fields_strict是字段合法性校验开关，非防注入机制；开启后会校验写入字段是否真实存在于数据库表中，非法字段直接抛异常，避免静默失败或意外覆盖。
ThinkPHP 的 fields_strict 不是用来“防止字段注入”的安全机制，而是一个字段合法性校验开关，它的作用是：在写入或更新数据时，检查你传入的字段名是否真实存在于数据库表中；如果存在未知字段，且 fields_strict = true（默认），就会直接抛出异常，从而避免因拼写错误、参数污染或结构不一致导致的静默失败或意外覆盖。
它不能替代输入过滤、权限控制或 SQL 注入防护，但能有效拦截“错字段写入”这类低级但高危的问题。
✅ 正确开启并使用 fields_strict
1. 全局开启（推荐，默认即开启）
在数据库配置文件（如 config/database.php）中确认以下配置存在且为 true：
'db' => [
'fields_strict' => true, // 默认就是 true，无需修改
],⚠️ 注意：ThinkPHP 6/8 默认开启该选项。如果你没改过配置，就已经在起作用了。
立即学习“PHP免费学习笔记（深入）”；
2. 单次查询临时关闭（仅调试用，勿上线）
Db::name('user')->strict(false)->insert($data);这行代码会跳过本次插入的字段校验，不建议用于生产环境，仅限排查字段名不匹配问题时临时使用。
3. 验证是否生效的小技巧
故意传一个不存在的字段试试：
$data = ['username' => 'test', 'xxx_tmp' => 'hack'];
Db::name('user')->insert($data); // fields_strict=true 时会立即报错报错类似：InvalidArgumentException: The field xxx_tmp is not exists in table user
❌ 常见误解与风险点
-
fields_strict = false不等于“更安全”，反而可能让非法字段被静默忽略，或在某些驱动下引发 SQL 错误； - 它不防 SQL 注入——SQL 注入靠参数绑定（ThinkPHP 默认已做）、输入过滤、白名单字段控制来防御；
- 它不代替 allowField：
allowField()是白名单式字段过滤（只允许写指定字段），fields_strict是黑名单式校验（禁止写不存在字段），二者逻辑不同，可配合使用但不可互换； - 字段名比对区分大小写，且必须与数据库实际列名完全一致（如
create_time≠createTime）。
✅ 更进一步：结合白名单主动防控
光靠 fields_strict 被动报错还不够，建议在业务层加一层主动控制：
$allowed = ['username', 'email', 'mobile', 'status'];
$input = input('post.');
$safeData = array_intersect_key($input, array_flip($allowed));
UserModel::create($safeData); // 或 Db::name('user')->insert($safeData)或者模型中链式调用：
$user = new UserModel(); $user->allowField(['username', 'email'])->save($input);
✅
allowField()+fields_strict = true是双重保险：前者控“该写哪些”，后者控“不该写的别让我碰”。
? 补充：如何动态获取合法字段列表？
避免硬编码白名单，可用：
$fields = Db::getFields('user'); // 返回小写字段数组，如 ['id','username','email']
// 然后校验用户输入的 key 是否都在其中适用于动态搜索、排序、where 条件等场景，比如：
$sort = input('sort', 'id_desc');
$field = preg_replace('/_(asc|desc)$/i', '', $sort);
if (!in_array($field, $fields)) {
throw new HttpException(400, '非法排序字段');
}不复杂但容易忽略。
