结论：必须用where()链式调用配合闭包嵌套实现动态AND/OR/NOT组合，禁用字符串拼SQL；ThinkPHP 6.0+支持whereOr()/whereNot()闭包，5.1需用三参数形式；字段名须白名单校验，避免注入；嵌套不影响语法效率，但复杂NOT易致索引失效，需EXPLAIN验证。
ThinkPHP模型里怎么写动态AND/OR/NOT组合条件
直接说结论：不能靠拼SQL字符串，得用where()链式调用配合闭包嵌套。ThinkPHP的where()本身不解析“AND”“OR”这类关键词字符串，传字符串进去只会当纯SQL片段处理，丢失参数绑定和安全防护。
常见错误是这样写：$model->where("status = 1 AND (type = 'A' OR type = 'B')")->select()——看似能跑，但字段名、值全没转义，SQL注入风险实打实存在；更麻烦的是，后续想加NOT逻辑（比如NOT (type = 'C')）时，括号嵌套一多就难维护、易出错。
- 正确做法是用闭包构造子查询：
where(function ($query) { $query->where('type', 'A')->whereOr('type', 'B'); }) -
whereOr()和whereNot()是ThinkPHP 6.0+原生支持的方法，不是插件或扩展 - 如果用的是ThinkPHP 5.1，
whereOr()需改用where(['type' => 'A'], ['type' => 'B'], 'or')这种三参数形式，否则默认是AND - 多个
whereNot()连续调用等价于NOT A AND NOT B，要表达NOT (A OR B)必须套一层闭包+whereOr()
NOT逻辑怎么避免括号漏写或嵌套错位
NOT最容易翻车的地方，不是语法不会写，而是语义理解偏差。比如想查“不是管理员且不是审核员”，有人会写：whereNot('role', 'admin')->whereNot('role', 'reviewer')——这其实是role != 'admin' AND role != 'reviewer'，符合预期；但若想查“不是（管理员或审核员）”，就必须：whereNot(function ($q) { $q->where('role', 'admin')->whereOr('role', 'reviewer'); })。
- ThinkPHP 6.0+ 的
whereNot()只接受闭包或字段名+值，不支持直接传带OR的数组 - 闭包里用
whereOr()时，它只对当前闭包内生效，不会污染外层查询 - 调试时可打印
$model->getLastSql()看生成的SQL，重点核对括号位置和NOT作用范围
字段名动态拼接时如何防止SQL注入
用户输入字段名（比如搜索框选“用户名”“邮箱”“手机号”）再拼条件，是高频需求，也是高危场景。直接把用户传来的$field塞进where($field, $value)极危险——万一传个id); DROP TABLE user; --呢？
- 必须白名单校验：
in_array($field, ['username', 'email', 'mobile'], true)，不满足直接抛异常或忽略 - 禁止用
where("{$field} = ?", $value)这种字符串拼接方式，哪怕做了过滤也不保险 - ThinkPHP的
where()方法本身对字段名不做转义，它只保证值参数走PDO预处理，字段名得开发者自己兜底 - 如果字段来自配置文件或数据库字典，也要确保来源可信，不能是前端任意传参解析出来的
性能隐患：嵌套太多闭包会不会拖慢查询
单纯语法嵌套不影响执行效率，真正拖慢的是生成的SQL质量。比如在闭包里反复whereOr()又套whereNot()，最终SQL可能变成多层NOT (A OR (B AND NOT C))，MySQL优化器有时会放弃使用索引。
- 用
EXPLAIN看执行计划，重点关注type是否为range或ref，key是否命中索引 - 复合条件尽量扁平化：把
NOT (A OR B)等价转换成NOT A AND NOT B，前者常导致索引失效 - 涉及全文检索、模糊匹配（
like '%xxx%'）时，AND/OR组合再复杂也救不了没索引的命，优先建好联合索引
最麻烦的其实是业务逻辑和SQL语义的对齐——人脑觉得“非A且非B”和“非(A或B)”一样，但写错一层括号，数据库就真按字面意思执行了。上线前务必用真实数据测几组边界case，别只信文档里的示例。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
