修改器不生效主因是$type类型声明冲突或allowfield过滤导致；datetime类型支持修改器，integer则跳过；修改器内不可访问其他属性，应改用事件或重写save()。
模型修改器不起作用？检查是否用了 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。这不是 bug，是生命周期决定的——修改器只负责当前字段的“输入转换”，不是业务逻辑钩子。
性能影响：强行在修改器里查数据库、调 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'），TP 尝试转时间戳失败，最终塞了个 0 给数据库。
兼容性影响：MySQL 严格模式下直接报错；非严格模式写入 0000-00-00，后续查询可能出空值或异常。
- 返回字符串时，务必用标准格式：
'Y-m-d H:i:s'（如date('Y-m-d H:i:s', time())） - 返回时间戳整数更稳妥，TP 会自动格式化进 datetime 字段
- 开发期打开
app_debug = true，留意日志里是否有Invalid datetime format类提示
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
