依赖升级单

申请人：刘洋

批准人：张伟

目标版本：行政协同平台 V1.3.1

窗口：10月16日 22:00

结论：同意纳入 V1.3.1

一、升级结论

行政协同平台的服务端使用 Java 17。本次升级四处依赖，其中解析库和连接池是供应商公告要求的维护版本，日志库补上追踪号，数据库驱动与生产 MySQL 8.0 的时区解析对齐。张伟于 9月25日同意放入 V1.3.1。该版本只包含依赖，功能变更另按 10月8日的窗口发布。依赖窗口定在 10月16日 22:00，两台分批。当晚只升级这四处依赖。

二、依赖清单

解析库仍在补一条边界用例：请求体层数过深时直接拒绝。连接池和数据库驱动已在预发跑完。日志库计划在 10月10日前合入，合入后抽样 100 条日志，每条都要带追踪号和单据号。

三、兼容性验证

1. 刘洋在分支上跑完全部 1,240 条单元测试，失败 0 条。覆盖预订冲突、请假审批、访客到达和用品申领。
2. 王芳在预发回归 46 条用例，通过 46 条。包含重复点击申领、二维码到达和列表翻页。
3. 连接池在每台 20 个连接、预订 25 QPS 下保持 2 小时，泄漏告警为 0，活跃连接稳定在 6 至 9。
4. 数据库驱动升级后，请假的开始日期与页面选择的日期一致，抽查 20 条，时区均为东八区。

四、发布安排

10月16日 22:00 由周敏按一台一批发布 V1.3.1，两台间隔 8 分钟。第一台健康检查通过并观察 10 分钟后，再发布第二台。刘洋在线看错误日志和连接池。第一台出现连接等待升高，或预订错误率高于 0.1%，就停止第二台，并把第一台退回 V1.3.0。退回目标是 15 分钟内两台都回到升级前的依赖组合。

五、风险说明

解析库升级之后，结构不完整的请求体会被直接拒绝，并返回现有的参数错误码。近 7 日生产上这类请求为 0。王芳用企业微信回调保存的 5 份真实报文在预发回放，5 份都通过解析。日志格式变化只增加追踪号字段，值班检索单据号的方式保持不变。若 10月8日的功能发布顺延，本依赖窗口仍按 10月16日执行，当天的版本号改为在当时的生产版本上只叠加这四处依赖。