with() 分页报错因懒加载返回数组而非 Query 对象，正确写法是先构建主模型查询再 with() 预载入最后 paginate()；关联只读不影响预载入，但字段隐藏会导致关联数据为空，需检查 $hidden/$visible 配置。
关联字段只读时，with() 分页会报错“Call to a member function paginate() on array”
这是因为 with() 默认是懒加载，返回的是已查出的关联数据数组，不是 Query 对象，没法直接调用 paginate()。你不能对 $list->with('author')->paginate() 这样写——$list 是结果集，不是查询构造器。
正确做法是：先构建主模型查询，再用 with() 预载入关联，最后在同一个 Query 实例上调用 paginate()：
$list = User::with('profile')->where('status', 1)->paginate(10);
注意：with() 必须放在 where() 等条件之后、paginate() 之前；它不会改变主表查询逻辑，只是追加 JOIN 或子查询拉取关联字段（取决于配置和关联类型）。
- 如果关联模型字段设为只读（如
protected $readonly = true;），不影响预载入，只影响后续save()操作 - 若用
hasWhere()或闭包约束关联条件，需确保闭包内不调用写操作方法 - TP6.1+ 支持
withCount()和withSum()，但它们不参与分页主查询，只额外统计，别误以为能替代with()
想让关联数据也独立分页（比如文章列表 + 每篇文章的 3 条最新评论），不能靠 with()
with() 是一次性查出所有关联记录，不适合“每个主项下关联数据单独分页”。这时候必须手动遍历 + 异步或延迟加载，否则会 N+1 或爆内存。
立即学习“PHP免费学习笔记（深入）”；
推荐方案：主列表分页查出 ID 列表，再批量查关联数据，按需分页渲染。例如：
$ids = Article::where('is_public', 1)->column('id'); // 只取 ID
$comments = Comment::whereIn('article_id', $ids)
->order('create_time', 'desc')
->limit(30) // 总共最多取 30 条，避免撑爆
->select();
然后在模板里用 PHP 数组分组（collection($comments)->groupBy('article_id')），配合前端 JS 控制每篇文章下的“查看更多评论”按钮触发新请求。
- 不要在循环里写
$article->comments()->paginate(5)，这是典型 N+1，且 TP 不允许在已实例化的模型上调用关联分页 - TP6 的
load()方法是运行时懒加载，也不支持分页，仅适合单条记录补查 - 如果必须服务端渲染完整分页，建议拆成两个接口：/api/articles（带分页）、/api/articles/{id}/comments?page=1
with() 分页时字段被过滤或丢失，检查 hidden 和 visible 配置
关联模型如果定义了 protected $hidden = ['password']，会导致整个关联数据为空（尤其一对一关联），看起来像“没查到”。这不是 bug，是 TP 的自动字段过滤机制在起作用。
验证方式：临时注释掉关联模型的 $hidden，看是否恢复显示。修复建议：
- 把不需要隐藏的字段显式写进
$visible，例如protected $visible = ['id', 'nickname', 'avatar'] - 若只需某次查询暴露敏感字段，用
append()动态添加，而非改模型配置 - 一对多关联（如
hasMany）受toArray()影响更大，可重写关联模型的toArray()去掉过滤逻辑（慎用）
TP6.3+ 使用 withAgg() 或自定义子查询做关联聚合分页，性能更稳
当需要“文章列表 + 每篇的评论数 + 最新一条评论内容”，用 withCount() 加 withMax() 组合容易出错（withMax('comments.create_time') 返回时间戳，不是整行）。这时应上原生子查询：
$list = Article::field('*, (SELECT content FROM comments WHERE comments.article_id = article.id ORDER BY id DESC LIMIT 1) as last_comment')
->where('status', 1)
->paginate(10);
TP6.3 支持 withAgg() 简化这类场景，但底层仍是子查询，需注意 MySQL 版本兼容性（5.7+）。
- 子查询中不能用
JOIN，否则分页 COUNT 会错（TP 对含 JOIN 的子查询 COUNT 处理不稳定） - 如果关联数据量极大（如单篇文章百万评论），优先走异步聚合表或 Redis 缓存计数，别硬查
- 分页总数（
total()）始终基于主表，关联子查询不影响 count，这点很关键
page=2，后端处理关联时若没统一上下文，很容易主表翻页了，关联数据却还是第 1 页的缓存结果。手动拼 SQL 或用 Db::query() 时尤其要核对绑定参数。 
