人在成都，页面却显示南充：天气定位的调整记录

天气模块最初只是首页角落的一块小信息：地点、天气和温度。接入实际数据后，却出现了一个明显的问题——人在成都龙泉驿区，页面显示的地点却是南充。

这时，界面虽然有了“真实接口”，展示出来的信息却没有符合使用者的实际情况。

返回了结果，不代表结果适合直接展示

定位和天气查询是两个步骤：先确定地区，再查询这个地区的天气。如果地区本身就不准确，后面的天气即使查询成功，也可能不是访客想看的内容。

当时的现象能够说明：这一次定位来源给出的地区与实际所在位置不一致。但仅凭页面结果，不能进一步断定偏差具体发生在哪一层。

因此，调整的重点没有放在把默认城市写死成成都。那样只会让当前使用者暂时满意，却无法服务其他访客。

把定位来源区分开

当前后端支持三条地区确定路径：

| 来源 | 本项目的处理方式 |

| --- | --- |

| IP 查询 | 使用查询结果中的地区代码继续获取天气 |

| 设备定位 | 将传入坐标转换后查询地区信息，再获取天气 |

| 手动地区 | 根据填写的地址查询地区，要求结果足够明确 |

三种路径没有被包装成同一种“精准定位”。页面需要让人知道，这个地点来自自动查询、设备定位，还是自己的手动选择。

当结果不合适时，访客也能通过重新定位或手动选地区进行纠正。

刷新之后，选择不该消失

另一个问题出现在刷新页面时：地点刚刚调整好，刷新后又回到了不正确的地区。

对应的处理是保存地区选择及其来源，并在后续加载时恢复。这里不只是记住一串城市文字，还需要区分“手动选择”与“上次设备定位”等状态。

这让纠正结果成为一种能够持续生效的选择，而不是一次性的界面变化。

第三方接口失败时怎么办

当前天气服务包含有界缓存和失败冷却。缓存用于减少重复查询，失败后短时间内不持续回源，避免不停触发相同请求。

数据字段也会经过校验：

- 地区代码不完整时，不继续拼接一个看似正常的天气结果。

- 温度无效时，不随便补成某个数字。

- 地区无法确定时，返回可理解的提示。

- 手动地址存在多个匹配结果时，提示补充完整省、市、区县。

相比显示一个错误却完整的卡片，明确表示“暂时无法定位”更容易让人理解当前状态。

目前仍然没有解决所有误差

这些调整提供了来源说明、纠正入口和选择恢复，但不能保证每一次自动定位都准确。

天气卡片里的数据也带有服务方的发布时间，不应该被理解成持续更新的现场测量。阅读这些信息时，需要同时看地区来源和数据时间。

这次调整留下的经验

一个功能的完成标准，不能只有“接口通了”和“页面有数据”。

对天气模块而言，至少还需要回答：

1. 这个地点从哪里来？

2. 如果不对，使用者能怎样纠正？

3. 刷新之后，纠正是否还有效？

4. 查询失败时，页面会不会误导人？

这些问题让一个小小的天气卡片，变成了一次关于信息可信度和交互反馈的练习。

---

系列：雾海手记开发记录 · 02。

页面实录


当前博客天气区域的实际截图。截图时手动选择了成都龙泉驿区，地区来源与天气发布时间会一起显示；这不代表浏览器自动定位一定准确。