拉倒吧，官方禁止加班的意思就是，你们晚走都是自愿的，公司不承认你们是在加班，不支付加班费

没关系，写一段兼容代码就好了：

您的浏览器存在病毒感染风险，请下载安全浏览器：[此处为 Edge 下载链接]

就怕一紧张，噗通双膝跪下

两个前提：
1 、结构不确定
2 、数据整存整取

在确定了产品经理有多不靠谱的情况下

猫的报恩，鹿的报仇

个人博客？ sqlite+静态化就好了

不如做成外设，还能再割一波 9 菜

挺多的吧，不过我是用贴纸贴掉了

@jtwor 提供服务接口就行了，你可以使用私有格式，甚至特殊的硬件，随意发挥

@loux 这个副作用的确存在。但是邮箱手机解绑和重新绑定本身就是身份认证系统的业务，而不是用户系统的业务。认证系统重新绑定邮箱和手机后，可以通知用户系统更新 user profile 里的数据。用户系统不用验证邮箱和手机的惟一性，交给认证系统处理就好了

@liuzhedash 被产品坑个几次就知道拆表的好了

@kiripeng 脱敏只是一部分原因。或者说是附加的额外优势，如果 User 和 Authentication 系统分开（逻辑上和数据上都分开），甚至可以做到 password 数据不落数据库，无论是用特殊硬件还是保密级别更高的数据库，自由度非常高

@qsnow6
@qq8331199
@loux
@kiripeng

理由很简单，用户(User)和认证(Authentication)是两码事，小型系统混在一起没关系，既然做的是通用架构，那就不应该混在一张表里。用户放在 User 表里，认证信息放在 Auth 表里。

谁规定一个用户只能有一种登录（认证）方式的？除了用户名+密码的方式，手机号+密码行不行？邮箱+密码行不行？用户名+一次性 TOTP 行不行？

对于第三方平台认证的用户根本不需要密码字段。如果需要封禁一个用户，只要删除 Auth 表里用户对应的认证数据就行了。甚至可以控制一个用户允许通过哪些方式登录（认证）

@liuzhedash 这表结构设计得很糟糕，密码和用户信息竟然放在一张表里