邮件标题：20260907-技术评审-营销活动中心-扫码错误记录表
邮件正文：
晓娜、建新：
已完成针对【扫码错误记录表（scan_error_info）】的技术评审，现将评审结论、风险判断及后续执行安排同步如下，便于各方对齐认知并落实执行。
项目名称： 营销活动中心
评审时间： 2026/09/07
参与评审人： 王建朝、马奇、孙传熙、张喜（方案汇报）
评审结果： 通过
一、技术方案背景
- 业务场景：新增
scan_error_info扫码拦截记录表，沉淀 B 端扫码环节被规则拦截的明细，支撑拦截原因分析、经销商行为分析与异常追责，采集数据供数据中台做统计分析。
二、技术方案要点
- 整体流程：B 端扫码请求进入出货查码接口 → 查
code_info获取码信息 → 4 类校验（生产时间未满 2 天、货权不一致、已过期、码状态不符）→ 命中拦截即组装记录 → 经自定义线程池异步写入 Mongoscan_error_info→ 主流程立即抛异常返回前端，落库与抛错并发执行、不堵塞主线程。
三、决议事项
- 在技术方案中补充 Mongo 时区说明——mongo 时间按 UTC 存储、比北京时间少 8 小时，中台抽数存在时间差、不能按 0 点抽取，由张喜负责。
- 在方案中补充埋点采用代码侵入式而非 AOP 或消息解耦的评估结论——埋点类型少、拦截量小、改动可控，维持现方案，后续扩展再改为发消息 + 独立服务监听，由张喜负责。
- 留存测试环境自测记录（埋点落库已验证正常），并明确与中台的关联分析部分需上线后线上验证，由张喜负责。
四、风险提示
- 测试环境码为自造数据、缺少 TTS 中间表，与中台的关联分析无法在测试环境覆盖，需上线后线上验证，存在上线后才暴露关联问题的风险。
- 数据最终一致性尚未书面确认：落库失败不重试，极端情况（如服务异常重启）可能丢失少量拦截数据；若中台后续要求每条必达，需改造并补充重试机制。
- 埋点为代码侵入式嵌入现有校验分支，主流程改造时需同步维护埋点；拦截量级增大或埋点类型增多时，需改为消息解耦。