一次请求承载多个内容区块
首页数据加载流程读取当前地区信息，再请求首页数据。首屏没有实时位置时，可以使用缓存或默认城市编号继续加载；定位成功后定位状态再触发列表刷新。
返回数据被拆成轮播图、精选内容、推荐内容、分类内容和关联条目等集合。实现没有在 UI 的 build() 中直接解析 JSON，而是调用顶层解析函数 parseLandingData() 将各列表转换成模型。
把 CPU 密集的解析放进 compute
Map<String, dynamic> parseLandingData(Map<String, dynamic> raw) => {
'banners': List<Map<String, dynamic>>.from(raw['banners'] ?? []),
'featured': List<Map<String, dynamic>>.from(raw['featured'] ?? []),
'content': List<Map<String, dynamic>>.from(raw['content'] ?? []),
};
Future<Map<String, dynamic>> loadLandingData(
Map<String, dynamic> responseData,
) {
return compute(parseLandingData, responseData);
}网络 I/O 本身是异步的，不需要因为 await 就额外放到 isolate。适合移出的部分是大量同步 JSON 转模型工作。传给 compute 的函数和数据需要可传递，因此 parseLandingData() 放在文件顶层，输入也是普通 Map/List。
解析完成后，控制器再将模型列表赋给状态并更新 GetBuilder。热门列表还会按条目 ID 从其他列表补齐推荐标记和展示字段；只有热门数据本身没有值时才填入，不覆盖已有值。
页面不活跃时停止轮播
首页控制器的 setPageActive() 维护当前 Tab 是否活跃。活跃时启动轮播定时器，离开时停止。定时器每次切页前检查 PageController.hasClients，避免控制器还未挂到 Widget 树时发起动画。
这里值得区分两种工作：轮播图定时器明确受页面活跃状态控制；首页的其他动画控制器则在 onInit() 中启动。若首页被保留在 Tab 栈中，可以进一步评估非活跃时是否也暂停那些持续动画。
数据缺失和失败如何呈现
接口返回非成功 code 时，当前方法记录错误并在 finally 中更新首页；异常也会被捕获。文章卡片的空态和加载状态由页面读取控制器的 isLoading、列表状态来决定。审查时应继续核对部分字段为空、服务端返回空列表以及重复刷新时的表现。
性能优化不能只看是否使用了 compute：小数据量时 isolate 的消息传递也有成本，是否值得要用真实列表规模和低端设备帧耗时判断。该实现提供了一个可观察、可维护的解析边界，但不能仅凭代码推导出具体性能提升百分比。
经验总结
compute 这段我摘出来实际跑过：parseLandingData 放在顶层、输入输出都是普通 Map/List，传给 compute 的约束都满足，断言全过。但我要泼一盆冷水：我自己的项目里还没遇到需要 compute 的数据量。isolate 不是免费的，spawn 和消息序列化都有成本，几百条以内的小列表直接在主 isolate 解析更快，帧耗时根本看不出差别。真要做，先用 DevTools 看帧耗时，确认解析是瓶颈再移出去。“用了 compute”不等于”性能优化了”，没有基线数据的优化都是玄学。轮播图那块 setPageActive() 的思路我认同：页面不可见就停定时器。切页前先判 hasClients，Tab 快速切换时能救命——这条是示例应用代码里已经写对的，照抄就行。
小结
首页的数据路径是“异步请求、后台解析、控制器赋值、局部刷新”，位置状态则决定推荐数据所在区域。拆开 I/O、模型解析和动画生命周期后，首屏卡顿或内容不一致的问题更容易分别定位。