2026-10-21 工作日志
酸奶事业部计费钱包PRD评审
发言人：郑然然、赵敏、孔玮、李强、贾继伟等 6 人；主题：本次会议对酸奶事业部计费钱包 PRD 进行了评审，明确了仅支持陈列券单张核销及 H5 端接入方案，并重点讨论了 12 月中旬多项目并行的测试资源紧缺问题。
小结
1. 业务背景与核心功能范围
- 仅支持卡券功能：本次酸奶事业部接入计费钱包仅使用卡券功能，不涉及红包与积分功能。
- 仅支持陈列券单张核销：系统仅支持陈列货补券与陈列代金券；因券中心不支持批量核销，本次仅提供单张券核销，无多选或全选功能。
- 前端 H5 端接入：本次需求仅涉及前端钱包 H5 层面功能，不涉及计费管理后台服务端相关功能。
2. 卡券展示与核销流程
- 按门店维度展示与切换：系统默认展示当前门店的待核销券，支持通过控件切换门店查看对应券信息。
- 核销状态分类展示：卡券列表默认展示待核销券，支持通过 Tab 切换查看已核销与已过期记录，并带数量角标。
- 生成核销码与轮询状态：用户选择单张券生成核销码后，系统通过轮询机制实时更新核销状态；关闭页面后返回列表时也会通过查询接口更新状态。
- 陈列货补券签收核销：点击陈列货补券可进入详情页进行签收核销，需选择数量，且一张券只能核销一次。
3. 系统对接与历史问题确认
- 复用智慧门店小程序链路：本次接入智慧门店小程序，除新增酸奶事业部编码外，UI 参数与接入流程与以往保持一致。
- 仅对接券中心货补券服务：本次仅调用券中心的货补券服务获取相关数据，不接入其他类型的券。
- 贴码活动与卡券系统相互独立：经确认，消费者扫码的贴码活动属于物码链路，与本次评审的卡券钱包系统是两个独立系统，不涉及本次迁移。
4. 上线排期与测试资源现状
- 多项目集中在 12 月中旬上线：酸奶事业部计费钱包、冷饮事业部及积分逆向项目均计划在 12 月 17 日至 20 日期间上线。
- 当前测试资源严重不足：目前仅有丁聪一名测试人员负责，面对多个项目并行测试及积分逆向庞大的测试工作量，现有资源难以覆盖。
- 需提前引入测试资源：为避免年底新人入场后因不熟悉业务而无法协助，需在 11 月前提前引入测试人员熟悉内容并介入用例评审。
5. 协同与推进安排
- 酸奶项目协同方为数字化结案中台：本次酸奶计费钱包需求由数字化结案中台主导协同，目前尚未开展联调工作。
- 后续需拉齐协同方推进：针对当前协同端进展缓慢的情况，后续需拉通相关协同方共同推进项目进度。
6. 后续建议（评审中识别，待补充确认）
- 「单张核销」是券中心能力约束下的方案，不是需求主动选择：酸奶侧明确没有多选/全选，而冷饮二期（10-20 评审）同期的门店类角色方案是「新增全部核销 + 批量核销按钮互斥」。两条路径并存意味着两个事业部的钱包 H5 交互不一致，且「全部核销 >500 张按到期时间排序只核销前 500 张」的语义问题不会出现在酸奶侧——建议明确「批量核销」能力是否具备在券中心侧统一落地的条件，否则同一套卡券中心对外呈现两套交互，事业部间体验割裂且后续维护成本翻倍。
- 轮询机制需在 PRD 中写明频率与终止条件：单张券核销状态靠轮询实时更新，PRD 未记录轮询间隔、超时上限与页面关闭后的兜底查询策略。建议把轮询频率、终止条件、异常兜底（查询失败时的用户可见提示）三项写进技术方案，避免实现侧各自取值造成体验不一致。
- 12 月中旬三条线上线集中，压测与联调资源需与开发资源一起盘点：当前仅识别出测试资源紧缺（1 人对 3 个项目 + 积分逆向），但联调环境、上线窗口与灰度顺序同样是串行资源。本次酸奶联调尚未启动，与 12-17~20 的上线窗口叠加，需与积分逆向项目排一次统一的窗口级排布。
待办
1. 测试资源盘点与引入
- 盘点测试资源，评估是否需要在 11 月前引入新的测试人员以应对 12 月中旬多项目并行的测试需求。——@李强
2. 协同推进
- 后续协同推进时，需拉通相关协同方共同开展测试工作。——@李强
关联与提示
- 与 10-20 冷饮二期需求评审并读（同为卡券钱包，但走两条不同路径）：10-20 冷饮二期定的是门店类角色「复用卡券中心 + 新增全部核销、按钮互斥、>500 张按到期时间排序只核销前 500 张」，本次酸奶定的是「券中心不支持批量核销，故只做单张核销、无多选全选」。两条同为卡券钱包 H5、同一个券中心底座，交互形态却相反。影响是：券中心的批量核销能力目前只存在于冷饮侧的方案描述里、未确认是否为券中心侧的通用能力；若不是通用能力而是冷饮侧局部实现，则「券中心不支持批量核销」这句前提本身需要修正——否则两套 PRD 对同一底座的描述互相矛盾，后续联调与回归会各按各的理解写用例。建议在券中心侧一次性确认批量核销能力归属。
- 与 10-19 积分逆向扣减方案的排期并读（同一 12 月窗口的资源叠加）：10-19 已定积分逆向相关方案并评估 12 月压测，本次确认酸奶计费钱包、冷饮事业部、积分逆向三个项目均落在 12 月 17 日至 20 日上线窗口内。影响是本次待办「盘点测试资源」不能只算测试人力：1 名测试（@丁聪）同时覆盖三个项目的功能测试、积分逆向的压测与回归，叠加 10-19 已识别的 12 月压测评估与 PRD 标注、报表与财务需求澄清等前置项，资源缺口在 11 月前若未补齐，最先崩的是压测与回归这两类需要连续时间的验证工作，而非 PRD 与用例评审这类可并行的文档工作。
盘点任务测试用例评审
发言人：刘莉、郑然然、余建新、宋洋、吴南林等 8 人；主题：本次会议主要评审盘点任务测试用例，明确了经销商与门店类型的盘点逻辑及异常场景，探讨了盘点中基础数据变更的校验机制，并确认了开发与测试排期。
小结
1. 经销商与门店盘点逻辑
- 盘点位置与人员限制：经销商类型任务支持在仓库、门店及其他位置盘点，且隐藏门店类型和范围选项；门店类型任务仅限门店盘点，不支持在仓库或其他位置查看该任务。
- 盘点结束与数据生成：经销商任务按门店或仓库维度结束，单门店结束不影响其他门店盘点；在仓库盘点会生成退货记录，在其他位置盘点仅生成盘点明细记录。
- 任务下发与门店变更：若任务下发时选择经销商并默认全部门店，中途新增或更改归属的门店仍可正常接收任务并进行盘点。
2. 异常场景与边界条件
- 经纬度异常校验：若营销助手无法获取经纬度，可选择其他位置盘点；若模拟经纬度为非法值（如国外或 0,0），系统需通过接口直接拦截。
- 报表经纬度显示：测试需重点验证报表中经纬度的显示是否准确，避免因换算错误导致距离计算偏差。
- 相同产品任务互斥：若已存在相同产品、相同月份的经销商类型任务，再创建相同条件的门店类型任务时，系统应拦截不允许创建。
- 多人员并行盘点：不同人员（如门店人员与经销商人员）同时盘点同一门店任务时，若其中一人先结束任务，另一人再次进入盘点时系统会提示任务已结束。
3. 激励发放逻辑
- 正常盘点发放激励：正常完成签收与盘点流程后，系统会按预期发放签收激励与售卖激励。
- 积分逆向处理：涉及积分逆向的场景需单独编写测试用例进行验证。
4. 盘点中基础数据变更的校验机制
- 当前仅进入任务时校验：目前系统在进入盘点任务时仅判断一次权限，扫码盘点过程中未对门店或经销商类型进行实时校验。
- 产品维度实时校验：扫码盘点时，系统会对产品信息是否符合任务要求进行实时判断，若扫描非任务指定产品则无法关联。
- 评估实时校验性能：技术团队需评估在每扫一题时增加门店和经销商类型校验的性能开销，若性能无影响则增加实时校验。
- 变更后任务可见性：若门店在盘点过程中被移出原经销商，且任务创建时未明确指定该门店，则该门店后续将无法看到该盘点任务。
- 已盘数据激励归属：若门店在盘点中途变更渠道类型导致不符合任务要求，已盘完的数据仍会正常记录并计入活动激励。
5. 开发与联调节点
- 后端接口联调：后端接口预计于明天上午具备联调条件。
- 前端灰度上线：前端计划于 10 月 29 日晚上推至灰度用户环境。
6. 测试策略与排期
- 测试时间窗口：若联调顺利，最早本周五可启动集成冒烟测试；UAT 测试计划于 10 月 27 日启动，28 日集中测试盘点任务，29 日推至 Pre 环境进行整体验证。
- 特殊场景测试安排：针对盘点中基础数据变更的特殊场景，若技术评估改动较大，将暂不纳入本次版本测试，顺延至 11 月份版本处理。
7. 后续建议（评审中识别，待补充确认）
- 「进入任务时校验一次」是本次最需要盯住的设计缺口：当前权限判断只在进入任务时做一次，扫码过程中不校验门店与经销商类型，而盘点是典型的长时段作业——期间门店被移出经销商、渠道类型变更都会导致「已盘数据」在事后无法归因。是否增加实时校验取决于性能评估，但即使实时校验不通过、决定不增加，也需要把「数据变更期间的已盘数据如何归因」写成明确口径，否则激励发放会带着一个说不清的尾巴。
- 激励发放与任务可见性出现了方向相反的结论：门店中途被移出经销商后看不到任务，但已盘数据仍计入活动激励。这两条同时成立时，需要确认激励归属对象是谁——按原任务归属的经销商发，还是按变更后的实际归属发。建议在 PRD 中显式写明，否则测试无法判定对错。
- 排期节点密到没有缓冲：后端明天上午联调 → 最早本周五冒烟 → 10.27 UAT → 10.28 集中测盘点 → 10.29 前端推灰度。同一天里既有「推至 Pre 环境整体验证」又有「晚上推灰度用户环境」，一旦 28 日集中测出问题，当天既没有修复窗口也没有回退窗口。建议把 29 日的灰度动作与 Pre 验证的通过结论绑定。
- 人员名单与品牌范围两项前置输入未到位：这两项直接决定任务创建时的过滤范围（10-20 评审已确认该功能要做），属于业务方输入而非技术方工作量，越晚拿到越会压缩 UAT 前的准备时间。
待办
1. 业务方前置输入
- 提供盘点任务涉及的具体内部及外部执行人员名单。——@业务
- 提供盘点任务涉及的具体品牌产品范围。——@业务
2. 测试用例补充
- 补充测试用例的预期结果，并附上测试截图。——@刘莉
- 补充积分逆向相关的测试用例。——@刘莉
- 补充经销商门店任务中，单门店结束不影响其他门店盘点的测试用例。——@刘莉
- 验证若门店在盘点中途因数据变更导致无法看到任务，其已盘数据是否仍会正常发放签收或售卖激励。——@刘莉
- 在 10 月 27 日 UAT 前，提供测试用例的体验码并加入郑平平中。——@刘莉
3. 技术评估与文档同步
- 评估盘点扫码时增加门店和经销商类型实时校验的性能开销，并确认具体实现逻辑。——@宋洋
- 根据技术评估后的校验逻辑，更新 PRD 文档以确保与最新逻辑一致。——@吴南林
关联与提示
- 与 10-20「盘点与数据修复方案评审」并读（同一天的方案侧到测试侧闭环）：10-20 已定「经销商任务支持门店、仓库和其他位置三种盘点方式，系统会校验经纬度是否在国内，以及仓库与经销商的归属关系」，本次测试用例把该校验具体化为「模拟经纬度为非法值（国外或 0,0）需由接口直接拦截」，并新增了 10-20 方案未覆盖的两个点——报表经纬度换算准确性（换算错误会导致距离计算偏差）与相同产品同月份的经销商/门店任务互斥拦截。影响是：10-20 方案里的「校验经纬度是否在国内」目前只在接口层做了拦截判断，但报表层的经纬度展示准确性没有任何方案覆盖，而它直接决定距离计算结果，属于方案缺口而非测试缺口。
- 与 10-20「盘点与积分需求评审」并读（需求侧到用例侧的闭环）：10-20 需求侧确认了经销商盘点位置可为仓库/门店/其他位置、其他位置按经纬度解析至街道维度汇总、仅门店产生的盘点数据纳入售卖激励计算。本次用例把激励口径落成可验证项（正常完成签收与盘点后按预期发放签收激励与售卖激励），并确认了「中途变更渠道类型导致不符合任务要求时，已盘完数据仍正常记录并计入活动激励」——这与 10-20 需求侧「仅在门店产生的盘点数据纳入激励」不冲突（地点未变，变的是渠道类型），但门店中途被移出经销商后已盘数据的激励归属仍未定，需 @吴南林 在更新 PRD 时一并写明。
营销活动中心技术方案评审（工厂状态字段修正 + PG 迁移接口）
发言人：（本场未记录）；主题：本次会议评审了工厂表状态字段取值修正方案与 PG 迁移接口推送方案，明确了字段修正与备份的实施要求、双接口并行推送的测试与对数策略，并安排了液奶接入底座方案的专题评审。
小结
1. 工厂状态字段取值修正
- 状态字段取值错误：工厂表原有的有效/无效状态字段取值错误；主数据推荐使用 cs code 作为有效无效的判断依据。
- 新增备份字段：计划将原有字段的值迁移至新字段备份留存，同时修正原字段取值，确保代码统一使用 cs code 判断。
- 无业务影响：该状态字段当前未在任何对外接口或业务逻辑中使用，属全量查询，本次改动不涉及业务层面。
- SQL 语法兼容性：底座数据库目前仍为 MySQL，需确保测试环境中执行的 SQL 语句语法兼容。
- 代码与注释规范：需在 SQL 脚本及 Java 代码中补充详细注释，明确字段映射关系及修改原因，避免后续维护人员误解。
- PG 迁移同步修改：底座数据库即将切换至 PG，本次字段修正逻辑必须同步更新至 PG 迁移方案，避免遗漏。
2. PG 迁移接口方案
- 废弃原分发方案：原定通过单一接口向两个 Topic 分发数据的方案存在影响业务的风险，已废弃。
- 采用双接口并行推送：最终确定由主数据提供两套接口并行推送数据；待正式切换完成后，旧链路及代码一并下线清理。
3. 测试与联调策略
- 测试环境单接口验证：考虑主数据双接口开发排期，测试环境先使用单接口验证数据接收逻辑与 PG 写入功能。
- 生产环境全量对数：正式切换 PG 前，需使用双接口与主数据进行全量数据核对，确认一致性无误后再执行正式切换。
4. 后续评审安排
- 液奶接入底座方案已就绪：液奶接入基础底座及门店中心的 PG 迁移技术方案已制定完成。
- 另行组织评审：因本次会议时间冲突，液奶接入底座的方案评审将另行组织专题会议进行。
5. 后续建议（评审中识别，待补充确认）
- 备份字段会把错误值长期固化在表里：本次把错误的历史值迁入新字段留档是安全做法，但错误值一旦以「备份」之名留在表结构中，下游若误当历史快照引用就很难清理。建议备份字段命名与注释明确写「2026-10 修正前原值留档，非业务字段」，并在 PG 迁移时确认该列是否同步带过去——避免在 PG 侧多出一个没人知道来由的列。
- 「测试单接口、生产双接口」是测得少、验得全：单接口验证只能覆盖数据接收与 PG 写入，双接口并行下的重复写入、幂等表现与旧链路残留，在测试环境无法暴露。建议至少在 Pre 或灰度环境补一次双接口并行推送 + 读取去重验证，否则全量对数一旦查出差异，定位成本会很高。
- 旧链路下线需挂明确的时间点与责任人：「待正式切换完成后下线清理」是条件句而非排期。建议为旧链路与旧代码的下线挂一个明确日期与责任人，否则新旧两条链路会并存到年底，届时排查数据问题将无法判断该看哪条链路的结果。
待办
1. 工厂字段修正与上线
- 评审结束后开始修改工厂字段逻辑，并在下周完成测试与上线。——@郝梓斐
- 修改代码时同步补充备份表逻辑，确保生产表数据有完整备份。——@郝梓斐
- 同步修改底座 PG 库的迁移逻辑，确保与 MySQL 库改造保持一致。——@郝梓斐
2. 主数据协同与提单流程
- 与建利老师确认测试与生产环境接口的提交流程，明确是否需要主数据配合提单。——@李明非
- 编写主数据配合事项文档，明确接口开发与推送的具体需求。——@宋洋
3. 专题评审组织
- 另行组织液奶接入基础底座及门店中心 PG 迁移方案的专题评审会。——@马奇
关联与提示
- 与 10-20「营销活动中心开发进度同步会」并读（同一底座切换主线的技术侧展开）：10-20 会上定的是「营销活动中心后续切换至基础底座，数据不再走主数据、直接走基础底座，计划 11 月 1 日启动基础底座与主数据的对数比对，需协调主数据团队开发资源并在 11 月前确定具体对数比对日期」。本次是这条主线的技术方案侧：底座从 MySQL 切 PG、主数据改为双接口并行推送、正式切换前做全量对数。影响在于两处对数口径必须先对齐——10-20 定的 11.1 对数是「基础底座 vs 主数据」的比对，本次定的是「双接口推送结果 vs 主数据」的全量核对，若 11.1 那次对数在双接口上线前做，它比的是旧链路的存量数据，与切换后的核对不是同一件事；反之若两次对数都做，须明确各自比对的是切换前存量还是切换后结果，否则「对过了」这句话在两次对数之间无法互相背书。
- 与 10-20「盘点与数据修复方案评审」并读（同一根因链的新增切面：原方案因影响业务而废弃）：10-20 的 TDS 码表修复方案推翻了原定的执行形态（由「上线流程内执行」改为脚本直接执行、SQL 改走分片键 code 批量更新），本次则推翻了原定的接口推送形态（由「单接口向两个 Topic 分发」改为「主数据提供两套接口并行推送」）。两处的共同判断依据是原方案一旦上线就会影响在跑的业务，而不是等出问题再回退。影响在于这类「先废弃再重建」的决策都自带一段双份代码并存期：本次的旧链路下线、旧代码清理目前只有条件没有日期，10-20 的三套修数脚本则执行门槛不一（最低那条是直接脚本执行）。建议把「方案变更后必须同时给出旧路径的退出条件与时间点」作为一条固定检查项，否则废弃掉的旧方案会以「还在跑、还得维护」的形式沉淀下来。
计费冷饮二期技术方案评审
发言人：王军、王建朝、贾继伟、李强；主题：本次会议对计费冷饮二期需求的技术方案进行了评审，重点讨论了红包记账、钱包 H5 提现及优惠券核销等模块的架构设计、数据层调整与上线风险，并明确了后续优化方向。
小结
1. 红包记账模型调整
- 新增配送员角色：红包记账模块在原有门店侧角色基础上，新增了经销商侧的配送员角色。
- 唯一索引重构：记账账户的唯一约束由「事业部编码+门店编码+用户编码」调整为「事业部编码+归属主体类型+归属主体编码+用户编码」。
- 字段兼容处理：红包进账流水表新增了经销商编码与名称字段，当角色为配送员时，门店编码与名称将设为空字符串。
2. 历史数据清洗与 DDL 执行风险
- 历史数据统一归门店侧：所有事业部业态一致（含液奶），历史数据均需清洗为门店侧，已有脚本处理。
- 并发风险已排除：上线时经销商端暂无业务数据流入，不会出现并发账号生成问题。
- 后台文案需同步调整：数据统一归门店侧后，后台管理系统的文案表述需相应调整。
- DDL 执行窗口：表数据量较大，执行 DDL 变更时需注意执行期间风险，上线时提前与上游沟通并暂停网关数分钟以执行脚本。
3. 经销商端钱包 H5 鉴权流程
- 身份票据生成：经销商人员通过宿主小程序请求计费后端获取身份票据，后端基于本地主数据补齐经销商编码后返回。
- 登录令牌续期：钱包 H5 使用身份票据请求登录接口获取登录令牌，后续业务接口调用时由网关服务校验令牌有效性并自动续期。
- 异常场景回跳：登录失败或令牌失效时，钱包 H5 跳转至宿主小程序的指定桥接页，由小程序重新获取票据并加载。
4. 红包余额一键提现
- 提现自闭环：经销商端红包提现流程纯在钱包 H5 内部完成，无需唤起微信原生确认收款页面。
- 结果轮询机制：发起提现后，系统间隔 3 秒请求汇总接口；若存在提现中金额，则间隔 1 秒重试 3 次，最终展示提现中、成功或失败的汇总信息。
5. 对账与优惠券核销
- 对账枚举扩展：对账明细表新增收货方角色类型为配送员的枚举项，整体技术方案保持不变。
- 三种核销方式：门店端钱包 H5 支持单张、批量及全部核销，其中单张与批量核销复用批量处理链路。
- 全部核销上限处理：全部核销前需校验待核销数量，若超过 500 张需用户二次确认，系统将自动提取最近 500 张券进行生码处理。
6. 架构演进与上线执行
- 分库分表诉求：当前所有事业部需求都在同一张表内迭代，DDL 变更对其他业务影响较大。
- 分库实施顾虑：后续计划增加分库，但分库后实体类与接口字段增加会导致代码逻辑区分复杂度上升。
- 结构一致性要求：分库后需确保各库表结构一致，或在代码中做逻辑区分，两者都会增加开发复杂度。
- DDL 上线规范：需与上游确认重试机制，并选择较晚的时间段（如晚 10 点后）以减少对业务的影响；上线时暂停网关入口，待异步消息队列消费完毕后再执行变更，以避免数据操作冲突。
7. 后续建议（评审中识别，待补充确认）
- 「最近 500 张」与 10-20 需求侧的「按到期时间排序取前 500 张」口径需对齐：10-20 冷饮二期需求评审定的是按到期时间排序取前 500 张，本次技术方案写的是自动提取最近 500 张券。同一上限下的取券规则不同，用户实际核销到的券也不同；10-20 提出的「超上限需提示实际核销张数」建议在本次已由二次确认部分承接，但取券排序依据仍未写明。建议明确按到期时间还是按写入时间排序，并同步回需求文档。
- DDL 前缺备份与恢复验证动作：本次红包记账表 DDL 含唯一索引重构与历史数据清洗两件事，且需停网关窗口执行，但待办只安排了「与上游确认重试机制 + 协商暂停网关时间窗口」。建议在执行前补齐上线前的数据备份与恢复验证步骤，避免表结构与数据同时变更时无可回滚基线。
- 提现结果轮询的终止条件与异常兜底未写明：当前口径是「间隔 3 秒查一次，有提现中金额则间隔 1 秒重试 3 次」，三次之后若仍为提现中状态，是终止展示还是持续轮询、用户在提现中状态下能否再次发起提现，均未定义。建议明确轮询上限、终止后的用户提示，以及提现中记录的最终态查询路径。
- 分库优先级被 DDL 成本反复消耗：红包表本次因新增配送员角色而改唯一索引，同表后续每接一个事业部的新角色都要再改一次索引、每次都要停网关。建议把「新角色是否在建模期就预留归属主体类型维度」与分库时点一并评估，而不是等每次 DDL 停机后再议。
待办
1. 提现结果文案修正
- 修复提现结果汇总页面中关于三种状态文字描述的笔误。——@王军
2. DDL 上线前置确认
- 上线执行 DDL 脚本前，与上游营销活动中心确认重试机制，并协商暂停网关入口的时间窗口。——@王军
关联与提示
- 与 10-20「冷饮事业部二期需求评审」并读（同一需求的方案侧落地，闭环前次待办）：10-20 需求侧定的红包链路是「新增配送员角色枚举 + 红包进账流水表新增经销商编码与名称字段 + 门店类角色卡券核销」，本次技术方案把这三项落到了具体实现上——记账账户唯一索引由「事业部编码+门店编码+用户编码」改为「事业部编码+归属主体类型+归属主体编码+用户编码」，配送员角色下门店编码与名称置空。影响是：10-20 待办中「沟通并确认记账接口中收款方编码的唯一性与必填性」这条已由本次索引重构给出明确答案，可闭环；且本次补上了 10-20 未展开的鉴权链路（身份票据 → 登录令牌 → 网关续期 → 异常回跳宿主桥接页）与提现轮询机制，这两段是配送员钱包能否真正跑通的前置条件，此前只在需求侧一笔带过。
- 与 10-10「B 端出货明细表数据覆盖事故复盘」并读（生产变更管控根因链的新增切面）：10-10 复盘确立了「DDL 操作前对数据全量备份并验证恢复流程」，并把「上线评审表固定检查 SR 操作、新老接口兼容性」列为检查项。本次红包记账表要改唯一索引并清洗历史数据，执行方式是「暂停网关入口、等消息队列消费完毕后再执行 DDL」，属同类高风险生产变更，但待办里只有「与上游确认重试机制 + 协商暂停网关时间窗口」，没有备份与恢复验证动作。影响是：本次变更同时动表结构与表内数据，且需停网关窗口（此时业务写入已中断、无天然兜底），一旦脚本执行到中途失败，回滚依据只能依赖人工判断。10-10 的备份与恢复验证要求在本次方案中缺位。
- 与 10-14「营销活动中心微服务拆分与分库规划」并读（分库诉求的第一份显性成本）：10-14 定的是渐进式演进、先拆出红包/积分/优惠券等大模块独立微服务，以实现不同事业部在数据层与服务层的隔离，并提出为避免明年事业部量级上来后再分库导致迁移复杂度高、需把分库优先级往上放。本次是这条线的第一次显性成本暴露——红包表要新增配送员角色就得改唯一索引，改一次索引就要停一次网关，而同一张表后续每接一个事业部的新角色都要再改一次。影响是：分库讨论此前一直停留在「量级上来再说」，本次说明单表多事业部共存的代价已经开始以每次 DDL 停机的方式重复计费，建议把分库时点从「明年量级」提前到「下一个新角色建模之前」，否则每次事业部扩角色都要重新付一次停机成本。