Hyperf 的 with() 仅支持朴素 IN 查询，不解析闭包条件、不兼容 limit/take、嵌套预加载需手动确保关系定义且外键严格匹配，默认两条独立 SQL 易致内存暴涨。
Hyperf 的 with() 不支持闭包条件、不兼容 limit/take、嵌套预加载必须手动确保中间模型关系已正确定义——它只做最朴素的 IN 查询，复杂逻辑得拆出来手写。
Hyperf 的 with() 为什么不能写闭包条件
Hyperf 的 with() 底层调用的是 Builder::eagerLoadRelations()，它只负责收集关联模型、构造 IN 子句并批量查询，不解析也不执行你传入的闭包。传进去的闭包会被直接忽略，既不报错也不生效。
常见错误现象：User::with(['posts' => function ($q) { $q->where('status', 'published'); }])->get() 看似合理，实际查出的 posts 仍是全量数据，where 条件完全没起作用。
- 想筛关联数据？只能先查主模型，再用
load()手动加条件（但仍是 N 条 SQL） - 或改用
join()+select()显式拼接，自己控制 ON 和 WHERE - 若必须复用模型逻辑，可在关联方法里预设全局作用域（如
boot()中定义baseScope），但该作用域不会被with()自动继承，仍需手动调用
嵌套预加载（如 user.posts.comments）失败的三个硬性前提
Hyperf 不像 Laravel 那样自动推导嵌套路径，它要求每层关系都必须是「可独立查询的模型方法」，且外键字段名必须严格匹配默认约定（如 post_id、comment_id），否则中间层直接返回空。
- 检查
Post模型是否定义了comments()方法，并返回hasMany(Comment::class, 'post_id') - 确认
Comment模型中没有定义user()关系，或即使定义了，user_id字段在数据库中也必须存在且非空 - 避免在
with()中写['posts.comments.user']这种长链——Hyperf 会尝试调用$post->comments()->user()，但comments()返回的是HasMany实例，没有user()方法，运行时静默失败，user字段为null
with() 配合 select() 时字段丢失的真相
Hyperf 的 with() 默认走两条独立 SQL：主表查一次，关联表用 IN 查一次。如果主查询用了 select('id', 'name')，但关联模型没显式指定 select()，那关联表仍会 SELECT *，不仅浪费带宽，还可能因字段过多拖慢响应。
- 主模型只取部分字段时，关联模型也必须同步精简：
User::select('id', 'name')->with(['profile' => function ($q) { $q->select('id', 'user_id', 'avatar'); }])—— 注意：这个闭包虽不生效条件，但select()是有效的 - 外键字段（如
user_id）绝不能漏，否则 Hyperf 无法把profile记录和User实例正确配对 - 若关联表字段名与主表冲突（比如都有
id），Hyperf 不做自动别名，结果数组中后加载的id会覆盖先加载的，建议在关联方法里用->field('p.id as profile_id')显式处理
大数据量下 with() 内存爆掉的直接原因
Hyperf 的 with() 是纯 PHP 层组装，不生成 JOIN，也不去重。查 1000 个用户 + 每人 50 条订单，底层会发出 2 条 SQL：1 条查 users（1000 行），1 条查 orders（50000 行），PHP 要把这 51000 行全部读进内存，再按 user_id 逐条归并——不是数据库慢，是 PHP 自己撑不住。
- 单次查询主模型别超 500 条，超过请用
chunkById()分批处理 - 一对多关联数量必须限制：不能依赖
with('orders')，得先查User::get()，再对每个用户用Order::whereIn('user_id', [...])->limit(5)->get()手动控制 - 若需排序（如按最新订单时间排用户），
with()完全无能为力，必须改用join()+GROUP BY+MAX(created_at)聚合
Hyperf 的 with() 是轻量级预加载，不是魔法。它省不了复杂条件、压不住笛卡尔积、也绕不开外键一致性校验——所有“看起来该它干的活”，其实都得你亲手补上。
