KCGL/app at 89db1d14d3c152530be2501a2cef45eeb081ce81 - KCGL

Files

yueli 89db1d14d3 feat(audit): BOM 摘要带出子件，消除批量插入的刷屏

问题：BOM 一次新建会批量插入几十条子件关联记录，同一秒出现几十行
target_name 与 summary 完全相同的日志。实测同一 bom_no 同一秒最多 58 条，
整页 200 条只折叠出 16 种摘要。UPDATE 更严重 —— 批量归档时一种摘要
（「是否启用：是→否；是否归档：否→是」）重复了 135 次。

改动：changes_summary 增加子件分支，load_child_lookup 解析子件。

两条解析路径：
  1. 快照里的 child_id —— CREATE/DELETE（实测 BOM CREATE 覆盖 100%）
  2. 否则若 module 是 BOM，用 target_id 反查 bom_table —— UPDATE
     （实测 584/634 可解）

★ 为什么必须按 module 门控，不能靠「target_id 命中 bom_table」这个特征：
  后者实测**大量误命中** —— 入库管理 3655 条、系统管理的 /permissions/assign
  1415 条、image_embeddings 1187 条、出库管理 726 条，它们的 target_id 都会
  撞上某条 bom_table 记录。照着补子件名就是把毫不相干的零件安到别的记录上。
  而 module 由**表名**推得（audit_listener: bom_table → 'BOM管理'），
  按 module 判定等价于按表判定，是可靠的。

★ 子件名直接可用，不必退回 #ID：child_id 已在 load_ref_maps 的批量解析
  范围内，且 load_child_lookup 自身也只做一次 MaterialBase 批量查
  （实测 200 行 1 次查询、20 行 1 次查询，与行数无关，无 N+1）。

摘要格式：
  新增（BOM管理）：添加子件 SF-9000 机加工配件（用量 1）
  删除（BOM管理）：移除子件 四代一体-侧面壳（用量 1）
  子件 9-36V输入5V输出隔离模块15W：是否启用：是→否；是否归档：否→是（来源：/bom/archive）

用量只在快照里有；UPDATE 行拿不到就不显示 —— 宁可不显示，也不去猜。

效果（实测）：
  · 同一秒 58 条 → 58 种不同摘要
  · 整页 200 条 CREATE：改造前 16 种 → 改造后 76 种
  · UPDATE：改造前 300 条折叠成 5 种（最多重复 135）→ 去重种类显著提升
  · 非 BOM 记录零污染（系统管理/入库管理/出库管理 各 200 条，含「子件」0 条）

验证：16 + 18 项断言全过；日报三天附件 490.5K / 193.4K / 10.3K 与 6 列结构未变；
导出口径在 4 组筛选下与列表一致；权限与凭据过滤未松动；
字典 182 个键零缺失；全库 0 条退化到原始 JSON。vue-tsc 与 vite build exit=0。

2026-09-28 10:52:25 +08:00