明文存密码极其危险，因拖库、撞库、内部人员访问、日志备份泄露及合规违规等多重风险，必须使用加盐哈希存储。

明文存密码等于把用户所有其他平台的账号一起交到攻击者手上——这不是假设，是已经发生过上百次的真实事件。

拖库后所有账号瞬间沦陷

一旦数据库被拖走，明文密码直接可读。而现实中超过 65% 的用户在不同网站使用相同密码。攻击者拿到你的 user 表，立刻就能去尝试登录微信、淘宝、邮箱——这叫“撞库”。你系统里一个弱密码，可能让用户的整个数字身份崩塌。

内部人员也能轻易获取全部密码

DBA、运维、甚至开发同事都有数据库只读权限。如果密码是明文，他们不需要越权、不需提权，查一条 SELECT * FROM user 就能批量导出所有人密码。这不是信任问题，是权限模型天然无法规避的风险。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

日志和备份里也全是明文

MySQL 的 general log、slow log、binlog（除非用 --log-raw 关闭重写）会原样记录含明文密码的 INSERT 或 UPDATE 语句。备份文件里同样躺着明文。只要一份日志或一个备份泄露，就全盘失效。

合规红线直接踩穿

GDPR、等保2.0、PCI DSS 都明确要求：密码必须以不可逆方式存储（如哈希），且须加盐。用明文不仅技术上愚蠢，法务上就是送检材料——审计一查就定性为重大安全缺陷。

真正难的不是“怎么加密”，而是坚持不让任何一行代码把 password = '123456' 这种东西塞进 SQL；最难忽略的一点是：加盐值如果写死在配置里，等于把万能钥匙挂在门把手上——动态盐+独立 salt 字段才是生产可用的底线。