| | |
|---|
| | | - `UpgradeLog*.htm` 是旧版 VS 升级项目留下的报告，可忽略。 |
|---|
| | | - `.gitignore` 已屏蔽 `bin/`、`obj/`、`packages/`，但仓库里依旧保留了 `packages/` 目录 —— 那是老项目直接把 NuGet 包签入的历史遗留，不要当作缺失。 |
|---|
| | | |
|---|
| | | ## QCDistributionRegisterInfo 保存契约 |
|---|
| | | |
|---|
| | | 本仓库**没有** `(QCDistributionId, LabId, ProjectId)` 的数据库唯一索引（产品决定不动 DDL），防重复登记完全靠业务层。约定如下： |
|---|
| | | |
|---|
| | | - **唯一的保存入口**：所有保存 `QCDistributionRegisterInfo` 的路径都必须经过 `QCService.SaveQcDistributionRegister`。新写任何涉及登记表写入的代码，**不要**直接 `_qcDistributionRegisters.Insert`、不要绕开此方法。 |
|---|
| | | - **Id==0 的语义**：该方法把 `Id==0` 视为"新增"请求，进入前会按 `(QCDistributionId, LabId, ProjectId)` 做查重： |
|---|
| | | - 查不到 → 正常 Insert。 |
|---|
| | | - 查到 → 打一条 `[WARN]` 前缀的 Info 日志，按 `MergeRegisterInfo` 规则**合并**到既有行后 UPDATE；同时把入参 `qcDistributionRegister.Id` 回写为 `existing.Id`，便于调用方后续引用。 |
|---|
| | | - **MergeRegisterInfo 的合并规则（刻意不对称）**： |
|---|
| | | - `string` 字段：`source != null` 才覆盖（保留既有内容，不会被意外 null 清空）。 |
|---|
| | | - `DateTime?` 字段：`HasValue` 才覆盖。 |
|---|
| | | - `DateTime ModifyTime`：非默认值才覆盖（调用方都用 `DateTime.Now`，天然非默认）。 |
|---|
| | | - `bool` 字段：**只能 `false → true`，不能 `true → false`**。这是为了防止一次 Id==0 的脏 Save 把既有的 `IsCharged=1` 意外清零。 |
|---|
| | | - `QCDistributionId / LabId / ProjectId`：业务唯一键，不动。 |
|---|
| | | - **要把 bool 清回 false、或清空 string/Date 字段，必须走 Id>0 路径**：先用 `GetQcDistributionRegister(id)` 查出 tracked entity，直接改字段再 `SaveQcDistributionRegister`。用 `Id=0 + IsCharged=false` 这种方式期望"反收费"会被静默忽略。 |
|---|
| | | - **生产日志里出现 `[WARN] SaveQcDistributionRegister 命中已有行`** = 某个上层调用方漏做了查重或前端提交了脏 Id，**必须排查根因**，不要忽略。 |
|---|
| | | - **`SaveLabList` 路径（`QCDistributionInfoViewModel.ToEntity`）**：作为第一道防线，保留了自己的 `(QCDist, LabId, ProjectId)` 查重分支 —— 与 `SaveQcDistributionRegister` 里的收口形成双保险。修改这两处任一处时都要同步检查另一处。 |
|---|
| | | - **`BackstageController.ImportLabs`**：是唯一绕过 `SaveQcDistributionRegister` 的写入路径（直接操作 `QCDistribution.QCDistributionRegisters` 导航集合）。它自己在源读取后用 `GroupBy(LabId, ProjectId).Select(g => g.First())` 去重；**修改 ImportLabs 时必须保留这段 GroupBy**，否则脏数据会跨分发传染。 |
|---|
| | | - **残余风险**（已知，不修复）：两个管理员并发编辑同一分发时，两个独立 DbContext 的查重都可能返回空，仍有产生重复的理论窗口。本仓库不通过 DB 约束兜底，缓解办法是前端按钮防抖 + 日志监控 `[WARN]` 条目。如果日后发现并发窗口被真实触发，加唯一索引是根治方案（见"一致性"章节末尾）。 |
|---|
| | | |
|---|
| | | ## 修改时的红线（针对本仓库的具体风险） |
|---|
| | | |
|---|
| | | - **`BackstageController` 是超级 Controller**：1600+ 行、几十个动作、大量 QC 业务耦合在一起。做变更时务必在动作内部就近改，**不要顺手重构或拆分文件** —— 这不是本次任务范围，且缺少测试覆盖，重构风险极高。 |
|---|
