thinkphp模型save报“unknown column”错误是因为默认将传入数据所有键视为字段拼入sql，遇非表字段（如token）即报错；必须用allowfield、except等显式过滤字段，且saveall需单独传参，setter无效。
ThinkPHP模型_save为什么报“Unknown column”错误
因为 save() 默认会把传入数据里所有键都当字段写入 SQL，遇到非表字段（比如前端传来的 token、confirm_password）就直接拼进 SET 子句，MySQL 报 Unknown column 'xxx' in 'field list'。
这不是 ThinkPHP 的 bug，是它默认信任你传的数据结构和表结构一致。实际开发中，表单字段永远比数据库字段多，必须主动过滤。
- 显式指定允许写入的字段：用
allowField参数，例如$model->allowField(['name', 'email'])->save($data) - 更安全的做法是配合
except，只剔除非字段项：$model->except(['token', 'captcha'])->save($data) - 如果用的是
create()（旧版）或validate()，注意它们不自动过滤字段，只是校验；字段过滤必须单独做
allowField(true) 和 allowField(false) 的区别很关键
allowField(true) 是「白名单模式」：只保留数据中同时存在于数据表字段 + 你显式声明的字段里的键；allowField(false) 是「黑名单模式」：默认放行全部，但会跳过 protected $readonly 定义的字段（如 id、create_time），前提是这些字段没被显式传入。
-
allowField(true)更安全，推荐在增/改操作中强制使用，尤其搭配getFields()动态获取字段：$model->allowField($model->getFields())->save($data) -
allowField(false)在某些 legacy 场景下省事，但一旦表结构变更、或数据里混入新字段，容易悄悄写错 - 两者都不影响
validate规则执行，校验和字段过滤是两层逻辑，别以为加了验证就不用过滤字段
批量更新时 saveAll 的字段过滤陷阱
saveAll() 内部会逐条调用 save()，但默认不继承模型实例上的 allowField 设置——这是最容易踩的坑。
- 必须显式传参：
$model->allowField(['title', 'status'])->saveAll($list)，否则每条记录都可能带脏字段 - 如果
$list中每条数据结构不一致（比如有的带remark，有的带note），allowField会统一按白名单裁剪，安全但可能丢数据 - 避免用
Db::name('table')->update()替代saveAll()来绕过模型逻辑——那样连事件、自动时间戳、软删除都会失效
自定义 setter 方法不能替代字段过滤
有人在模型里写 setTokenAttr() 想“接管”非法字段，但这只会让 token 被转成其他字段（比如存进 extra JSON 字段），而不会阻止它出现在 INSERT/UPDATE 的 SET 列表里。
- setter 只影响属性赋值过程，不影响最终生成的 SQL 字段列表
- 真正起作用的只有
allowField、except、only这三个模型方法 - 如果你依赖 JSON 字段存扩展属性，记得在
allowField里明确加上那个 JSON 字段名（如extra），否则它也会被过滤掉
save 前必须确认的动作；哪怕表结构暂时简单，也要养成 allowField 显式声明的习惯——等哪天加了个 __proto__ 或 constructor 字段进来，再补就晚了。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
