ThinkPHP 6+ 模型中 _setAttr 不生效是因为已弃用，须改用 set+字段名首字母大写+Attr 格式（如 setPasswordAttr），且仅在 save() 等写入操作中触发，需确保继承 think\Model、字段名严格匹配、方法参数仅为 $value。
ThinkPHP 模型中 _setAttr 修改器不生效的常见原因
直接在模型里写 _setAttr 方法却没触发？大概率是命名或位置不对。ThinkPHP 6+ 的修改器必须以 set + 字段名首字母大写 + Attr 形式命名，比如字段叫 password，就得叫 setPasswordAttr，而不是 _setAttr —— 后者是旧版 TP5 的写法，且仅在特定场景下被识别，新版已弃用。
实操建议：
- 确认模型继承的是
think\Model（非think\db\Model） - 字段名和方法名严格对应，区分大小写，如数据库字段为
user_name，方法应为setUserNameAttr - 修改器只对
save()、create()等写入操作生效，data()或直接赋值不会触发 - TP6.1+ 开始，
setXxxAttr方法参数默认只接收一个值（即新值），不要写成(value, $data)
密码加密入库的典型写法与陷阱
想在存库前自动把 password 字段哈希加密，最稳妥的方式是用 setPasswordAttr，但别直接调 md5() 或裸写 password_hash() —— ThinkPHP 自带的 think\facade\Crypt 不适用此场景，它用于加解密而非密码哈希；而 password_hash() 是唯一推荐方案，因为支持盐值自动生成和算法升级。
示例：
立即学习“PHP免费学习笔记（深入）”；
public function setPasswordAttr($value)
{
return $value ? password_hash($value, PASSWORD_ARGON2ID) : null;
}
注意点：
- 务必判空，否则新增记录时若该字段未传值，
password_hash(null, ...)会返回false，导致入库失败 - 别用
md5或sha1，它们不是安全的密码哈希方式，且无法抵御彩虹表攻击 -
PASSWORD_ARGON2ID需 PHP ≥ 7.3 且开启 sodium 扩展；若环境受限，退而用PASSWORD_DEFAULT（当前等价于 bcrypt） - 加密逻辑只发生在写入时，读取时不反向解密 —— 这是正确设计，验证时用
password_verify()
修改器里访问其他字段或原始数据的风险
有人想在 setPasswordAttr 里根据 email 或 username 动态加盐，或者依赖当前模型实例的其他属性。这很危险：修改器执行时，模型的其他字段可能尚未赋值，$this->email 很可能是空或旧值。
更糟的是，TP6 的修改器默认不提供第二个参数（即完整数据数组），所以不能像旧版那样靠 $data 取上下文。强行用 $this->getData() 也可能拿到不一致的状态。
可行做法：
- 如需多字段协同逻辑（比如“用户名+密码”组合加密），改用事件（
before_write）或重写save()方法 - 若只是简单加盐，直接用
password_hash()即可 —— 它内部已生成并嵌入随机盐，无需手动干预 - 避免在修改器里调用数据库查询、外部 API 或耗时操作，会拖慢所有写入流程
加密后验证失败？检查字段类型和长度
存进数据库后，用 password_verify() 总返回 false？先看字段定义。bcrypt 哈希结果约 60 字符，Argon2 约 90–120 字符。如果数据库字段是 VARCHAR(32) 或 CHAR(40)，必然被截断，哈希失效。
解决方案：
-
password_hash()输出最长约 255 字符（未来算法可能更长），字段类型至少设为VARCHAR(255) - MySQL 中避免用
utf8mb4字符集下的过短VARCHAR，因部分字符占 4 字节，实际存储长度可能进一步压缩 - 验证时确保传入的是原始明文密码，且和入库时完全一致（注意前后空格、换行、编码）
- 调试时可临时在修改器里
Log::info('hash: ' . $hashed)，确认入库值是否完整无截断
真正容易被忽略的是：修改器只管“写”，不管“读”。如果你在模型里又写了 getPasswordAttr，反而会把哈希值再处理一遍，导致验证永远失败 —— 密码字段不该有获取器。
