页面进入时安排了两次延迟动作：120ms 后复查布局，1300ms 后隐藏启动层。两次 `setTimeout` 都没有保存句柄，因此页面若在等待期间离开，无法主动取消；如果用户很快再次进入，旧一轮回调还可能与新一轮页面状态交错。本文不讨论延迟数值是否合适，而是把回调的所有权和有效代际补完整。

商城列表把 `id:status:progress` 拼成 `ForEach` 的 key。订单每推进一次，key 也跟着变化，框架看到的就不再是“同一订单更新了内容”，而更像“旧身份消失、新身份出现”。与此同时，订单 ID 只靠 `Date.now` 生成，还留下同一毫秒创建时的碰撞窗口。本篇分别处理渲染身份和业务身份，避免用展示字段弥补 ID 设计。

商城列表已经允许同时出现多笔订单，送印调度却仍只记一组 timer、订单 ID 和截止时间。第二笔送印到来时，代码先推进上一笔，再把这组字段整体覆盖；表面上是“继续处理”，实质上是用新订单改写旧订单的运行上下文。本文把问题收窄到一个核心：订单是多实例，调度状态也必须按订单区分。

订单数组已经写进 Preferences，因此进程重启后仍能看到 `pending` 订单；但负责推进它的订单 ID 和截止时间只保存在页面字段里。页面消失时计时句柄和字段一起消失，重新打开只能恢复“待处理”这个结果，却恢复不了“何时应该进入下一状态”的依据。

切片模拟把“定时器回调了一次”直接换算成“进度增加 5%”，再预约 42ms 后执行下一次。只要回调发生得不准时，进度对应的真实时长就会改变：回调密集时显得快，系统繁忙或后台节流时又会拖长。本文改用经过时间推导业务进度，让定时器只负责唤醒刷新，并明确后台继续或暂停的产品语义。

打印机弹窗里有名称、IP 和端口三个输入框，但“开始连接”并没有消费这些输入来判断端点是否成立。按钮直接进入成功回调，随后创建订单并展示连接成功。于是页面上的“成功”只说明点击事件走到了回调，并不说明输入合法，更不说明打印机可达。本文据此拆分端点解析、网络握手和订单创建三道门，强调输入合法不等于设备可达。

ArchiveRadarCanvas 的五个 Prop 都 Watch 同一个回调。一次预设切换若连续更新五个参数，就可能多次进入 `drawOnce()`，而每次绘制都要清屏并重画网格、轴线、多边形和文字。单个 Watch 没有错，问题是多个字段共同描述一张雷达图，却没有共享一次“本轮只画最终状态”的调度。

ChaqiStarfieldCanvas 每 40ms 绘制 90 个粒子。`animate` 虽然是外部传入的 Prop，却只在启动时被读取，没有 Watch；因此页面仍可见时把它从 `true` 切到 `false`，已经创建的 interval 不会因为字段值变化而自动停止。

两处入口分别用 switch 把 1022400010—1022400014 映射成字符串。表面上只是几段提示文案，实际上取消、隐私、账号、网络、服务和未知错误需要的后续动作并不相同；如果组件只保存上一次 `errorText`，一次无提示的取消还可能把旧错误留在界面上。

HSP 的 ChaqiAgentButton 与 entry 的 ChaqiAgentPage 都声明同一个 Agent ID 和默认 queryText。当前值虽然一致，但“一致”只是这次静态检查的结果，不是工程结构能够持续保证的约束。下一次更换智能体或调整首问时，只要漏改一个入口，同一个产品就会出现两套智能体行为。