验证记录是否存在应使用 where()->exists() 或 where()->count()，而非 findOrEmpty()；TP6.0+ 支持 exists() 返回布尔值，TP5.1 需用 count()>0；软删除场景须显式添加 whereNull('delete_time')。
用 where 验证记录是否存在，别调 findOrEmpty
ThinkPHP 的 findOrEmpty 不是为「存在性校验」设计的——它本质是查一条记录再兜底返回空数组，性能和语义都不对。验证存不存在，该用 where + count 或 exists。
常见错误是写成：$user = User::where('email', $email)->findOrEmpty(); if (!$user) { ... }。这会查出整行数据（哪怕只用判断真假），浪费 IO 和内存，还可能触发模型事件、自动转换、关联预载入等额外开销。
-
where(...)->count()最轻量，只走 COUNT(*)，返回 int，0 表示不存在 -
where(...)->exists()语义最准，在支持 EXISTS 语法的数据库（MySQL 5.7+、PostgreSQL）里生成EXISTS (SELECT 1 FROM ...)，通常比count更快 - 别在验证逻辑里用
find/findOrEmpty/select，除非你下一步真要读数据
exists() 在不同版本 ThinkPHP 的行为差异
ThinkPHP 6.0+ 原生支持 exists() 方法，直接返回布尔值；TP5.1 没这个方法，得手写原生 SQL 或用 count() > 0 替代。
TP6.0 示例：User::where('mobile', $mobile)->exists() → 返回 true 或 false；TP5.1 只能：User::where('mobile', $mobile)->count() > 0。
立即学习“PHP免费学习笔记（深入）”；
- TP6.0+ 的
exists()底层会自动优化为子查询，不取字段，也不走模型构造器 - TP5.1 若强行用
find()判断，注意null和空数组的真假值陷阱：比如find()返回null，但某些场景下模型可能返回空对象而非null，导致if ($res)判断不稳定 - 跨版本兼容写法建议统一用
count() > 0，语义清晰、行为稳定、所有版本都支持
联合条件 + 软删除场景下容易漏掉的过滤
验证「某条记录是否已存在」时，如果表启用了软删除（delete_time 字段），where 默认不会自动排除已删除数据——这意味着 exists() 或 count() 可能返回 true，但实际业务上那条记录已被逻辑删除。
- 必须显式加软删除过滤：
User::where('email', $email)->whereNull('delete_time')->exists() - 如果项目全局启用了软删除中间件或基础模型自动处理，确认当前模型是否继承了正确基类（如 TP6 的
SoftDeletetrait），否则自动过滤不会生效 - 调试时可打印 SQL：
User::where('email', $email)->whereNull('delete_time')->toSql()，核对生成的 WHERE 条件是否含delete_time IS NULL
验证失败后抛异常还是返回 false？选哪个更稳
验证存在性本身是个纯查询动作，不涉及状态变更，所以返回布尔值最合理。但很多人习惯在验证后立刻抛异常（比如注册时提示“邮箱已被占用”），这时要注意控制异常抛出位置。
- 不要在验证方法内部抛异常——把判断和响应耦合在一起，不利于复用和测试
- 推荐分两步：先
$exists = User::where(...)->exists()，再由业务逻辑决定是throw new ValidateException(...)还是return ['code'=>1, 'msg'=>'已存在'] - 若用 validate 规则做唯一性检查（如
rule => ['unique' => 'user.email']），底层其实也是走count查询，但会自动处理软删除，适合表单场景；自定义验证逻辑仍建议手动控制where条件
exists 或 count），补全条件（特别是软删除、租户 ID、状态字段）。别的都是围绕这两点打转。 
