BUG REPORT · 10 ENTRIES · ALL FIXED
小薇进销存 · Bug 缺陷报告
小薇 · 进销存智能 Agent —— 集成测试 / 接口自动化 / 并发回归与一致性测试过程中发现并跟踪的缺陷。共 10 条,按严重程度从高到低排序,全部已修复并通过回归关闭。
4 P0 严重
4 P1 中等
2 P2 轻微
10 / 10 已修复关闭
统计口径:P0 严重 4 条、P1 中等 4 条、P2 轻微 2 条,已全部修复并通过回归关闭。严重程度按「资金损失 > 数据/一致性破坏 > 规则/权限 > 性能 > UI 体验」评估;以下按严重程度从高到低排序,BUG 编号为稳定跟踪号,与 P0 接口一致性与并发用例一一对应。
P0 严重:资金与最终一致性 4
BUG-01库存并发扣减超卖：同商品多单并发销售时库存虚高、可为负
P0 严重已关闭
模块库存状态机 / 销售出库（`GoodsServiceImpl.adjustStock`）
来源并发回归测试 · 接口自动化（CON-01 / INV-12）
定位并发/一致性
复现步骤
① 商品 A 库存 10，售价 5；② 并发提交 3 笔各销售 5 件的销售单（线程并发直接调 `/sale/save`）；③ 结束后查询商品 A 库存与销售明细。
预期:总销量不得超过库存 10：至多 2 笔成功，库存 ≥ 0，不会出现负库存。 实际:3 笔全部成功，库存被覆盖为 -5（后写覆盖先写）；部分销售单在库存为负的情况下仍然出库成功，直接造成超卖资金损失。
根因 库存扣减缺少原子性保障（乐观锁 / CAS 更新 / Redis Lua 原子脚本）；属于典型「先查后扣」竞态，与金额类并发超扣同源。
修复建议
BUG-02挂账销售无赊账额度上限：客户可无限挂账，形成资金敞口
P0 严重已关闭
模块销售出库 / 赊账台账（`SaleOrderServiceImpl.save`）
来源功能测试 + 代码走查（CRD-11 / CON-05）
定位并发/一致性
复现步骤
① 对客户「王老板」连续 10 笔挂账销售，每笔 1000 元；② 查赊账台账。
预期:挂账累计欠款超过商户设定的赊账额度上限时，第 N 笔挂账应被拒绝或显著提示，控制资金敞口。 实际:10 笔全部挂账成功，累计欠款 10000 元无任何拦截；挂账分支仅校验「客户姓名非空且非散客」，不存在额度上限概念。
根因 赊账额度风控缺失 + 缺少在途欠款聚合查询；需产品明确额度口径（商户级 / 客户级）。
修复建议
BUG-03还款并发丢更新：两笔还款同时提交，后写覆盖先写，欠款余额错乱
P0 严重已关闭
模块赊账台账（`CreditRecordServiceImpl.repay`）
来源并发回归测试（CRD-06 / CON-04）
定位并发/一致性
复现步骤
① 台账欠款 100 元；② 并发发起两笔还款，各 60 元；③ 查询台账余额与还款明细。
预期:两笔还款都生效或其中一笔因余额不足被拒绝，最终余额为 0（或 40），还款流水与余额对账一致，累计还款不超欠款。 实际:两笔还款均返回成功，但台账余额仅被扣减 60（后写覆盖先写），40 元还款流水丢失，客户实际多还 20 元 / 商户账实不符。
根因 余额类写操作未做原子化（乐观锁 / `UPDATE ... SET paid=paid+? WHERE id=? AND paid+?<=amount`）。
修复建议
BUG-04商品缓存与 DB 双写不一致：写后清缓存失败被静默吞掉，接口读到过期库存
P0 严重已关闭
模块商品管理 / 库存状态机（`GoodsServiceImpl` 缓存层）
来源故障注入 + 一致性测试（CON-02 / CON-03 / GDS-07）
定位并发/一致性
复现步骤
① 商品 A 已被列表接口缓存（TTL 10min）；② 制造 Redis 写入/删除失败（如网络抖动、keyspace 大导致清缓存超时）；③ 销售扣减库存后，立即查商品列表/详情。
预期:写操作后缓存被正确清理或刷新，任何读路径返回的都是最新 DB 库存。 实际:清缓存操作 `catch(Exception)` 静默吞掉失败；随后读路径命中 TTL 内的旧缓存，返回过期库存（如仍显示 10，实际已扣到 5），导致「库存足够」的误判进而叠加超卖风险。
根因 双写缺少最终一致性补偿（失败重试 / 延迟双删 / 版本对账）；异常被静默吞掉。
修复建议
P1 中等:规则 / 权限 / 部分一致性与性能 4
BUG-05AI 流式对话不落操作日志：AiLog 页面看不到记录，审计链路缺失
P1 中等已关闭
模块Agent 对话（`AiServiceImpl` / `AiOperationLog`）
来源功能测试（LIM-08 / CON-07 / AGT-12）
定位并发/一致性
复现步骤
① 登录后在 AiChat 发起多轮流式对话（含写操作）；② 打开 AiLog 操作日志页面。
预期:每次对话（含流式）都生成一条操作日志：时间、问题、意图、操作类型、结果。 实际:日志页面为空或仅有部分记录；非流式接口正常，但流式对话路径未保存日志——Agent 实际执行了写操作，审计日志却是空的。
根因 日志记录与 Agent 执行解耦且无兜底（事件丢失型缺陷，等价异步日志/回调丢失场景）；「有值才落库」策略使审计在异常路径下静默缺失。
修复建议
BUG-06Agent 确认后 PendingWrite 状态残留：新对话被上一次预览状态劫持
P1 中等已关闭
模块Agent 状态机（Redis PendingWrite / `state.py`）
来源多轮对话功能测试（CON-06 / AGT-03）
定位并发/一致性
复现步骤
① 发起「卖 10 瓶可乐」生成预览（PendingWrite 落 Redis）；② 对话「确认」落库成功；③ 再次发起全新对话「今天卖了多少」。
预期:确认成功后 PendingWrite 被清理，新对话为全新上下文，正常返回查询结果。 实际:部分情况下新对话被上一次残留的预览状态拦截，要求「继续确认或修改」，无法正常执行查询——旧状态未被清理（清理失败或异常路径未删除）。
根因 状态清理缺少确定性（无 `finally`、无 TTL 过期兜底、无对账任务）——最终一致性回退缺失。
修复建议
BUG-07登录限流基于 JVM 内存且信任 X-Forwarded-For：可伪造 IP 绕过、多实例失效
P1 中等已关闭
模块登录限流（`LoginRateLimitInterceptor`）
来源安全测试 + 代码走查（LIM-01 / LIM-04）
定位并发/一致性
复现步骤
① 同 IP 连续登录 11 次触发 429 限流；② 构造不同的 `X-Forwarded-For` 请求头再次登录；③ 部署 2 个后端实例后同 IP 高频登录。
预期:限流以真实来源 IP 为维度，任何客户端伪造请求头都不能绕过；多实例部署下限流策略仍然生效。 实际:伪造 `X-Forwarded-For` 后限流计数被重置、可继续暴力尝试密码；多实例部署时各实例独立计数，总限流次数翻倍。
根因 限流状态放错层级（JVM 内存而非 Redis），且信任不可信请求头——安全属性依赖「单实例 + 客户端诚实」的错误假设。
修复建议
BUG-08挂账单退款冲减赊账选错记录：同一客户多笔挂账时冲减到最近一笔
P1 中等已关闭
模块销售出库退款 / 赊账台账（`SaleOrderServiceImpl.refund`）
来源场景法测试（CRD-09 / CON-08 / SAL-16）
定位并发/一致性
复现步骤
① 客户「李姐」先后挂账两单：单 A 100 元（早）、单 B 200 元（晚）；② 对单 A 退款 100 元；③ 查询台账两条记录。
预期:退款应冲减与单 A 对应的台账（B 单不受影响），台账与单据一一对应。 实际:冲减逻辑取「该客户最近一笔未结清记录」，实际冲减了单 B 对应的台账（200→100），单 A 仍显示欠 100——退款与单据错位，账实不符。
根因 台账与销售单缺少引用完整性（无外键关联），冲减策略「就近取」不具备业务确定性。
修复建议
P2 轻微:UI / 体验 / 文案 2
BUG-09挂账客户姓名未归一化：前后空格导致同一客户拆成两条台账
P2 轻微已关闭
模块销售出库 / 赊账台账
来源UI + 接口边界测试（CRD-08 / CON-11）
定位并发/一致性
复现步骤
① 挂账销售客户填「张三」；② 另一单客户填「 张三 」（含空格）；③ 查赊账台账。
预期:客户名归一化（trim）后视为同一客户，台账合并展示同一客户的总欠款。 实际:两条记录被当成不同客户，同一人欠款被拆散展示，还款/对账口径错乱。
根因 输入缺少数据清洗（strip）与展示归一化。
修复建议
BUG-10仪表盘毛利统计 N+1 查询：单量增长后统计接口响应显著变慢
P2 轻微已关闭
模块仪表盘统计（`DashboardServiceImpl.stats`）
来源性能测试 + 日志分析（DSH-03 / 千单压测）
定位并发/一致性
复现步骤
① 造数本月 1000 笔销售单；② 调用 `/dashboard/stats` 并统计响应时间；③ 查看慢日志/DB 查询日志。
预期:统计接口一次/少数次查询完成，响应 < 500ms（千单量级）。 实际:响应 2.3s，DB 查询日志显示对每笔销售单逐条回查商品进价（约 1000+ 次单点查询），随单量线性恶化。
根因 循环内查询（N+1 模式），缺少批量 `SELECT ... WHERE goods_id IN (...)` 或冗余进价快照。
修复建议