allowfield仅在链式调用save()/update()/create()时生效，模型属性$allowfield仅对create()有效；常见失效原因包括赋值方式错误、静态方法调用丢失上下文、db类误用、字段名大小写不匹配及严格模式干扰。
ThinkPHP 6.0 的 allowField 不是“设了就自动生效”的开关，它只在调用 save()、update()、create() 等写入方法前链式调用时才起作用；模型属性 $allowField 仅对 create() 有效，对 save() 和 update() 完全无效。
为什么 allowField(['name', 'email']) 调了却没过滤掉 password？
最常见原因是调用顺序或方式错误：
-
$model->allowField = ['name', 'email']; $model->save($data);—— 属性赋值不触发过滤，save()仍按默认逻辑处理全部字段 -
$model->allowField(['name', 'email'])->update($data);——update()是静态方法，链式调用会丢失实例上下文，实际未生效 - 用了
Db::name('user')->update($data)——allowField是模型专属，Db类完全不识别 - 字段名大小写不一致：数据库是
user_name，但传入的是username，匹配失败后被当作非法字段直接报错（尤其在_strict = true下）
allowField 和 _strict 到底谁管字段过滤？
allowField 控制“哪些字段能进 SQL”，_strict 只控制“字段不存在时是否抛异常”：
-
_strict = true（默认）：字段不在数据表中 → 报The field xxx is not exists in table user，但不会帮你剔除合法字段 -
_strict = false：字段不存在时静默忽略，但password这种存在的字段照样写入，毫无防护力 - 二者不互斥，但分工明确：
allowField是唯一能真正排除敏感字段的机制；_strict只是调试辅助开关 - 别用
_strict = false来“绕过报错”，那等于放弃字段合法性检查，可能把错别字字段写进数据库
如何让 allowField 在所有更新场景下稳定生效？
必须把字段白名单逻辑收口到模型或基类，避免每个控制器手写：
- 在模型中定义静态属性
protected $allowField = ['name', 'email', 'status'];，然后统一用self::create($data)或$model->create($data)—— 此时属性生效 - 对
save()和update()，改写基类控制器的doSave()方法：return $model->allowField($this->getAllowFields())->save($data);，再由子类重写getAllowFields()按接口返回不同数组 - 关联写入（
with()）不受allowField影响，必须在关联模型里单独配置$allowField或链式调用allowField() - 注意 JSON 字段、虚拟属性（如
getFullnameAttr）、数据库别名（user_id as uid）都不会被自动识别，需手动列入白名单
容易被忽略的兼容性陷阱
TP6.0+ 默认开启严格字段检查，很多旧代码升级后突然报错，根源不在 allowField 本身：
- MySQL 字段类型不匹配也会触发“字段不存在”假象：比如数据库是
TINYINT(1)，PHP 传入字符串"true"，类型转换失败后该字段被过滤，报错信息极具误导性 -
$fillable在 TP6+ 已废弃，$allowField是唯一替代方案；继续写$fillable会导致字段校验直接跳过，验证器规则都不执行 -
input(['id', 'name'])返回的是请求参数白名单，但它和模型的allowField完全无关——前者防 URL 参数污染，后者防数据库误写入，两者必须同时做 - 手动组装数据数组（如
['name' => $request->post('name')]）会绕过所有模型层过滤，allowField彻底失效
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
