exists() 查的是关联记录是否存在，生成 SELECT 1 语句，返回布尔值，不加载模型、不触发事件、无副作用；适用于权限校验等纯存在性判断，不适用于需获取字段的场景。
exists() 方法到底查的是什么
exists() 不是查模型数据本身，而是生成一条 SELECT 1 的极简 SQL，只判断关联记录是否存在。它绕过 Eloquent 的属性加载、类型转换、访问器（accessor）等全部开销，比 count() 或 get() 快得多，尤其在大表关联时差异明显。
常见错误是以为 exists() 会触发模型事件或填充关系属性——它不会。调用后你拿到的只是 true 或 false，没有模型实例，也没有懒加载副作用。
- 适用场景：权限校验（“用户有没有这个订单？”）、前端开关控制（“该商品是否已关联规格？”）
- 不适用场景：需要后续操作关联模型字段（比如取
name或updated_at）——这时该用first()或带约束的whereHas() - 注意：
exists()必须在关联关系方法调用后链式使用，不能直接在模型类上调用，例如User::has('posts')->exists()是错的，正确是User::whereId(1)->posts()->exists()
whereHas + exists() 组合怎么写才安全
想查“用户是否有未删除的订单”，不能只靠 user->orders()->exists()，因为默认关联可能没加软删除约束。这时候得用 whereHas() 套一层条件，再调 exists()。
关键点在于：条件必须写在 whereHas() 的闭包里，而不是在关联定义中硬编码。否则容易污染其他查询逻辑。
- 正确写法：
User::whereId($id)->whereHas('orders', fn ($q) => $q->whereNull('deleted_at'))->exists() - 错误写法：
User::whereId($id)->orders()->whereNull('deleted_at')->exists()—— 这会报错，因为orders()返回的是HasMany实例，不是查询构建器 - 性能提示：如果关联表有复合索引（如
(user_id, deleted_at)），这个组合能命中索引；否则可能触发全表扫描
exists() 在 withExists() 中的隐藏行为
withExists() 是 Laravel 7+ 加入的便利方法，但它和单独调 exists() 行为不同：它会把结果作为布尔字段注入到主模型，字段名默认是 {relation}_exists（比如 posts_exists），且**自动处理空值和关系不存在的情况**。
容易踩的坑是误以为它会复用已有关系定义里的约束。实际上，withExists('posts') 用的是原始关联定义；如果想加条件，得显式传闭包：
- 基础用法：
User::withExists('posts')->get()→ 返回每个User多一个posts_exists属性 - 带条件：
User::withExists(['posts' => fn ($q) => $q->where('status', 'published')])->get() - 注意：闭包里不能用
$this，因为此时模型实例尚未加载；所有条件必须静态可推导
exists() 报错 “Call to undefined method” 怎么快速定位
这个错误基本只发生在两种情况：调用对象不是关系实例，或者关系方法返回了非关系对象（比如手动 return new Collection()）。
最常被忽略的是：关系方法里用了 return $this->belongsTo(...)->withDefault() 或类似链式调用，导致返回的不是标准关系类，而是封装后的代理对象，不支持 exists()。
- 检查方式：
dd(get_class($user->posts()))，正常应输出Illuminate\Database\Eloquent\Relations\HasMany类型 - 修复路径：去掉
withDefault()、asSmallInt()等中间修饰，或改用whereDoesntHave()/whereHas()替代 - 兼容性提醒：Laravel 9.20+ 修复了部分关系代理对
exists()的支持，但自定义关系类仍需自行实现exists()方法
关联存在性检测真正难的不是语法，而是搞清「你要确认的存在性，边界到底在哪」——是数据库里有记录？还是符合业务状态？或是当前用户有权限看到？这些逻辑一旦混进 exists() 调用链，后面就很难拆解。
