ThinkPHP 模型 where 条件字段名错误默认静默转为恒假条件，不报错难定位；需启用 $strict = true、校验字段白名单、安全处理 like 通配符、剥离 JSON/关联字段，并分级异常提示。
ThinkPHP 模型 where 条件里写错字段名不报错？
默认不会报错，而是静默转成 0=1 这类恒假条件，查不到数据还难定位——因为字段名拼错、大小写不符、或用了未定义的属性，TP6 的 where() 会直接忽略，不抛异常也不提示。
根本原因是 ThinkPHP 的查询构造器对模型字段做了“宽松映射”：只要字段不在模型的 $schema 或数据库字段列表里，就跳过；没开严格模式时，连日志都不记。
- 开启字段严格校验：
php think optimize:schema后确保模型启用了protected $strict = true; - 手动校验输入字段：在搜索前用
$model->getSchemaFields()拿到合法字段集，比对用户传入的field键 - 别依赖数据库报错兜底——MySQL 对
WHERE unknown_col = ?是直接报错的，但 TP 在生成 SQL 前就过滤掉了非法字段，根本到不了数据库层
用户输入 like 搜索带 *? / 通配符怎么安全转义
很多人让前端传 keyword=张*，后端直接塞进 where('name', 'like', "%{$keyword}%")，结果 * 被当字面量，% 和 _ 反而成了 SQL 通配符，导致查出意外数据或全表扫描。
ThinkPHP 不自动转义 like 参数里的特殊字符，得自己处理。关键是分清“用户意图”和“SQL 语义”：
立即学习“PHP免费学习笔记（深入）”；
- 若用户想搜“以张开头”，应传
keyword=张，后端补%：where('name', 'like', $keyword . '%') - 若支持简单通配（如
*表示任意字符），先用str_replace(['*', '?'], ['%', '_'], $input)转义，再进like - 绝对不要把原始输入拼进 SQL 字符串——哪怕加了
addslashes，也挡不住like的语义穿透
搜索参数含 JSON 字段或关联字段时 where 报错 Syntax error
比如用户传 category_id=1&status=active&extra={"level":2}，直接 where($params) 就崩，报 Parse error: syntax error, unexpected '{' 或更隐蔽的 Call to a member function where() on string ——其实是 TP 把 JSON 字符串当 PHP 表达式去解析了。
原因在于 ThinkPHP 的 where() 支持数组、闭包、字符串三种格式，而字符串格式会尝试 eval（虽然新版已禁用，但某些旧写法或第三方扩展仍残留逻辑）。JSON 字段必须显式剥离：
- 提前过滤掉非基础字段：
$searchable = array_intersect_key($params, array_flip(['name', 'status', 'category_id'])) - JSON 字段单独处理：
if (isset($params['extra'])) { $json = json_decode($params['extra'], true); if (json_last_error() === JSON_ERROR_NONE) { ... } } - 关联字段（如
user.name）不能直接进where()数组——得拆成withJoin()+ 显式where()条件
错误提示怎么做到既友好又不泄密
直接把 Undefined index: xxx 或 Call to undefined method 推给前端，等于暴露代码结构；但只回 “参数错误” 又没法调试。关键是在中间层拦截、重写、分级。
ThinkPHP 的异常处理机制能接管，但得避开两个坑：
- 别在控制器里用
try/catch包整个where()——很多字段错误发生在查询构建阶段，不触发 DB 异常 - 在模型的
initialize()或基类搜索方法里做字段白名单校验，失败时抛自定义异常：throw new ValidateException('搜索字段 "'.$key.'" 不被支持'); - 全局异常处理器中，对
ValidateException返回 400 + 简洁提示，其他异常走日志 + 500，绝不泄露路径、函数名、SQL 片段
最麻烦的是字段别名和视图字段混用场景——用户搜 real_name，模型里映射的是 user_info.name，这时提示“real_name 不可搜索”反而误导。得在提示里悄悄带上映射关系，又不能明说底层结构。
