ThinkPHP更新需用allowField白名单显式指定字段，_strict仅控制字段校验不参与过滤；Db类更新不支持allowField，模型更新必须链式调用allowField并排除敏感字段。

ThinkPHP 的 update 默认会更新所有传入字段，包括你不想要的

这是最常踩的坑：调用 save() 或 update() 时，只要数据数组里有某个字段，哪怕数据库里它本不该被修改，也会被写进去。比如用户提交了 id、name、status、create_time，而你只希望改 name 和 status，但 create_time 会被一并覆盖成当前值（或空），导致数据错乱。

ThinkPHP 提供了两种主流控制方式：allowField 和 _strict，但它们作用时机和逻辑完全不同，混用容易失效。

• allowField 是白名单机制，在数据写入前过滤字段，只保留你明确列出的字段
• _strict 是模型层的“严格模式”开关，影响的是字段合法性校验，不是字段过滤——它不会帮你剔除字段，只会决定“字段不存在时是否报错”
• 如果你没设 allowField，又开了 _strict = true，反而可能因字段名拼错直接抛出 InvalidArgumentException: property not exists

allowField 怎么用才真正排除字段

必须在调用 save() 或 update() 前显式传入允许的字段数组，否则不生效。模型本身的 $this->allowField 属性仅对 create() 有效，对更新无效。

• 正确写法：$model->allowField(['name', 'status'])->save($data)
• 错误写法：$model->allowField = ['name', 'status']; $model->save($data)（属性赋值不触发更新过滤）
• 如果用 Db::name('user')->update($data)，allowField 完全无效——它只属于模型类
• 注意：字段名必须和数据库列名一致，区分大小写；别名、JSON 字段、虚拟属性不会被自动识别，需手动列入白名单

为什么 _strict = false 不能替代字段过滤

_strict 控制的是模型是否校验字段是否存在。设为 false 后，即使你传了数据库里没有的字段（比如 xxx_tmp），也不会报错，但它依然会尝试写入——最终结果取决于底层 SQL 构建逻辑，多数情况是被静默忽略，但某些驱动（如 PDO MySQL）可能因字段不存在导致 SQL 错误。

立即学习“PHP免费学习笔记（深入）”；

• _strict = false 的典型用途：兼容历史数据结构变更，避免因新增字段未同步到模型就崩掉
• 它对防止误更新毫无帮助：你传了 password，它照样塞进 SQL，除非数据库字段真的不存在
• 若同时开启 _strict = true 又漏写了字段，会提前在 PHP 层报错，反而比静默失败更容易定位问题

安全更新的推荐组合：白名单 + 显式指定主键

排除字段的本质目标是“只更新该更新的”，而不是“不让它报错”。所以最稳的做法是：不用依赖任何全局配置，每次更新都主动声明允许字段，并确保主键不被意外覆盖。

• 始终用模型更新：UserModel::update($data, ['id' => $id])，而非 Db::table()
• 立刻链式调用 allowField：UserModel::update($data, ['id' => $id])->allowField(['name', 'email'])
• 敏感字段（如 password、token、is_deleted）绝不放进用户提交的数据源，先从 $data 中 unset() 掉再传入
• 如果字段逻辑复杂（比如根据角色动态放行），把白名单提取成方法：$this->getAllowFields($role)，别硬编码在控制器里

真正麻烦的从来不是语法怎么写，而是谁来保证每次更新都记得加 allowField。一旦漏掉一次，就可能覆盖掉 updated_at、version 甚至 status 这种关键字段——而且这种 bug 往往上线后才暴露，日志里还找不到痕迹。