v1.9.2 · 更新提示看得见了 —— 点它就知道新版是什么
提示看得见了 —— 而且点它就能知道新版是什么
v1.9.0 加了版本落后检查,提示是版本徽记右上角一个 5px 描边圆点。维护者的反馈很直接:「太弱了,不够醒目,因为和背景色过于相似」。
量化之后确实是缺陷,不是克制:圆点填色 --brass-soft #E8D9B6 落在纸色背景 --paper #F4EFE6 上,对比度约 1.2:1,而 WCAG 对非文本元素的最低要求是 3:1。
改成实心「NEW」标签(≈4.1:1)
调研了四种做法并排比:
| 做法 | 对比度 | 结论 | |
|---|---|---|---|
| A | 描边圆点(v1.9.0) | ≈1.2:1 | 否决 · 看不见 |
| B | 实心「NEW」文字标签 | ≈4.1:1 | 选定 |
| C | WordPress 式红色计数药丸(#d63638 底 + 白字) |
≈4.8:1 | 否决 |
| D | sub2api 式整个徽记变 chip | ≈4.1:1 | 否决 |
选 B:① 过 3:1 门槛;② 「NEW」是文字,用户不需要先学会「圆点 = 有新版」;③ 刻意不用红色 —— 红在本项目里是告警语义(超支 / 负值 / 失败),借给「有新版」这件既不紧急也不是错误的事,会稀释真告警;④ 静态不闪,顶栏常驻动画跟「每月十分钟」的定位不合。
点提示 → 就地弹窗,不再丢去配置页
原来点徽记跳 /admin?tab=version。问题是用户此刻要的只有三句话,却被丢进配置语境,还得自己在页面里找那张卡。参考 WordPress 的更新提示层与 sub2api 的 VersionBadge(点徽记就地展开、不跳页),改成弹窗:
- 最新版本 ——
当前版本 → 最新版本+ 发布日期(落后 2 个及以上时额外标「落后 N 个版本」) - 该版本的 GitHub Release 链接 —— 新窗口打开
- 版本说明摘要 —— 从 release body 抽第一段正文(跳过标题与宫格图)
- 迁移判定 —— 本项目独有。因为回滚只回 jar 不回 DB,这一格直接决定升级能不能退回来
- 底部保留「升级说明与开关」通往管理页版本卡(升级命令、隐私开关都在那)
弹窗是渐进增强:徽记的 href 仍指向管理页版本卡,JS 在时才拦成弹窗 —— 禁用 JS 的浏览器点了照样能用。手机端是从底部升起的抽屉,按钮撑满一行并避开 home indicator。
顺手修掉一个真 bug:升级完之后提示不消失
hasUpdate() 比的是缓存行里的 current,而那是上次检查时在跑的版本。你照提示升级完 jar、重启,这行还没刷新 —— 于是已经升到最新版的实例继续挂着 NEW,最长挂 24 小时到隔天定时器跑过。
latest 是关于 GitHub 的事实(可以旧),current 必须是关于本进程的事实(不能旧)。修法:读缓存时一律用正在跑的 app.version 覆盖 current。
覆盖动作放在服务内部而不是调用方:读缓存的入口有三个(启动预热 / 开关切换 / 检查后回写),第一版确实是让调用方传参的,结果只在预热那条路传了 —— 管理页把开关关掉再打开就把过期值复活了。
一个测不动的分支,怎么真的测
这功能有个结构性麻烦:开发机的在研版本号永远比已发布最新版更新,所以「有新版」那条分支在 beta 上根本不执行(v1.9.1 的 compare 404 bug 就是这么漏掉的)。
这次不靠手写假数据,而是临时构建一个 app.version=1.9.0 的 jar 部到 beta,让它真的落后于线上的 v1.9.1,再走完整链路:真实 GitHub 调用拿到 latest=v1.9.1 / behind=1 / 迁移 known n=0、真实摘要、Release 链接真能打开。双端无头 Chromium 验证不跳页 / 遮罩生效(像素采样背景被压到 rgb(153,149,141),正是纸色叠 42% 黑的预期值)/ 弹窗未被顶栏压穿 / Esc 可关。
验收完把 1.9.2 的 jar 部回去,徽记重启即消失 —— 那是上面那条修复的活证明。
升级注意
- 无 DB 迁移,回滚只回 jar
- 纯前端提示层 + 一处缓存读取逻辑,对现有数据零影响
- 升级后徽记若还挂着 NEW,重启一次即可(这一版就是修它)
设计文档:prd/v1.9.md 附录 · tech-design/v1.9.md §9
477 单元测试 · 551 黑盒回归 · 74 条 e2e 断言