2026-06-26 工作日志
7月2号版本项目进展同步会
本次会议同步了各项目进展，明确了7月2号版本的优化方向，并对整体测试、上线评审及遗留问题进行了讨论。
小结
各项目进展同步
- 红绿中心：昨天的三个问题修复已上线。提示语功能将在7月29号完成验收测试。
- 智慧门店：7月2号版本将上线后端买单及主数据优化的门店接口，目前技术方案和开发均在正常推进中。
- TTS：压测环境验证按计划正常进行。
- 小智系统：新增了关于事业部及5段归属和权限的数据内容，已与主数据存在差异，主数据侧将导出清单供小智系统分析。
- 高德地图及运动出货性能优化：技术方案已通过，今日将部署新参数至测试环境进行测试。
- 资源出明细表下载：针对高峰期下载量大的问题，已参照活动中心的流式改造方案进行调整。
问题与风险
- iOS软件崩溃：将在7月2号UAT结束后，通过灰度包收集用户崩溃日志，以便进行定向优化。
- 费用类数据监控：因近期在做移动端SIT，此项目已暂缓，需重新评估其优先级。
上线与测试安排
- 7月2号版本：大部分遗留问题将在此版本中解决。
- 整体测试：7月1号将进行上线评审，要求各端准备好完整的测试材料，特别是本次包含较多技术优化项。
- 7月2号版本：内部测试将在今天收尾。
待办
- 上线评审材料准备：各端需根据模板补充7月1号上线评审所需的全部材料，特别是本次包含的技术优化项。——所有人
- 费用类数据监控：重新评估费用类数据监控的优先级并调配资源，以恢复相关监控工作。——吴菊
- 小智系统首页入口调整：针对小智系统首页入口调整的需求，需进一步评估影响并尽快给出结论。——陈思
- 盘点明细表下载优化：在7月4号上线时，需将盘点明细表的下载模式调整为与B站出口明细表一致的流式模式，并同步监控其性能。——张建利
奶酪项目接口需求对齐会
本次会议主要对齐了“奶酪”项目的接口文档，讨论了扫码、盘点及作弊上报等功能的具体需求，并明确了后续的优化方向和待办事项。
小结
接口需求与功能对齐
- 明确了“奶酪”项目需提供的核心接口，包括：码查询、扫码查证、盘点上报、盘点记录查询及作弊上报。
- 确认“作弊上报”接口将予以保留，尽管此前有疑虑，但经与“奶酪”侧确认，该功能仍在持续使用。
“奶酪”产品信息与查询逻辑
- “奶酪”的码信息与“液奶”基本一致，但具体格式需进一步确认，建议提供实物包装或示例码文件以便比对。
- 讨论了码查询的多种方式，如通过完整码、追溯码、批次号、序列号等进行查询。
接口设计原则与优化
- 强调了接口设计需遵循一致性原则，例如对于“作弊人”、“门店”、“仓库”等信息，应统一处理逻辑（如必填项、默认值），避免出现前后不一致的情况。
- 提出了优化建议：对于已由上游系统（如营销活动中心）提供并确保有效的信息，应直接使用传入值进行落库，避免不必要的二次查询，以提升性能。
“作弊上报”接口设计
- 明确了“作弊上报”接口支持一次性上报多个码的作弊信息。
- 讨论了作弊人信息的处理逻辑，应与“液奶”项目保持一致，即优先使用系统内有效状态的人员信息，若不存在则使用传入信息作为兜底。
“盘点”相关接口
- 明确了盘点上报接口需包含新的“盘点单据照片”字段。
- 讨论了盘点记录查询接口，需返回详细的盘点数量、有效数量、异常数量及各品牌、生产信息等统计数据。
“活动升级”相关接口
- 提及了“活动升级”项目也涉及接口变更，需与“奶酪”项目进行最终的澄清。
待办
“奶酪”产品信息确认
- 粱健需向SIV团队确认，前端是否已支持根据批次号等信息查询码的功能。
- 张喜需向TDS团队获取“奶酪”的实物包装或示例码文件。
接口文档优化与确认
- 粱健需根据孔玮的建议，移除“活动升级”接口中不必要的枚举值。
- 粱健需与“奶酪”侧确认“作弊上报”接口中“作弊人”、“门店”、“仓库”等信息的必填及默认取值逻辑。
- 粱健需与“奶酪”侧确认“货品经销商编码”字段是否为必要字段，若非必要则移除。
“活动升级”接口最终确认
- 马奇需与“明飞”团队对齐“活动升级”相关接口的变更，并组织最终澄清会议。
内部流程优化
- 马奇会后需组织相关人员，将本次会议中所有待确认的事项整理成Excel表格，以便内部统一确认。
高德地图连接优化与五段码改造方案评审
发言人：张喜、潘玉平、王建朝、粱健、贾继伟等9人
本次会议评审了高德地图连接池化改造方案，确立了测试环境验证与参数对齐策略；通过了盘点数据修复与GPS限流优化方案；明确了五段码改造的冗余存储逻辑及历史数据兼容方案；并针对签收数据覆盖问题进行了初步排查。
小结
高德地图连接优化方案评审
- 连接池化改造：将原有的无池化 HTTP 请求改造为使用 OkHttp Client 的有池化连接，预计将连接获取时长从 200ms 降低至 20-50ms。
- 参数配置调整：设定最大空闲连接数为 200，连接超时时间为 2 秒，读取超时时间为 5 秒，以降低超时率。
- 协议支持确认：确认 OkHttp 原生支持 HTTP/2 协议，若高德地图服务端支持，将自动启用多路复用以提升并发性能。
- Keep-Alive 参数对齐：王建朝指出需确认高德地图服务端的 Keep-Alive 时长，避免因客户端（300 秒）与服务端（如 60 秒）配置不一致导致连接被服务端提前回收引发的异常。
- 验证方案补充：鉴于测试环境无法完全模拟生产环境压力，要求补充详细的验证方案，需包含逻辑可行性测试及性能压测。
盘点数据修复与 GPS 限流优化
- 盘点数据重复修复方案：将原本在消息消费环节循环调用的 RPC 接口（自增盘点次数）前置到订单提单环节，改为批次提交，确保一个订单仅调用一次 RPC；RPC 调用与盘点事务绑定，若 RPC 失败则触发事务回滚，防止因网络抖动导致的消息重试及数据重复。
- GPS 限流优化方案：将每个码单独调用高德地图的逻辑，改为在订单提单时统一获取经纬度并存储，后续消费环节直接复用订单中的行政区域信息；预计可将单笔订单（如 1000 个码）的高德调用次数从 1000 次降为 1 次，彻底解决限流问题。
五段码改造与数据同步方案
- 主数据接口调用：通过 TDS 获取地址 ID，调用主数据接口获取五段 ID 及名称，并存入本地缓存（默认 10 天）以降低主数据压力。
- 双重存储策略：在订单表和码表（Code Info）中均冗余存储五段信息，确保即使数据库同步延迟，也能通过订单数据兜底。
- 历史数据兼容：对于历史数据，计划在报表侧做兼容处理，若码表无数据则回退至原逻辑查询，待数据自然消化。
- 上线时间节点：确认 702 版本上线，需与主数据团队确认接口发布节奏，确保双方同步。
其他业务逻辑与遗留问题
- 生产时间校验逻辑：根据国家质监局要求，产品生产时间必须满两天后方可进行出货或签收操作，系统需增加相应的时间校验逻辑。
- 签收数据覆盖问题排查：发现签收数据处理完成时间晚于签收激励数据的 Read 时间，导致激励数据被覆盖为空；确认该问题并非本次评审核心，会后由相关团队自行确认修复方案。
待办
- 补充高德地图连接优化的验证方案（含逻辑与压测）。——潘玉平
- 调研高德地图服务端的 Keep-Alive 连接释放时长，并与客户端配置对齐。——潘玉平
- 在五段码查询 SQL 中增加
limit 1限制，防止主数据异常导致的多条数据问题。——张喜 - 确认主数据接口是否能在 702 版本前上线，确保双方发布节奏一致。——张喜
- 会后确认签收数据被覆盖问题的具体修复方案。——孙世文、马奇