2026-10-16 工作日志
券中心：券核销与发券逻辑研讨
发言人：林焕纯、赵敏、王军、孔玮、贾继伟；主题：本次会议主要围绕跨经销商券合并核销逻辑展开研讨，明确了生码与核销规则，评估了发券经销商字段的改造需求，并安排了后续数据落库结构表的交付与方案可行性分析。
小结
1. 跨经销商核销逻辑研讨
- 同经销商可合并：前端在合并生成核销码时，同经销商的券可以合并生成。
- 跨经销商不可合并：不同经销商的券不可跨经销商合并生成核销码。
- 无经销商券不可混合并：没有经销商维度的券只能跟没有经销商的券合并生成，不能跟有经销商维度的券合并生成。
- 生码阶段不校验经销商：系统生成核销码时主要校验券的有效性及时间范围等基础规则，不会在生码阶段拦截跨经销商合并。
- 核销阶段按规则校验：核销时会根据券配置的规则进行校验，若配置了限制经销商范围，系统会控制是否在经销商范围内核销。
- 货补券全有或全无：对于货补券类型，核销时会校验核销码内的所有券，若其中一条失败则全部核销失败。
2. 部分核销场景答疑
- 赵敏（提问）：如果生成码包含 A、B 两个经销商的券，核销时由 A 经销商核销，是否会导致 B 经销商的券核销失败？
- 林焕纯（回答）：对于自制券类型，核销时会根据接口类型进行部分核销，即符合 A 经销商规则的券成功，B 经销商的券失败；但货补券类型若有一条失败则全部失败。
3. 发券经销商字段改造评估
- 发券表无经销商字段：经查询，当前发给门店的券表中没有记录发券经销商的信息，若需获取历史数据需覆盖核销记录。
- 关联发券信息影响效率：若在查询优惠券列表时关联发券信息，可能会影响接口的查询效率。
- 前端需获取发券经销商信息：为控制跨经销商合并生成核销码，前端必须在生码前明确每张券对应的经销商信息。
- 后端同意改造并评估排期：后端同意将发券经销商信息存入发券表，并在查券列表时关联返回，但需前端最终确认需求后，后端再进行时间评估与排期。
4. 券发放对象类型说明
- 四种发放对象：目前系统支持发放给消费者、门店、门店加人员（导购）以及门店下的人员四种类型；货补券只发给门店，货款抵扣券则发放给门店加人员。
- 字段记录方式：发放记录表中通过门店编码和人员编码字段来区分发放对象，若两个字段都有值则为门店人员，仅有门店编码则为门店。
- 基础信息表无类型：券的基础信息表在建立时没有发放对象类型，该类型信息仅在发放记录表中体现。
5. 后续数据对接与方案分析
- 交付券全生命周期表：后端将在会后整理并交付两个数据库中券全生命周期设计的相关表及字段说明文档。
- 前端进行方案分析：前端团队将基于获取的数据落库结构表，对当前方案的可行性进行详细分析。
- 提前同步配合需求：若分析后需要卡券团队配合或支持，前端需提前说明，以便卡券团队评估资源与时间安排。
待办
- 评估发券经销商字段的改造时间并确认能否加入发券表中。——林焕纯
- 确认产品方案是否需要增加经销商字段，确认后同步给后端进行排期。——赵敏
- 会后整理并交付两个数据库中券全生命周期设计的相关表及字段说明文档。——杨建
- 基于数据落库结构表，分析当前方案的可行性，并提前同步卡券团队的配合需求。——王军
关联与提示
- 修正 10.14 评审结论：10.14 券中心评审记录中「核销码支持批量生成，但限定只能传入同一种券类型」，后端答复为「入参时只能传一种类型，但后端目前可能没有校验到，担心加逻辑会影响生码响应速度」，最终以「返回列表已限定类型、前端不写 bug 即可接受」口头结案。本次会议暴露该口头前提并不成立——前端确实会合并生成核销码，且生码阶段后端不校验经销商；同经销商可合并、跨经销商不可合并这条规则只存在于前端约定，后端无强制拦截。本次已同意改造发券表记录发券经销商，正是为让前端能在生码前判断；后端是否在生码入参侧补校验、避免跨经销商码被绕过前端构造，仍未决。
- 风险：货补券的「全有或全无」叠加跨经销商混合码：生码不拦跨经销商、核销才按配置校验，且货补券一条失败即全部失败。若前端合并逻辑在生码前拿不到经销商信息（发券表当前无该字段），混合码已生成，核销时才发现规则不符，则该码整体作废——业务侧表现为用户扫了码却核销失败，属可直接感知的线上问题。这也是发券经销商字段改造须尽快排期的实际原因。
高德接口异常排查与修复研讨
发言人：王建朝、潘玉平；主题：本次会议针对高德地图接口因 IPv6 解析异常导致请求失败的问题展开排查，明确了数据影响范围统计要求与修复参数验证计划，并同步了其他业务需求进展。
小结
1. 高德接口 IPv6 解析异常排查
- Pod 不支持 IPv6 导致连接异常：当前 Pod 不支持 IPv6，部分请求在调用高德地图时直接解析为 IPv6，导致连接异常并请求失败。
- 偶发异常与 DNS 解析机制相关：该异常表现为偶发性，且大部分请求仍使用 IPv4，这与 DNS 同时返回 A 记录和 AAAA 记录时的随机解析机制有关。
- 强制使用 IPv4 参数：此前讨论的解决方案为修改 JVM 参数，强制将域名解析为 IPv4 地址以规避该问题。
- 测试环境未能复现：该问题在测试环境中无法复现，仅在请求量大的生产环境中出现，导致此前未能完成验证。
2. 数据影响范围统计与修复计划
- 明确统计时间范围：需根据高德接口出现异常的具体时间段进行统计，确保数据口径与接口异常时间保持一致。
- 梳理受影响业务明细表：需排查包含地址解析逻辑的报表，如预算出货明细表、消费者明细表、盘点明细表及异常明细表等，统计受影响的数据量。
- 制定修复或保留理由：针对统计出的异常数据，需明确区分哪些数据可修复并给出技术方案，哪些无法修复并说明具体原因。
- 拉通产品共同评估：完成数据量统计与初步评估后，需拉通产品团队共同确认最终的修复方案与保留理由。
- 测试环境优先验证：下周需在测试环境优先配置强制使用 IPv4 的参数，并运行一周以确认服务无异常。
- 生产环境分批推进：测试环境验证无误后，再将参数配置到生产环境，并按节奏逐步推进。
3. 其他业务需求同步
- 人员与五段数据需全量同步：经确认，导购相关的人员表及五段数据需求仍需全量同步，以满足上线前的基础数据准备要求。
- 优雅停机连接异常问题：在近期部署期间，部分服务仍出现连接异常，后续需定位具体服务并针对性解决。
- 消费者明细批次清洗需求：需求已通过评审，此前已与子飞等相关人员核对数据量。
待办
1. 数据影响面统计与修复方案
- 统计高德接口异常时间段内受影响业务明细表的数据量，并梳理修复方案或保留理由。——潘玉平
- 将高德接口异常的数据量统计结果在群内同步。——潘玉平
2. 基础数据同步
- 下周一与明飞确认人员表与五段数据全量同步的需求。——潘玉平
3. 修复参数验证
- 下周在测试环境配置强制使用 IPv4 的参数，验证一周无异常后再推进至生产环境。——潘玉平
4. 连接异常排查
- 排查部署期间出现连接异常的具体服务并针对性解决。——潘玉平
关联与提示
- 同根因链新增切面（与 9.14 高德地址异常修复并读）：9.14 已记录「查证明细表 09-02 高德地图异常扫码地址为空修复」，本次把根因锁定为 Pod 不支持 IPv6 + DNS 同时返回 A/AAAA 记录随机解析，属偶发性而非确定性故障；因此此前单次修复只能覆盖已发现的空地址数据，未覆盖仍会随机发生的新增量。本次要求「按异常时间段统计受影响数据量 + 区分可修复/不可修复」正是补这个口子，但需注意：测试环境无法复现，参数验证只能靠测试环境运行一周的观察性结论，不是复现验证。
- 修复参数为 JVM 层改动，影响面大于单个业务：强制 IPv4 属Pod 级 JVM 参数，对该 Pod 内所有外部域名解析生效，不限于高德。若换其他域名（如 MQ 对象存储等）也依赖 IPv6或存在 IPv6 侧链路差异，需一并确认；建议配置前先在测试环境列出该 Pod 内所有外部依赖域名，逐一确认走IPv4 无副作用，再推进生产分批。
- 部署期连接异常与本次高德问题可能是两类问题：待办「排查部署期间出现连接异常的具体服务」与高德 IPv6 解析是两回事（前者未定位到服务、后者已锁定根因），不应合并处理；若部署期异常同样表现为偶发连接失败，需反向核查是否也是 DNS 解析相关，避免两条线各查一遍。