后端修好了，测试通过了，接下来是不是就能部署？
这次发布前，我反复问的是另一个问题：App Store 上的那些版本，能继续用吗？
GFocus、GPlay、GBalance、GMemor 都有已经发布的客户端。让所有 App 改完代码、提交审核，再等用户更新，成本很高。而且即使新版本通过审核，也不会让旧版本立刻从用户手机上消失。
服务端的发布节奏，不能只围着当前客户端源码转。
先把“兼容”说具体
“兼容旧 App”太宽泛，不适合直接当验收结论。我先拆成几条可以检查的边界：
- 原有路由和请求字段继续可用。
- 成功响应的包装、令牌字段和用户信息保持原有契约。
- 已存在的账号和有效购买权益，不因服务端实现调整而改变归属。
- 匿名购买、登录后恢复等旧流程，不被新的校验规则无意截断。
- 遇到临时服务故障，不能把“暂时无法确认”写成永久没有权益。
这些约束不意味着接受错误请求。例如 Apple 登录的身份，应以验签后的身份为准。旧请求里的身份字段可以保留，但字段冲突时不能因为“旧版兼容”就继续相信客户端提供的值。
接口形式可以兼容，信任边界仍然需要修正。
三条路，只有一条适合这次
第一条是直接升级协议，要求客户端同步修改。新旧实现都干净，但发布被多个 App 的审核和用户更新节奏绑住。
第二条是为了旧客户端，长期保留所有宽松行为。短期省事，却会把已经发现的问题也一起保留下来。
第三条是保持外部契约，修正服务端内部行为；确实依赖客户端修改的部分，单独安排过渡。
这次采用了第三条。修复可以分批发布，前提是先明确每一批会影响哪些请求和用户状态。
并发刷新，是一个典型例子
用户打开 App 时，几个请求可能同时发现访问令牌过期。它们会接近同时地发起刷新。
如果服务端让每个刷新请求各生成一组新令牌，客户端最后保存哪一组就可能取决于响应先后顺序。如果只允许第一个请求成功，又可能把合法的并发请求或网络重试当成异常。
这次的处理方式是：同一次旧刷新会话只能产生一个后继结果，合法的短窗口重试拿到同一个结果。相关状态放在共享 Redis 中，让不同服务实例也能做出一致判断。
这里有一个重要限制：短时间的重试兼容，不能解决客户端长期不保存新刷新令牌的问题。
因此，遇到这类客户端行为时，需要核实实际发布包，并保留明确的过渡边界。这次 Admin 与 admin-web 的刷新路径就没有直接套用普通 App 的严格轮换方案。
不能把一个看起来更安全的新实现，机械地推给所有调用方。
购买权益也需要保持旧语义
订阅不是简单的“到期时间晚于现在”。终身购买没有订阅到期时间；匿名购买和登录用户的记录也不是同一种关系。
如果新实现把没有到期时间的权益一律判成无效，接口即使还返回原字段，用户也已经感受到了破坏性变化。
这次同时检查了终身购买、匿名恢复、通知顺序和交易归属。旧通知的退款，应该影响对应交易，不能把之后另一笔有效购买的权益一起撤掉。
这也是我越来越重视行为回归的原因：字段没变，只能证明接口形状没变。
当前源码、旧请求和上架包，是三种证据
检查当前 Flutter 源码，可以知道现在的调用方式，但不能证明 App Store 上的二进制具有相同行为。
服务端的旧请求契约测试，可以检查字段和响应，也不能代替手机上的完整业务操作。
所以这次验收分别记录了：
- 服务端单元测试和旧接口契约回归。
- 使用隔离 MySQL、Redis 的并发与恢复测试。
- 实际设备上的操作，以及安装包的来源。
- 生产配置、迁移记录和上线后的健康检查。
真机上的 GPlay 确认为 App Store 安装。部分其他验证使用 Xcode 安装包，GBalance 的沙盒购买使用了指向隔离服务的 QA 包。这些结果各自有价值，但不能合并成“所有上架版本、所有业务路径都已经验证”。
沙盒购买也不等于真实生产购买、续期和退款都完成了验收。
兼容接口，不等于旧会话永远有效
这次发布还包含经过确认的凭据轮换，其中包括 JWT 签名密钥。旧密钥签发的令牌会失效，用户可能需要重新登录。
这和“客户端是否需要更新协议”是两个问题。原有客户端仍然可以使用登录接口，但旧会话不能因为兼容目标而无限保留。
因此，这次发布不能被描述成“所有用户无感升级”。准确的说法是：没有要求客户端重新上架，同时按受控发布安排了凭据轮换和重新登录的影响。
我现在怎样判断能不能发
我会先问：旧请求还能不能得到正确结果？已有账号和购买记录会不会被错误改写？哪些路径有实际上架包证据，哪些只有源码或隔离测试？这次是否还有凭据、数据库或持久化配置变化？
把这些答案分开记录，比一句“测试全部通过”更有用。
这次服务端已经完成生产发布，关键在线检查通过。但实际上架客户端的完整业务路径、退款和真实生产购买仍未全部验收，也没有做生产压力测试。
我接受的是有证据、有边界、能继续观察的发布，而不是把“兼容”当成一句不会出错的保证。
购买状态的具体处理，另见订阅系统最难的不是付款。