项目：xyMall ｜ 版本：v1.1 ｜ 生成日期：2026-10-06 ｜ 依据：源码分析
本文汇总当前代码库的已知问题、死代码与口径不一之处，逐条给出位置/证据/影响/建议，并给出短期与中期的重构演进路线图。事实来源有三：本轮源码核对（所有"位置"均在当前工作区验证）、仓库自带的过程文档（xy-mall/AGENTS.md、mall/docs/CODE-AUDIT-20260905.md、mall/docs/REMAINING-BACKLOG-V2.md、mall/docs/MICROSERVICE-SHARDING-PLAN.md）、以及本套文档集 00-06 篇与代码的交叉比对。每条都标注验证状态，无法从源码确认的写 ⚠️ 待确认。
| 编号 | 类别 | 条目 | 严重度 | 状态 |
|---|---|---|---|---|
| D1 | 部署 | admin 初始账号 INSERT 不在 Flyway V1~V8 | 高（新环境不可用） | 未修 |
| D2 | 部署 | H5 端无 Dockerfile、未纳入 compose | 中 | 未修 |
| D3 | 部署 | start.sh 默认 profile 为 dev | 中（配合 D6 缓解） | 未修（有注释提示） |
| D4 | 单实例 | 下单幂等键为进程内实现 | 高（扩容前必修） | 已知、有边界注释 |
| D5 | 单实例 | sys_config 进程缓存、登录失败计数降级内存、限流 Filter 进程内 | 中 | 已知 |
| D6 | 安全 | prod 模拟支付默认开启 | 高（接入真实支付前） | 有意为之，需流程把关 |
| D7 | 一致性 | 无资金对账任务 | 中 | 未做 |
| D8 | 组织 | OrderLogistics 实体错放在 user 模块 | 低 | 未修 |
| D9 | 组织 | favorite/parcel/seller 三模块无 service 层 | 低 | 未修 |
| D10 | 死代码 | sensitive_word 表建了没人用 | 低 | 未修 |
| D11 | 口径 | 旧文档中的 /api/admin/stock-log/page 端点不存在 | 低（文档债） | 本篇澄清 |
| D12 | 口径 | AGENTS.md 记载 27 个测试，实际 32 个 | 低（文档债） | 《09》已澄清 |
| D13 | 口径 | 折扣券不支持限定分类/商品范围 | 低（业务限制） | 报错文案已声明 |
| D14 | 口径 | pay_type 语义"以调用处为准" | 低 | 注释声明 |
| D15 | 口径 | docs/REMAINING-BACKLOG-V2.md 部分条目已过时 | 低（文档债） | 本篇澄清 |
| D16 | 测试 | 集成测试硬编码 root/root1234 与固定商品 ID | 中 | 未修 |
| D17 | 依赖 | ES 搜索依赖 NAS 19200 未实测 | 低 | backlog 已列 |
D1：admin 初始账号 INSERT 不在 Flyway V1~V8。位置：xy-mall/server/src/main/resources/db/migration/V1__init.sql。证据：V1 第 262263 行只有 255 行），只差账号行。建议：新迁移（V9）补 UPDATE admin_user SET role_id = 1 WHERE login_user_name = 'admin' AND (role_id IS NULL OR role_id = 0)——对 admin 行的更新存在，但没有任何一条 INSERT INTO admin_user 建立该行；admin_user 表本身是 CREATE TABLE IF NOT EXISTS（第 158 行），空库执行后是空表。影响：全新环境（compose 首次起库、新同事本机空库）启动成功但无任何管理员可登录，/api/admin/login 报"用户名或密码错误"；e2e-smoke.py 的 admin_login 也会失败。RBAC 的角色与权限点种子倒是齐全（V1 第 212INSERT IGNORE INTO admin_user (login_user_name, login_password, salt, nick_name, role_id) VALUES ('admin', '<BCrypt 哈希>', '', '超级管理员', 1)，密码用一次性 BCrypt 哈希并在文档要求首次登录改密；或提供 scripts/init-admin.sql。06-部署运行2.2 节已提示"需手工插入或沿用已有库"。
D2：H5 端无 Dockerfile。位置：xy-mall-h5/。证据：目录内有 nginx.conf 但没有 Dockerfile（ls xy-mall-h5 可验证）；xy-mall/docker-compose.yml 仅编排 mysql/redis/backend/admin-web/mall-web 五服务。影响：H5 无法容器化发布，生产只能静态托管或手工部署；三端发布形态不一致。建议：复制 xy-mall-admin/Dockerfile（node:20-alpine 构建 → nginx:alpine 承载），compose 增加同构服务 h5-web: 5188→80，nginx.conf 已就绪基本零改动。是否有计划内安排无源码依据 ⚠️ 待确认。
D3：start.sh 默认 dev profile。位置：xy-mall/start.sh 末行 export SPRING_PROFILES_ACTIVE="${SPRING_PROFILES_ACTIVE:-dev}"。证据与历史：docs/CODE-AUDIT-20260905.md P0-2 曾指出 start.sh 硬编码 --mall.captcha.allow-bypass=true 且未设 profile——旁路参数已被移除（当前 start.sh 无该参数，注释明确"验证码旁路仅由 dev profile 提供"），但默认 profile 仍是 dev，生产忘设 SPRING_PROFILES_ACTIVE=prod 时会以 dev 跑（SQL 打印、文档暴露、验证码 0000 生效）。影响：误部署风险；缓解：06-部署运行2.2 节把"显式 prod"列为标准命令。建议：start.sh 改为"未显式指定时打印醒目警告并要求 --prod 确认"，或直接反转默认值为 prod。
D6：prod 模拟支付默认开启。位置：application-prod.yml（xy-mall.payment.mock-enabled: true，注释自述"演示环境……接入正式支付宝后改回 false"）。影响：任何登录用户可把订单置为已支付（fail-closed 校验只在开关关闭时生效）。这是一次有意的演示站取舍，但它是上线清单里最容易漏的一项。建议：把《08-安全与权限设计》第 7 节的安全配置清单固化为发布检查脚本（grep 配置值 + 断言），并考虑给 prod 加"mock-enabled=true 时启动打印大字警告日志"。
D4：IdempotencyService 进程内。位置：xy-mall/.../modules/order/service/IdempotencyService.java。证据：ConcurrentHashMap 实现，TTL 24h、容量 5 万、超量惰性清理；类注释自述"单实例部署假设的一部分，横向扩容前需外置到 Redis"。影响：多副本部署时幂等头失效，重复提交可能产生重复订单（X-Idempotency-Key 是下单防重的用户可见契约）。建议：扩容前迁移到 Redis（SET NX PX + 原子 get-or-compute），接口签名不变。
D5：其余进程内状态清单。SysConfigServiceImpl.cache（ConcurrentHashMap，写时 clear——多副本下 A 副本改配置 B 副本最多滞后到下次写）、InMemoryCaptchaStore/InMemoryLoginFailStore（Redis 不可用时的降级实现，多副本下计数分裂）、RateLimitFilter.windows（进程内滑窗 + windows.size() > 10_000 整体清空的防御性重置）。影响与建议见《10-性能设计与优化》第 3 节；docs/BIG-TECH-READINESS-ASSESSMENT.md 维度 D 已有同结论清单，微服务化改造的完整路径见 docs/MICROSERVICE-SHARDING-PLAN.md（M0→M8 绞杀式推进，其中"前端零改动、网关保契约"是核心约束）。
D7：无资金对账任务。证据：秒杀域有 SeckillReconcileJob（Redis↔DB 对账），但余额/积分/库存无"流水合计 vs 余额/库存现值"的周期对账。docs/BIG-TECH-READINESS-ASSESSMENT.md 维度 C 同样点名"无对账任务（余额流水 vs 余额、库存 vs 流水）"。影响：极端并发下的漂移（或历史 bug 遗留）无法被系统自动发现，只能等用户投诉。建议：仿 SeckillReconcileJob 骨架新增 AssetReconcileJob：sum(balance_log.change) + 初始值 == user.balance、sum(stock_log.change) + 初始值 == 当前库存，不一致 warn + 可选自动修复，日级执行即可。
D8：OrderLogistics 实体错放 user 模块。证据：xy-mall/.../modules/user/entity/OrderLogistics.java，而订单物流的查询入口在 OrderService（order 模块）——实体与服务的模块归属不一致；同目录还有 BalanceLog/PointsLog/BrowseLog（资产与足迹，放 user 合理）。影响：认知成本；order 模块直接 import user 模块 mapper 形成跨模块 Mapper 依赖（与"模块间只走 Service"的约定不符）。建议：迁移到 modules/order/entity/（纯挪包，无表结构变化），OrderLogisticsMapper 随迁。
D9：三模块无 service 层。证据：favorite（controller 直用 Mapper）、parcel（同）、seller（同）。影响：逻辑薄时直连 Mapper 是务实选择，但三者已开始积累业务规则（favorite 的在售校验 + DuplicateKey 兜底；parcel 的发货状态校验），规则继续增长后控制器会变胖。建议：规则超过三个方法时补 service 层，不必提前。
D10：sensitive_word 表无调用点。证据：V5__tier1_closure.sql 建 sensitive_word 表，但 grep -rn "sensitive_word|SensitiveWord" server/src/main/java 零命中——无实体、无 Mapper、无服务。影响：死表；评价/IM 的敏感词过滤并未实现，存在"以为有过滤"的错觉风险。建议：要么实现过滤（评价发表与 IM 落库前校验，缓存词表到内存），要么在迁移注释与文档声明"预留"，本篇按现状标注为死代码。
D11：/api/admin/stock-log/page 端点不存在。证据：本套文档 03 篇第 6 节与 06 篇曾记载该端点（归属 StockLogController），但当前源码 grep -rn "stock-log" server/src/main/java 零命中；库存域只有 StockAlertController 的 GET /api/admin/stock/alerts。stock_log 的写入（record）遍布订单/秒杀/后台商品，但没有查询端点。影响：文档口径与代码不一致，调用方会 404。建议：二选一——补一个 StockLogController（分页查询流水，权限 goods:list，实现约 30 行），或修订文档。本套新篇（07/15）已按"端点不存在"口径书写。
D12：测试数量口径。AGENTS.md 第 5 节记"27 个"，当前源码 @Test 统计 32 个（8+5+5+3+4+5+2，逐类见《09-测试与质量保障》）。以 mvn test 输出为准；建议在 AGENTS.md 改为"以 mvn test 实际输出为准"的动态表述，避免再次漂移。
D13：折扣券的范围限制。证据：CouponServiceImpl 抛"折扣券暂不支持限定分类/商品范围（goodsValue 字段语义冲突）"。影响：折扣券（coupon_type 折扣型）只能全场用，运营若配置了范围会被接口拒绝。属于有意声明的业务限制而非 bug。建议：明确 goods_value 在折扣型下的语义（按件折扣或按类折扣）后放开，或在管理端表单隐藏该字段防误配。
D14：pay_type 语义模糊。证据：V1__init.sql 注释"0 余额 1 模拟/默认 2 支付宝（语义以调用处为准）"。影响：报表/排查时该字段不能自解释。建议：新增枚举类 PayType 收敛（AGENTS.md 已有 OrderStatus 收敛先例），迁移不必要、代码层即可。
D15：过程文档漂移。证据：docs/REMAINING-BACKLOG-V2.md（2026-09-05 盘点）所列需求中，至少两项已在后续迁移中落地——"评价商家回复"（第 10 项）对应 V5 的 goods_comment.reply_content/reply_time 与 AdminCommentController；"邀请注册奖励"（第 7 项）的数据底座 user.invite_code/inviter_id（V5，唯一键 uk_invite_code）已建（奖励发放逻辑未见实现——回刷核实：server 源码 grep invite/inviter/邀请 零命中，确认未实现）。影响：读 backlog 会低估当前完成度。建议：backlog 文档头部加"截至日期 + 已完成项回填"章节，或迁移到 issue 跟踪。
docs/CODE-AUDIT-20260905.md 曾列出 4 组 P0（资损/安全级）。本轮逐条核对当前源码，确认全部已整改，留档如下（防止未来误读旧审计报告）：
| 审计项 | 当时的证据 | 当前的修复证据 |
|---|---|---|
| P0-1 注册送 10 万 + 免费充值 | V4 种子 user.register.balance=10000000；充值接口无开关 | V7__cart_sku_unique_and_register_gift.sql 第 6 行：UPDATE sys_config SET config_value='0' WHERE config_key='user.register.balance' AND config_value='10000000'；充值接口加 xy-mall.user.recharge-enabled 开关（UserAssetController 第 49 行，默认 false，prod 显式 false）；注册接口补验证码校验 |
| P0-2 start.sh 后门 + dev 默认 | start.sh 硬编码 --mall.captcha.allow-bypass=true | 当前 start.sh 已无该参数，旁路仅由 application-dev.yml 提供（prod 加载不到）；默认 profile 仍 dev → 余留为本文 D3 |
| P0-3 MinIO AK/SK 硬编码兜底 | application.yml 兜底值为真实密钥 | 当前 ${XY_MALL_OSS_AK:}/${XY_MALL_OSS_SK:} 空默认，缺失自动回落本地 upload；密钥轮换与 git 历史清理属运维动作，仓库内无法验证 ⚠️ 待确认 |
| P0-4 双通道重复退款 | 售后与拼团退款互不感知 | OrderServiceImpl.refundAndClose 与 closeByAfterSale 双通道 CAS 互斥（源码注释"杜绝双通道重复退款"），《05-核心流程》3.2 节有机制描述 |
审计中的 P1 批次（余额扣款 Java 旧值覆盖等）在当前代码同样已改为条件更新（balance >= n 的 CAS，《05-核心流程》2.2 节④），不再逐条展开。
AGENTS.md 第 6 节第 7 条明确四项"勿在生产叙事引用"的演示级实现，逐条对应当前代码与升级方向：物流轨迹为演示数据（OrderService.logistics 返回拼装轨迹，无真实快递 API 对接；升级 = 接快递 100/菜鸟 API，backlog 第 4 项要求升级为按包裹查询）；多商户无入驻分账（seller 仅商品挂载维度；升级 = 卖家自助入驻 + 商家工作台 + 结算账单，backlog 第 3 项）；ES 搜索可切换但依赖 NAS 19200 且未实测（EsGoodsIndexService 代码就绪，search.engine=es 切换；升级 = 全量索引重建脚本 + 端到端联调，backlog 第 5 项）；拆单包裹为订单级演示（parcel 无仓配对接）。docs/REMAINING-BACKLOG-V2.md 第一梯队把这批"演示级 → 真闭环"列为最优先（约 8-10 人日），本篇不再重复展开。
短期以"堵漏与对齐口径"为主，全部是不动架构的小改动：D1 是新环境可用性的硬缺口，应最优先；发布检查脚本化把《08》清单从"文档约定"变成"机器门禁"；文档类债务（D11/D12/D15）成本极低且直接降低新人认知成本。
中期补质量基础设施：资金对账（D7）是电商系统从"能跑"到"可信"的分水岭；CI 门禁补强（回刷核实：三仓已有基础 GitHub Actions 流水线——后端 mvn test、web/admin lint+vue-tsc+build，但均无 e2e-smoke 与覆盖率门禁，h5 无 CI，见《09-测试与质量保障》第 6 节建议 5）与覆盖率基线让 AGENTS.md 的六条检查有机器兜底；H5 容器化补齐三端发布一致性；演示级四项按 backlog 的优先级推进。
长期仅在真实增长或团队解耦需求出现时启动：docs/MICROSERVICE-SHARDING-PLAN.md 已给出完整评估（"当前数据量下拆分没有性能收益，只有成本"），最小路径 M1+M3+M4+M6（网关 + 服务拆分 + 状态外置 + 灰度）保留了可回滚性；执行前必须先完成 D4/D5 的状态外置，否则多副本即数据不一致。该计划同时要求"前端零改动"约束下的路径契约不变——这与本套文档《15-接口全量参考》维护的端点清单互为配套：接口契约先冻结，拆分才可绞杀式推进。
代码库当前的真实状态是：核心交易正确性债务已基本清零（审计 P0 全部整改、防超卖/幂等/对账纠偏在位），剩余债务集中在三类——部署收尾（D1/D2/D3/D6）、单实例假设的状态外置（D4/D5）、以及文档口径对齐（D11/D12/D15）。短期先做 D1 与发布门禁脚本化，中期补对账与 CI 门禁补强（e2e/覆盖率），长期按业务增长决定是否推翻单实例定位；每一步都有现成的仓库内规划文档背书，不存在"无人知道往哪走"的状态。