处理 P2.5 评审遗留的 P1 项

song.jun

3 天以前 1eafb5411551e7a976e1f4ef6573897ec91362f0

处理 P2.5 评审遗留的 P1 项

P1.1: CLAUDE.md 补充 SaveLabList 的 byId/byLabProject 字典快照行为
- 明确说明字典是循环前的一次性快照，同批重复提交时第一道防线看不到
  循环内刚插入的行，会降级到 SaveQcDistributionRegister 的第二道防线
  兜底（触发 LogHelper.Error 告警）。
- 明确告诫后续开发者不要"为了一致性"把第一道防线改成循环内动态刷新
  字典——那反而会放大并发窗口。
- 也说明了 byLabProject.OrderByDescending(p.Id).First() 的确定性意图，
  避免未来被"没意义的简化"改回 First()。

P1.2: QCDistributionInfoViewModel.ToEntity 的 byLabProject 查重改为
     OrderByDescending(p.Id).First()
- 如果数据库里历史上出现未清理的重复（防御性假设），这个顺序保证永远
  命中 Id 最大（最新插入）的那一条，消除命中顺序不确定的理论风险。
- 实际上清理后全库已无重复，但代码层面不再依赖"没有重复"这个假设。

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

 CLAUDE.md

@@ -128,6 +128,8 @@
- **要把 bool 清回 false、或清空 string/Date 字段，必须走 Id>0 路径**：先用 `GetQcDistributionRegister(id)` 查出 tracked entity，直接改字段再 `SaveQcDistributionRegister`。用 `Id=0 + IsCharged=false` 这种方式期望"反收费"会被静默忽略。
- **生产日志里出现 `SaveQcDistributionRegister 命中已有行`（Error 级别）** = 某个上层调用方漏做了查重或前端提交了脏 Id，**必须排查根因**。这条日志**刻意用 `LogHelper.Error`** 而不是 Info —— 因为本仓库的 `LogHelper` 没有 Warn 方法，而 Info 级别不会触发告警系统；用 Error 保证运维能第一时间收到通知。
- **`SaveLabList` 路径（`QCDistributionInfoViewModel.ToEntity`）**：作为第一道防线，保留了自己的 `(QCDist, LabId, ProjectId)` 查重分支 —— 与 `SaveQcDistributionRegister` 里的收口形成双保险。修改这两处任一处时都要同步检查另一处。注意第一道防线命中后**只同步 `IsCharged` 和 `ModifyTime`**（基于 SaveLabList 的业务语义），第二道防线命中后走 `MergeRegisterInfo` 全字段合并（通用兜底）；两者行为刻意不对称。
- **SaveLabList 的 byId / byLabProject 字典是循环前的快照**：`QCDistributionInfoViewModel.ToEntity` 在循环开始前一次性 `WHERE QCDistributionId=? ` 预加载全部登记行进内存，构建两个字典供循环查找。这意味着**同一次 SaveLabList 请求内，前端 LabList 里如果有两条完全一致的 `(LabId, ProjectId)` 条目**，第一道防线**看不到第一次 Insert 刚产生的那一行**（字典没更新），第二次循环会继续走 Insert 分支 —— 最终落到 `SaveQcDistributionRegister` 的**第二道防线兜底**，触发 `LogHelper.Error` 并合并到已有行。这是**刻意的分层设计**：第一道防线负责 99% 的已入库重复，第二道防线负责同批提交的 race。不要试图"为了一致性"把第一道防线改成在循环内动态刷新字典 —— 那反而会放大并发窗口。
- **`byLabProject` 的 `GroupBy.First()` 用 `OrderByDescending(p.Id)` 保证确定性**：如果数据库里历史上有未清理的重复（不应该发生，但作防御），这个顺序保证永远命中 Id 最大（最新插入）的那一条。修改这个 LINQ 表达式时必须保留 `OrderByDescending`，否则行为变得不确定。
- **`QCDistributionRegisterInfoViewModel.ToEntityByLabCode`** 的 ProjectId 过滤是**条件的**：只有 `regInfoivewModel.ProjectId > 0` 才加入 WHERE 子句，否则退化为只按 `(QCDistributionId, LabId)` 匹配。原因：前端 `Views/Backstage/QCDistributionLabs.cshtml` 的 `openFeeWindow` / `openEMSWindow` 把 `CurrentQCDistRegisterInfo` 重置为不含 ProjectId 字段的 JSON 字面量，序列化后服务端 `regInfoivewModel.ProjectId == 0`，无条件加过滤会让 `ConfigrmFee` / `ConfigrmEMS` / `switchNextOne` 全部静默失效。**未来若前端补上 ProjectId 选择控件**，服务端会自动切换到精准匹配，不需要改服务端代码。多项目共存时当前会匹配第一条（与修复前行为一致）。
- **`BackstageController.ImportLabs`**：是唯一绕过 `SaveQcDistributionRegister` 的写入路径（直接操作 `QCDistribution.QCDistributionRegisters` 导航集合）。它自己在源读取后用 `GroupBy(LabId, ProjectId).Select(g => g.First())` 去重；**修改 ImportLabs 时必须保留这段 GroupBy**，否则脏数据会跨分发传染。
- **残余风险**（已知，不修复）：两个管理员并发编辑同一分发时，两个独立 DbContext 的查重都可能返回空，仍有产生重复的理论窗口。本仓库不通过 DB 约束兜底，缓解办法是前端按钮防抖 + 监控 `SaveQcDistributionRegister 命中已有行` 的 Error 日志。如果日后发现并发窗口被真实触发，加唯一索引是根治方案（见"一致性"章节末尾）。

 sbcLabSystem/Models/Backstage/QCDistributionInfoViewModel.cs

@@ -142,7 +142,7 @@
                var byId = existingRegisters.ToDictionary(p => p.Id, p => p);
                var byLabProject = existingRegisters
                    .GroupBy(p => Tuple.Create(p.LabId, p.ProjectId))
                    .ToDictionary(g => g.Key, g => g.First());
                    .ToDictionary(g => g.Key, g => g.OrderByDescending(p => p.Id).First());

                viewModel.LabList.ForEach(x =>
                {