ThinkPHP 6.0+ 查询缓存需手动配置驱动并验证通路，否则 cache() 不生效；TP5.1 关联预载不拦截后续未声明访问，易致 N+1；读写分离下 useWriteConnection() 仅用于强一致性场景；分页性能依赖版本与 SQL 复杂度，须通过 explain 确认执行计划。
ThinkPHP 6.0+ 的查询缓存必须手动开启，否则 cache() 不生效
TP6 默认关闭查询缓存，哪怕你写了 $model->cache(true)->select()，实际也走不到缓存层。根本原因是底层缓存驱动未初始化，且 cache() 方法在无有效缓存配置时直接静默降级。
- 确认
config/cache.php中默认驱动（如'default' => 'file'）已配置且路径可写 - 在模型查询前显式调用
Cache::tag('user')->get('key')测试缓存是否通路，避免只依赖cache(true)的“假缓存”错觉 - TP6.3+ 支持
->cache('key', 3600, 'tag')三参数形式，但 tag 缓存需搭配TagCache驱动（Redis 必须启用），File 驱动不支持 tag
TP5.1 的 with() 关联预载存在 N+1 隐患，不是加了就安全
很多人以为 User::with('profile')->select() 就能避免 N+1，但若后续代码中对结果集循环调用了未预载的关联（比如 $user->posts），TP5.1 仍会触发新查询——它只缓存第一次预载结果，不拦截后续未声明的关联访问。
- 检查所有模板和逻辑中对关联属性的访问，确保所需字段都在
with()列表里，例如with(['profile', 'posts.comments']) - 慎用
hidden或visible模型属性控制输出，它们不影响查询行为；真正减少查询得靠field()配合with()，如with('profile')->field('id,name')->select() - TP5.1 不支持嵌套
where条件下自动优化关联查询，比如with(['posts' => function($q){ $q->where('status', 1); }])会强制生成 JOIN，大数据量时比两条独立查询还慢
TP6.1+ 的 useWriteConnection() 在读写分离下容易误用
当主库压力大、从库延迟高时，有人会为“保险起见”给所有查询加 useWriteConnection()，结果反而把本可走从库的流量全压向主库，放大瓶颈。
- 仅在明确需要强一致性场景使用：如刚执行
insert()立即查出新记录，或事务内读取自身写入数据 - TP6.1+ 的
Db::connect('read')才是主动指定从库的正确方式，useWriteConnection(false)并不等价于切到从库，它只是取消“强制主库”，仍可能因负载策略落到主库 - 检查
config/database.php中'read_master' => true设置：若为true，即使没写useWriteConnection()，首次查询也会打到主库做探活，影响从库分流效果
跨版本分页性能陷阱：TP5.1 的 paginate() 和 TP6.2+ 的 paginate() 底层差异极大
TP5.1 分页默认先查总数再查数据，两次 SQL；TP6.2+ 默认改用子查询优化（SELECT * FROM (SELECT ...) LIMIT），但前提是没用 group、union 或复杂 having——一旦触发回退机制，就会悄悄切回 TP5.1 式双查，且不报错。
立即学习“PHP免费学习笔记（深入）”；
- 用
explain看分页 SQL 执行计划，确认是否出现Using filesort或Using temporary，这是回退信号 - TP6.2+ 可通过
paginate(15, false, ['query' => request()->param()])的第二个参数false强制跳过总数查询（适合列表不要总条数的场景） - TP5.1 若需绕过总数查询，只能手写
limit+offset，但要注意getLastSql()不显示真实 limit 值，得用buildSql()看原始语句
版本特性不是开关，是约束条件。同一个方法名，在不同版本里可能走完全不同的执行路径，甚至同一版本不同配置下行为也分裂。盯住 SQL 日志和执行计划，比记文档更可靠。
