ThinkPHP中AND+OR混合条件需用嵌套闭包实现：每组AND条件放入独立闭包，再用whereOr连接，确保生成“(a=1 AND b=2) OR (a=3 AND c=4)”结构；须显式添加表别名防字段歧义，参数绑定防SQL注入，避免过深嵌套影响索引使用。
where 闭包里怎么写 AND + OR 混合条件
ThinkPHP 的 where 闭包不是简单堆逻辑，而是靠嵌套闭包控制作用域。直接写 $query->where('a', 1)->whereOr('b', 2) 会变成全局 OR，不是你想要的 “(a=1 AND b=2) OR (a=3 AND c=4)”。
正确做法是把每组 AND 条件包进独立闭包，再用 whereOr 连接：
Db::table('user')
->where(function ($query) {
$query->where('status', 1)->where('score', '>', 80);
})
->whereOr(function ($query) {
$query->where('level', 'vip')->where('last_login', '>', strtotime('-7 days'));
})
->select();
- 每个闭包生成一对括号，ThinkPHP 自动加
(...) -
whereOr必须接在闭包之后，不能写成whereOr(...)传数组——那样不生效 - 如果用的是 6.0+，注意
whereOr是方法链式调用，不是静态方法
多层嵌套时 alias 冲突和字段歧义
连表查询中，在闭包里写 where 很容易漏掉表别名，尤其当主表和关联表都有 id 或 name 字段时，SQL 直接报错或查出错数据。
闭包里的字段默认绑定主表，要查关联表字段，必须显式带别名：
立即学习“PHP免费学习笔记（深入）”；
Db::table('order o')
->join('user u', 'o.user_id = u.id')
->where(function ($query) {
$query->where('o.status', 'paid') // 正确：带 o.
->where('u.is_deleted', 0); // 正确：带 u.
// ❌ 错误写法：->where('status', 'paid') → 可能被解析成 u.status
})
->select();
- 哪怕只查一张表，也建议统一加别名（如
user u），后续扩展连表更安全 - 闭包内不支持
use ($var)传变量以外的上下文，所有字段名、值都要明确写出 - TP 6.3+ 对未加别名的字段会尝试自动推导，但不可靠，线上环境务必显式声明
闭包里调用子查询 orRaw 怎么避免 SQL 注入
需要动态拼接 SQL 片段（比如 JSON 包含匹配、地理距离计算）时，where 闭包里用 whereRaw 很常见，但参数没处理好就会被注入。
绝对不要这样写：$query->whereRaw("json_contains(tags, '{$tag}')") —— {$tag} 是裸字符串拼接。
正确方式只有两种：
// ✅ 方式一：用参数绑定（推荐）
$query->whereRaw('json_contains(tags, ?)', [$tag]);
// ✅ 方式二：用 Db::raw() 包装已转义值
$query->whereRaw('json_contains(tags, ' . Db::raw(json_encode($tag)));
-
whereRaw第二个参数必须是数组，即使只有一个值也要写成[$val] -
Db::raw()不做转义，只标记“这段不加引号”，所以它里面的内容得自己确保安全 - 闭包外的变量进闭包，记得用
use ($var)，否则闭包里访问不到
性能陷阱：闭包嵌套过深导致 SQL 太长 or 执行计划失效
超过 3 层嵌套（比如 where → whereOr → where → whereOr）时，ThinkPHP 生成的 SQL 可能出现冗余括号或条件顺序混乱，MySQL 优化器可能放弃使用索引。
这不是框架 Bug，而是 SQL 复杂度超出优化器合理判断范围的表现。
- 先用
buildSql()把最终 SQL 打出来，贴到 MySQL 客户端执行EXPLAIN看 key_len 和 type - 如果发现
type=ALL或key_len明显偏小，说明索引没走，得拆查询或改结构 - 复杂权限类查询（如“用户可见的订单”含角色+部门+时间+状态多重交集），优先考虑用视图或中间表预计算，别硬扛在闭包里
闭包写得再漂亮，也掩盖不了底层 SQL 的物理限制。该拆就拆，别迷信“一个闭包搞定全部”。
