exists() 是判断关联存在的最轻量方式，仅返回布尔值、生成极简 sql、不实例化模型；必须链式调用在关系方法后，不可用于 has() 或直接模型调用，适用纯存在性判断。
exists() 是判断关联是否存在最轻量的方式，它不加载数据、不触发事件、只返回 true 或 false；但必须链式调用在关系方法之后，不能直接在模型类上用。
为什么 exists() 比 count() 和 get() 快
它生成的是 SELECT 1 FROM ... WHERE EXISTS (...) 这类极简 SQL，跳过字段映射、类型转换、访问器、模型实例化等全部 Eloquent 开销。尤其在大表关联时，count() 要扫描行数，get() 要构造完整模型，而 exists() 只需找到一条匹配记录就立刻返回。
- 适用于纯存在性判断：比如「用户是否绑定了手机号」「商品是否有 SKU」
- 不适用于后续要读取关联字段的场景——这时该用
first()或带条件的whereHas() - 常见错误：写成
User::has('phone')->exists()——has()返回的是查询构建器，不是关系方法，无法链exists() - 正确写法是
User::whereId($id)->phone()->exists()（前提是phone()是定义好的一对一关系）
whereHas() 才是带条件查关联存在的正解
当你要确认「存在满足某条件的关联记录」时，exists() 无能为力，必须用 whereHas()。它会在子查询中加入 WHERE 条件，再用 EXISTS 判断。
- 例如查「用户是否有未删除的订单」：
User::whereId($id)->whereHas('orders', fn ($q) => $q->whereNull('deleted_at'))->exists() - 错误写法：
User::whereId($id)->orders()->whereNull('deleted_at')->exists()——orders()返回的是HasMany实例，不是查询构建器，不能直接链whereNull() - 性能关键：确保关联表上有复合索引，如
(user_id, deleted_at)，否则可能全表扫描 - 别在
whereHas()闭包里混用orWhere()，它会破坏子查询逻辑，导致恒真条件
withExists() 的行为和坑点
withExists() 是 Laravel 7+ 加入的便利方法，但它和单独调 exists() 完全不同：它把结果作为布尔字段注入主模型，字段名默认是 {relation}_exists（如 posts_exists），且自动处理空关系和 null 值。
- 它本质是 LEFT JOIN + CASE，不是子查询，所以不会像
whereHas()那样触发多次 EXISTS - 但它不支持在闭包里加复杂条件——想筛「已审核评论」，得用
withCount(['comments' => fn ($q) => $q->where('is_approved', true)])，而不是withExists() - 字段名不可改，如果模板里直接用了
$user->posts_exists，升级 Laravel 版本或换关联名时容易漏改 - 它和
with()可共存，但注意：若同时with('posts')和withExists('posts')，Eloquent 会发两条 SQL，除非你手动合并
关联存在性验证别踩这三类坑
实际开发中最容易栽在语义混淆、调用位置和索引缺失上。
-
has('orders')和whereHas('orders', ...)看似只差一个字，但前者只看数量，后者才看内容；权限校验里写错一个字母，就可能放行非法数据 -
exists()必须紧跟在关系方法后，中间不能插其他查询方法；User::whereId(1)->withTrashed()->orders()->exists()是错的，软删除状态会影响结果，但withTrashed()不该出现在这里 - 外键没建索引时，
whereHas()和exists()都会变慢，尤其是 MySQL 5.7；别等线上报警才补index('user_id') - 多层嵌套（如用户→订单→订单项→商品）慎用连续
whereHas()，三层以上建议拆成原生selectRaw或提前建好聚合视图
