Db::name()返回null时if判断失效的根源是PHP隐式类型转换：find()返回null或含0/false字段的数组均被转为false，导致存在记录却被跳过；安全判断应改用count()>0或value()而非依赖find()返回值真假。
Db::name() 返回 null 时 if 判断失效的根源
不是 Db::name() 有 bug，而是 PHP 的隐式类型转换把 find() 返回的 null 或含 0/false 字段的数组，全当成 false 了。比如 ['id'=>1, 'status'=>0] 过 if ($user = Db::name('user')->find()) 就会跳过，哪怕记录真实存在。
-
find()查不到返回null，查到返回关联数组（哪怕status是0） -
select()查不到返回空数组[]，查到返回二维数组，empty()安全 - 别用
if ($data = ...->find())判断“是否存在”，这是语义错位：你问的是“有没有这条记录”，PHP 却在判断“这个数组算不算真值”
判断单条记录是否存在的安全写法
要确认“某条数据存不存在”，就别碰 find() 的返回值内容，直接查数量或主键值。
- 通用方式：
Db::name('user')->where('id', 1)->count() > 0—— 轻量、语义明确、不受字段值干扰 - 主键存在性专用：
Db::name('user')->where('id', 1)->value('id')—— 返回null表示没查到，比find()少解析整行数据 - 如果必须用
find()后再判断，务必显式写：$user = Db::name('user')->find(); if (!is_null($user)) { ... }，不能省略is_null
where 条件里传数组引发的类型混淆
ThinkPHP 5.1 的 where() 接收数组时，对键名非常敏感。常见错误是传入带字符串键的条件数组，比如 where(['status' => 1, 'type' => 'admin'])，它会被当作“字段=值”简写；但一旦混入操作符，如 ['id' => ['in', [1,2,3]]]，就会因内部 key 类型校验失败而静默忽略或报错。
- 多条件且含操作符时，必须用二维数组格式：
where([['status', '=', 1], ['id', 'in', [1,2,3]]]) - 数组第一维下标必须从
0开始，[1 => [...], 2 => [...]]会导致条件丢失（源码Builder.php第 305 行强制校验key($value) === 0） - 避免用字符串键数组传复杂条件，TP5.1 不支持嵌套或混合操作符，TP6+ 更是直接弃用该用法
升级到 TP6/8 时 where 和 find 的行为断层
TP5.1 的 where(['a'=>1, 'b'=>2]) 在 TP6+ 里仍能运行，但只是兼容层兜底；真正推荐写法已变成链式或闭包。更关键的是，findOrFail() 在 TP6+ 抛的是 ValidateException，不是 DbException，老代码里 catch \think\exception\DbException 会漏捕获。
立即学习“PHP免费学习笔记（深入）”；
- TP6+ 的
select()返回Collection对象，$list[0]['name']会报错，得先->toArray() -
find()行为没变（仍返null），但findOrFail()默认带 HTTP 404 响应头，API 层若需自定义错误格式，得提前拦截异常 - TP8 中
Db::name()已移除，必须改用Db::table('prefix_user')或模型类调用，表名不再自动加前缀
最常被忽略的一点：你以为在判断“有没有数据”，其实 PHP 正在帮你做一次不可靠的真假值转换；所有依赖 if ($res) 的查询判断，都应该重审是否真的需要那条数据，还是只需要知道它存不存在。
