软件自己天天用，就会发现最破坏心情的往往不是什么宏大的架构缺陷，而是两三个每天都要撞上好几回的交互小毛刺。在 2026 年 9 月 25 日到 27 日（v2.0.0-rc.18 至 rc.28）这三天里，我专门跟两个极其恼人的日常细节较上了劲。
点完圆圈先别跳行：给连点两下留出原地落点
TaskDock 里每条任务前面的状态圆圈，支持“待开始 → 进行中 → 已完成”三态循环点击。原本的逻辑很直白：任务列表是按状态分组排序的，你手指一点圆圈，状态从“待开始”变成“进行中”，列表立刻触发重排，这条任务“嗖”的一下就跳到了最上面的进行中分组里。
问题马上就来了：很多时候我只是想连点两下，直接把一条“待开始”的任务变成“已完成”。结果第一下刚点下去，任务行瞬间飞走了，第二下手指落下去的时候，正好点在替补上来的另一条无辜任务上。为了治好这个误触，我在 Commit d1721fc 里改掉了即时重排逻辑：点击状态圆圈后，任务颜色和图标当场变化，但所在行保持原地纹丝不动，直到你切换页面或者离开当前视图再回来时，才按新状态重新归组。
电梯弱网不再被踢下线：双副本预写与幂等续期
另一个让我头疼了好久的问题是手机端偶尔会莫名其妙掉登录。排查日志后才揪出真凶：当我走进电梯或地下车库、网络处于半死不活的状态时，App 刚好发起 Refresh Token 轮转请求。服务端其实已经收到了请求并签发了新 Token，同时把旧 Token 标为已消费；偏偏响应包在回传半路断了。等出电梯网络恢复，客户端拿着旧 Token 重试，服务端一看“拿已用过的旧令牌来刷”，当场触发重放攻击防卫，把整条登录会话全作废了。
在 Commit 1f67f03 里，我把续期流程改成了客户端主导的预生成模式：每次发起刷新前，客户端先在本地生成并双写 pending_refresh_token（同时写入 AndroidX 加密文件与 Keystore 互相校验修复），再把新令牌带给服务端做幂等落库。就算半路断网重试十次，两边对上的也是同一把钥匙，从此再也没被弱网无故踢下线过。