模型修改器失效，大多数情况下都是 $type 类型声明和 allowField 字段过滤在作怪。说穿了，修改器仅在写入数据库前的最后时刻才执行，一旦在此之前已经锁定了字段的类型或操作权限，它便彻底不起作用了。
模型修改器失效？先排查是否因 protected $type 覆盖了类型推断
ThinkPHP 的模型修改器（比如 setCreateTimeAttr）仅在写入数据库前触发，但前提是字段没有被 $type 强制声明为某种类型——一旦你写下了 'create_time' => 'integer'，框架就会跳过修改器，直接走类型转换逻辑。
常见的翻车现象：setCreateTimeAttr 完全没有响应，dump($this->data) 里时间仍是原始值；或者修改器明明返回了格式化字符串，数据库里存的却是时间戳整数。这类问题的排查思路其实并不复杂。
- 确认
$type数组中没有包含该字段，或者改用'create_time' => 'datetime'（修改器仍可正常工作） - 如果确实需要
integer类型，则在修改器里手动转换时间戳：return strtotime($value); - 在
datetime类型下，修改器返回字符串（比如'2024-05-20 10:30:00'）会被自动转为时间戳写入数据库
赋值时想统一处理字段，但 setXxxAttr 不生效？检查是否用了 allowField 或批量赋值
修改器只对模型实例的属性赋值生效，例如 $user->name = 'abc'、$user->data(['name'=>'abc'])；但如果你使用了 create() 或 saveAll() 并传入 allowField，且字段不在白名单内，那么修改器根本不会被触发。
一个典型的场景：表单提交后调用 User::create($_POST)，结果发现 setPasswordAttr 没有对密码进行加密。这时候不要急着怀疑代码逻辑——先检查一下白名单配置。
- 检查
create()是否传入了allowField，并且'password'位于列表中 - 避免在
create()之前手动过滤字段，比如使用array_intersect_key(...)后再传入，这会绕过模型字段校验和修改器 - 批量保存使用
saveAll()时，每个数据项都必须是完整数组，不能混用对象和纯数组
修改器里调用 $this->xxx 报错？避免在 setXxxAttr 中读取其他属性
修改器函数执行时，模型的其他属性可能尚未赋值或初始化，$this->name、$this->status 这类访问大概率返回 null 或触发 Notice 错误。这并非程序缺陷，而是由生命周期决定——修改器只负责当前字段的“输入转换”，并非业务逻辑钩子。
另外，强行在修改器里查询数据库或调用 API，会导致每次赋值都多一次 IO 操作，在批量插入时问题会被放大，这是一个隐藏的性能杀手。
- 如果需要依赖其他字段做处理，改用事件（
before_write）或重写save()方法 - 如果只是格式转换（如大小写、trim、json_encode），确保只操作
$value参数本身 - 调试时添加
if (func_get_args()) { dump(func_get_args()); }查看传入值，不要直接 dump$this
MySQL 字段为 datetime 但 PHP 传入字符串，为何存储后变成 0000-00-00？
这是类型不匹配与修改器返回值不当的典型组合：数据库字段定义为 datetime 类型，但修改器返回了非法格式字符串（如 '2024/05/20'），ThinkPHP 尝试转换为时间戳失败，最终向数据库写入 0。
后果是：MySQL 严格模式下会直接报错；非严格模式下写入 0000-00-00，后续查询可能得到空值或异常，导致数据混乱。
- 返回字符串时，务必使用标准格式：
'Y-m-d H:i:s'（例如date('Y-m-d H:i:s', time())） - 返回时间戳整数更稳妥，ThinkPHP 会自动格式化后写入 datetime 字段
- 开发阶段开启
app_debug = true，留意日志中是否有Invalid datetime format类提示
总结到此为止。最常见的坑是误以为修改器可以当作业务钩子使用，结果它连自身模型的其他字段都依赖不上。只有理解了它的边界，用起来才会得心应手。