上线前检查清单
数据准备
| # | 检查项 | 标准 | 状态 |
|---|---|---|---|
| 1 | WDT 同步引擎正常运行，最新数据已同步 | 最近一次同步成功，无延迟超过 1 小时 | ☐ |
| 2 | 宽表数据完整性校验通过 | 宽表行数与 WDT 源表行数一致（允许 1% 误差） | ☐ |
| 3 | 原慧策系统基础配置数据已导出 | 店铺、分销商、用户、结算配置已从 MySQL 导出 | ☐ |
| 4 | 基础配置数据迁移完成且验证通过 | PostgreSQL recon schema 中数据与原系统一致 | ☐ |
| 5 | 历史对账结果备份完成 | 原系统 MySQL 数据库已完整备份 | ☐ |
功能验收
| # | 检查项 | 标准 | 状态 |
|---|---|---|---|
| 6 | 登录认证正常 | 使用管理员账号可登录，错误密码被拒绝 | ☐ |
| 7 | 多租户隔离正常 | 不同租户用户互不可见对方数据 | ☐ |
| 8 | 角色权限生效 | 不同权限用户可见的菜单和功能与权限一致 | ☐ |
| 9 | 售中对账可正常执行 | 选择期间后对账引擎可正确产出匹配结果 | ☐ |
| 10 | 售后对账可正常执行 | 退款类型（退货退款/仅退款/换货）均正确匹配 | ☐ |
| 11 | 报表查询功能正常 | 所有 60+ 报表类型均可正常查询 | ☐ |
| 12 | 报表筛选/排序/分页正常 | 日期、店铺、状态等多维度筛选可用 | ☐ |
| 13 | Excel 导出功能正常 | 大数据量导出不超时，格式正确 | ☐ |
| 14 | 物流资费对账可正常执行 | 物流报价加载正确，费用对比结果准确 | ☐ |
| 15 | 结算生成与确认流程正常 | 选择周期→生成→调整→确认→锁定 流程完整 | ☐ |
| 16 | 金额调整审批流正常 | 提交→审批通过→金额更新 流程正确 | ☐ |
| 17 | 备份/恢复功能正常 | 创建备份→恢复备份 数据一致 | ☐ |
| 18 | 发票数据查询正常 | 发票汇总/明细/红冲统计正确 | ☐ |
性能验收
| # | 检查项 | 标准 | 状态 |
|---|---|---|---|
| 19 | 报表首页加载时间 | < 2 秒 | ☐ |
| 20 | 大数据量报表查询（10 万+ 行） | < 3 秒 | ☐ |
| 21 | Excel 导出（5 万+ 行） | < 30 秒 | ☐ |
| 22 | 对账引擎执行（10 万+ 条数据） | < 5 分钟 | ☐ |
| 23 | 并发用户支持 | 50 用户同时操作不出现超时或错误 | ☐ |
上线切换
| # | 检查项 | 标准 | 状态 |
|---|---|---|---|
| 24 | 新系统部署完成 | 生产环境可正常访问 | ☐ |
| 25 | 切换通知已发送 | 所有用户知悉切换时间和新系统地址 | ☐ |
| 26 | 原系统设为只读模式 | 原慧策系统保留历史数据查询，禁止新数据写入 | ☐ |
| 27 | 回滚方案就绪 | 原系统可在一小时内恢复服务 | ☐ |
常见问题（FAQ）
数据相关
Q：原慧策系统的历史对账数据怎么处理？
A：采用「配置迁移 + 业务重新同步」策略。基础配置数据（店铺、分销商、用户、结算配置）从原系统 MySQL 一次性迁移到 PostgreSQL。报表和对账结果数据不迁移——这些数据从 WDT 同步引擎重新生成，确保数据源头一致。原系统数据库保留作为历史查询，至少保留 6 个月后归档。
Q：如果 WDT 同步延迟，对账会受影响吗？
A：对账引擎在执行前会检查 WDT 同步状态。如果最近一次同步失败或延迟超过阈值（可配置，默认 2 小时），对账执行将标记为「数据不完整」状态，并在 Dashboard 上显示告警。用户可选择等待同步完成后再执行对账。
Q：数据会不会出现重复对账？
A：不会。每条对账记录通过「源系统 + 源单号 + 业务类型 + 对账周期」组成唯一幂等键，同一条单据在同一对账周期内不会被重复计入。
对账规则
Q：对账公式怎么修改？需要开发介入吗？
A：对账公式通过后台管理页面可视化编辑，运营人员可以调整匹配字段、匹配规则（精确/模糊/金额容差）、时间窗口等参数。修改后需要「保存并测试」——系统会用历史数据模拟执行，验证新公式的匹配效果。只有不想改代码的高级定制才需要开发介入。
Q：售中对账的金额不一致怎么处理？
A：金额差异在 ±1 元以内（可配置）的自动视为匹配通过。超过阈值的差异标记为「部分匹配」，进入人工复核队列。复核人员可以查看两边的原始单据，确认差异原因（平台手续费、优惠券等），选择接受或提交金额调整单。
结算相关
Q：结算确认后还能修改吗？
A：结算确认后数据锁定，不能直接修改。如需调整，需要先「撤销确认」→ 提交新的金额调整单 → 重新生成结算单 → 再次确认。所有操作记录（包括撤销）都有审计日志。
Q：结算周期怎么定义？
A：结算周期在「结算配置」中自定义，支持按自然月、按自定义天数、按平台账单周期等方式。不同店铺可以设置不同的结算周期，互不影响。
技术相关
Q：为什么选择完全替代而不是并行运行？
A：维护两套对账系统会导致数据不一致风险和维护成本翻倍。Factify 的 Go 架构性能远优于 Java 方案，单二进制部署运维更简单。渐进式替代（分阶段上线）已经提供了充分的过渡期。
Q：如果出了严重问题，怎么回滚？
A：原慧策系统在上线切换后保留至少 1 个月的完整可用状态。新系统的数据都在独立的 recon schema 中，不影响 WDT 同步和宽表。如果出现严重问题，切换回原系统只需将 DNS/反向代理指回原 Java 服务地址即可。
风险提示
| 风险 | 等级 | 影响 | 应对措施 |
|---|---|---|---|
| WDT API 接口变更 | 🟡 中 | 对账引擎数据源不可用 | WDT 同步引擎有变更适配机制；对账引擎数据源与同步引擎已验证兼容 |
| 对账公式迁移后匹配率下降 | 🟡 中 | 对账准确率暂时降低 | Phase 1 预留两轮公式验证；先在小数据集上验证再推广 |
| 历史数据迁移不完整 | 🟢 低 | 部分老旧配置丢失 | 迁移前做完整性校验；原系统保留 6 个月 |
| 用户学习成本高 | 🟢 低 | 短期内操作效率下降 | 新系统 UI 与旧系统页面布局相似；提供操作手册和培训 |
| 大促期间系统压力 | 🟡 中 | 对账查询响应变慢 | 提前进行压力测试；高峰期限制大数据量导出 |
关键提醒：原慧策系统在切换前不要删除或停用。保留至少 1 个月的完整可用状态作为回滚方案。数据迁移完成后，先在测试环境完整验证一遍全部 60+ 报表的数据准确性，再进行生产切换。