“检测成功”四个字并不能回答第二天的排障问题：昨天究竟测过没有，返回的是 HTTP 错误，还是请求根本没到服务器？上一版“链路镜”能在页面上展示结果，却只保存当前一次检测状态。用户离开页面、应用进程被系统回收后，之前的判断依据就没有了。网络诊断工具需要适量的历史信息，但它同样不能变成一份无意识收集网址、凭据和响应内容的日志仓库。 这一次不另起炉灶。项目继续使用 NetworkProbePage.e

用户点开“应用内提示”，开关瞬间变蓝；回到桌面、重新打开应用，开关却又变回灰色。更麻烦的是，界面可能一直显示“设置成功”，而底层 Preferences 的写盘操作已经抛出了异常。这不是颜色主题的小瑕疵，而是屏幕状态与持久状态谁说了算的问题。一个设置页面看起来只有三行开关，真正决定质量的却是初始化时机、同一批设置的存储边界，以及失败时怎样向用户交代。 这篇使用独立的小应用“简序设置”，不接入此前工

能耗看板收到七条记录，画面上的七根柱子就一定可信吗？“衡能”第四篇已经可以点选周五，明细显示 6.6 kWh，同时用 requestSeq 避免旧结果回写。可在实际接入数据时，新的难题并不是请求顺序，而是结果本身可能缺一天、重复一天，甚至包含负数或非有限值。这时让柱图直接参与求和，界面可能仍然很漂亮，却会把含义错误的数据包装成可靠结论。 “衡能”沿用 EnergyBar { key, label,

巡检员完成了两项检查，刚要走出配电房就切到了地图应用。重新进入“巡点台”时，页面还保留着“已选两项”的样子，但这并不证明两条记录都已经落盘。若此时把内存中的勾选状态直接恢复成“提交成功”，现场人员可能以为工作已经记录，实际上前一次写入还停留在队列里。这个细节把离线工单的两个概念分开了：界面离开前显示了什么，以及持久化层最后确认了什么。 前四篇沿用同一个 Ticket { id, title, do

网络检测页出现一个红色的“失败”提示，看似已经结束了这次检测，实际上却把最有用的信息藏起来了。用户看到 HTTP 503 与开发者看到 2300006，两者的排查入口完全不同：前者意味着收到了服务器的 HTTP 响应，后者则指向域名解析阶段。把所有情况都统一写成“请检查网络”，会让一个诊断工具在关键时刻失去意义。 “链路镜”系列前两篇已经固定了检测入口 https://example.com/、N

同样是一千多条数据，放进 List 与直接把所有子组件一次性创建出来，开发体验可能差别很大。真正棘手的地方又不在“滚动是否顺滑”这一个观察上：在列表开头插入条目时，为什么已有行可能被错误复用？删除一项后，为什么数据数组已经变短，界面还留着旧内容？如果用户勾选的是某个业务条目，而组件只记住了行号，排序之后它是否仍然表示同一个东西？ 这篇用一个独立的本地物资盘点应用“物盒清单”回答这些问题。它与此前的

图表能显示七根柱子，并不意味着它可以可靠地交互。用户在“衡能”看板里选中“周五”，明细卡片显示 6.6 kWh，随即切换到“今天”，如果页面仍保存着旧的 selectedIndex = 4，四个时段的新图表根本没有第五项。更隐蔽的情况是：用户选择某根柱子后点击刷新，旧请求晚返回，页面虽然凭借上一轮的 requestSeq 挡住了过期响应，却没有处理“选中项是否仍属于当前数据快照”这个新问题。 “衡

工单页面有三个“完成”按钮，单独点每一个都能保存。现场人员却常常一次巡检多台设备：勾选“配电柜温度复核”“应急灯回路确认”和“网络机柜标签核对”，连续点两次“批量完成”，或者在第一次提交尚未结束时修改其中一条标题。单次操作路径看起来没有错误，重启后却可能只有部分工单被改动，页面仍说“全部成功”。这不只是按钮防抖问题，而是多个写盘意图之间缺少确定的执行顺序与失败边界。 “巡点台”前三篇保留了一组刻意

用户在“链路镜”里点击了“开始检测”，两秒后觉得没有必要，按下取消。页面立即回到可操作状态。没想到又过了几秒，原先那次 HTTP 请求完成，结果把“已取消”改成“可访问”。从界面上看，这像是一个小闪烁；从诊断工具的可信度看，它意味着应用把用户已经撤销的操作重新算作有效结果。 第一篇建立了固定检测目标 https://example.com/、idle/loading/ok/error 状态和 ht

一个倒计时组件，最容易写成 remaining--：创建一个每秒运行的定时器，数字从 120 递减到零。打开页面盯着它看，大多数时候没有明显问题；按下 Home 键、切换应用、锁屏一段时间再回来，剩余时间却可能仍接近离开前的数字。问题不是 Text 没有刷新，而是定时器触发次数并不等于真实经过的秒数。 这篇把需求放进一个独立的“专注计时”页面。我们只做两分钟倒计时的开始、暂停、继续和重置，不连接服