Db查询构造器是ThinkPHP中构建SQL的核心机制，链式调用仅累积状态，需find/select等终结方法才执行；where错误写法易致SQL注入或解析异常，JSON字段查询要求MySQL≥5.7。
Db 查询构造器在 ThinkPHP 中不是“语法糖”，而是实际构建 SQL 的核心机制。链式调用本身不执行查询，只有遇到 find、select、value 等终结方法时才会真正发请求。这点不厘清，很容易在调试时误以为“写了 where 就查了”。
where 条件写错导致 SQL 注入或字段被忽略
常见错误是混用字符串条件和数组条件，尤其当字段名含 MySQL 关键字（如 order、group）时：
✘ 错误写法：where('order = 1') —— 不做字段转义，可能被解析为语法错误或绕过预处理
✔ 正确写法优先用数组：where(['order' => 1])，或显式表达式：where('order', '=', 1)
JSON 字段查询也容易出错：where('info->email', 'thinkphp@qq.com') 要求 info 是 JSON 类型字段，且数据库版本需 ≥ MySQL 5.7；低版本会静默返回空结果，无报错提示
闭包嵌套条件时，whereOr 和 where 在闭包内顺序不影响逻辑，但外部混合使用必须注意括号层级，否则生成的 SQL 与预期不符
field 和 column 的字段别名与索引行为差异
field 仅控制 SELECT 子句字段输出，不影响后续方法的字段引用；column 则直接返回一维数组，且第二个参数决定键名：
• column('name') → ['张三', '李四']
• column('name', 'id') → [1 => '张三', 2 => '李四']
• column('*', 'id') → 返回完整记录，并以 id 值为数组键，但注意：若多条记录 id 相同（如 JOIN 场景），后一条会覆盖前一条
别名支持只在 field 中生效：field(['name' => 'username']) 会让结果数组键名为 username，而 column 不接受这种映射
cache 方法失效的三个典型原因
cache 不是全局开关，它绑定的是整个查询语句结构（含参数值），以下情况会导致缓存不命中或不生效：
• 同一查询中混用 where 数组和字符串写法，生成的缓存 key 不一致
• 使用了 bind 或 whereRaw，但未在 cache 中显式传入相同参数（cache(60, 'user_list_v1') 不足以保证一致性）
• 缓存标识（如 'user_123'）未在增删改操作中同步清除：更新用户后，必须调用 Cache::tag('user')->clear() 或用相同标识再次 cache('user_123') 触发自动清理，否则旧缓存一直存在
另外，cache 对 findOrEmpty 有效，但对 findOrFail 抛异常前仍会读缓存——这点常被忽略
insert 和 replace into 的主键/唯一索引依赖陷阱
insert($data, true) 实际触发的是 REPLACE INTO，但它**强制要求表有主键或唯一索引**，否则退化为普通 INSERT 并可能重复插入：
• 没有主键/唯一索引 → 不报错，但不会删除旧行，变成纯新增
• 有联合唯一索引（如 UNIQUE KEY `uid_type` (`uid`, `type`)）→ 只要其中一组值匹配，就触发替换
• 替换过程是“删 + 插”，自增 ID 会跳变，事务中需注意一致性
更安全的替代方案是先 find 再 update 或用 upsert（TP6+ 支持，TP5 需手动实现）
立即学习“PHP免费学习笔记（深入）”；
链式操作的“链”本质是状态累积，但每个终结方法（find、select 等）执行后，该查询对象的状态不会自动重置。如果复用同一个 Db::table() 实例多次查询，记得用 removeOption() 清理条件，否则上一次的 where 或 limit 会悄悄影响下一次。 
