ThinkPHP 6 模型关联默认采用延迟加载机制，首页优化核心在于避免不必要的预加载（with）及模板中的隐式调用，而非配置不存在的 lazy 参数。
先说结论：ThinkPHP 6 默认即为延迟加载，无需额外配置->lazy(true)。优化重点在于控制器中移除不必要的 with 预加载，并警惕模板中的属性访问。
- 先定位：确认控制器是否使用了 with 强制预加载非必需关联
- 先做：移除控制器中非核心数据的 with 调用，保持模型关联定义默认即可
- 再验证：通过调试日志观察 SQL 查询次数，确保列表场景未触发 N+1 问题
核心机制说明
ThinkPHP 6 中，模型关联对象在定义时不需要特殊配置即可支持延迟加载。当通过属性访问关联数据（如 $user->articles）时，框架会自动触发查询；若在控制器中使用 with 方法，则会强制立即加载。
首页加载慢通常是因为在控制器中习惯性使用了 with 预加载了首页并未展示的数据，或者在模板列表中遍历了关联属性导致 N+1 查询。
实操步骤
1. 检查控制器预加载
打开首页对应的控制器方法，查找是否有类似以下代码。如果首页不需要文章数据，请移除 with 调用：
<?php
// 优化前：强制预加载了 articles，即使首页没用
$user = User::with(['articles', 'logs'])->find($id);
// 优化后：仅获取主模型数据，关联数据按需加载
$user = User::find($id);2. 确认模型关联定义
模型文件保持标准定义即可，无需添加不存在的 lazy 方法。确保关联方法返回正确的关联对象：
<?php
namespace app\model;
use think\Model;
class User extends Model
{
// 标准定义，默认支持延迟加载
public function articles()
{
return $this->hasMany('Article', 'user_id', 'id');
}
}3. 排查模板隐式调用
检查首页模板文件，确保没有意外遍历关联数据。如果在列表页循环中使用了 {$user.articles}，每次循环都会触发一次 SQL 查询。
验证方法
1. 开启 SQL 日志
在 .env 文件中设置 app_debug = true，确保能记录 SQL 执行日志。
2. 观察查询次数
刷新首页，查看页面底部调试信息或 app/runtime/log 目录下的日志。对比修改前后，确认移除 with 后初始加载的 SQL 数量是否减少。
3. 性能对比
使用浏览器开发者工具 Network 面板，观察首页请求的 Duration 变化。注意，如果后续业务确实需要关联数据，延迟加载会增加后续请求耗时，需权衡首屏与交互体验。
常见坑
1. 列表页的 N+1 问题
如果在首页列表中遍历了 10 个用户，且模板中访问了 $user->articles，原本 1 次查询会变成 11 次查询。这种场景下，建议在控制器中使用 with 预加载，性能优于延迟加载。
2. 接口序列化遗漏
如果接口返回 JSON 数据，延迟加载的属性若未访问则不会包含在序列化结果中。需在模型中配置 append 属性或在返回前手动触发加载。
3. 缓存一致性
延迟加载依赖模型实例。如果主模型数据被缓存而关联数据未缓存，多次访问可能重复查询数据库。建议结合 Redis 等缓存策略一起优化。
参考来源
- ThinkPHP 官方文档 - 模型关联：https://www.thinkphp.cn/doc.html