增量报告 · huanyan/web v0.1.53

一、报告信息

---

二、变更概览

本次提交是一次口径收紧型重构：将销售单整单多人的默认按人数平分比例，从 4 位小数（如 33.33%/33.33%/33.34%）改为整数百分比（如 34%/33%/33%），并让输入控件只接受整数。金额尾差归位（largest-remainder）逻辑保持不变。

说明：codescan.source_read 默认读取的是 base 工作树；以上 head 内容已用 commit_hash 逐段核对确认。

---

三、核心逻辑变更详解

1. evenAllocRatios(n) 重写（model.ts）

变更前

const share = Math.floor((1 / n) * 10000) / 10000   // 4 位小数
const out = Array.from({ length: n }, () => share)
out[n - 1] = Math.round((1 - share * (n - 1)) * 10000) / 10000  // 尾差归最后一档

变更后

const base = Math.floor(100 / n)
const out = Array.from({ length: n }, () => base)
const remainder = 100 - base * n
for (let i = 0; i < remainder; i += 1) out[i] += 1   // 余数从前往后各 +1
return out.map((pct) => pct / 100)

行为对照（已人工验算）

• 余数 100 - base*n = 100 mod n，恒 < n（n≤100 时 base≥1；n>100 时 base=0 且 100<n），循环下标不会越界。
• 对「人数平分」场景余数天然相等，从前往后 +1 与「最大余数法」等价，分配稳定、可预期。

2. 输入控件（AllocPanel.tsx）

• 销售单、服务单两处 InputNumber：precision 2→0、新增 step={1}；
• 显示值：round2(ratio*100) → Math.round(ratio*100)；
• 写回值：Math.round((v/100)*10000)/10000 → Math.round(v)/100。

即「显示整数百分比、存储 0.01 精度比例」，用户可用步进器按 1% 调整，不再出现 33.33。

3. 未变更但被依赖的关键函数（影响面收敛）

• allocAmountOf / allocAmountsOf（金额 = 基数×比例 并做尾差归位/largest-remainder）；
• salesAllocPending、lineAllocPending（Σ≠100% ±0.01 容差判待分摊）；
• salesAllocsToPayload（按 {staff_id, ratio} 提交）。

本次仅改「默认比例生成」与「输入精度」，提交载荷与金额计算口径不变，服务端仍按客户端显式传入的比例用同式重算，故前后端一致性保持。

---

四、质检比对结果（工具真实数据）

使用 codescan.issues_diff 对 base..head 比对：

问题对比结果：修复 0 条 / 新增 0 条（两版本质量无差异）

• 修复 bug：0 条
• 新增问题：0 条

本次变更为口径重构，未引入静态质检告警，也未消除既有告警。

---

五、人工审查与风险提示

未发现阻断性问题，以下为需留意点（非缺陷）：

1. 金额分配结果会变化（预期内）：如锚点 ¥10、3 人，旧 [3.33,3.33,3.34]，新 [3.40,3.30,3.30]。因客户端把整数比例（34/33/33）提交给服务端，服务端用同比例重算，前后端仍一致；但历史/对照报表若按旧默认值推算会出现差异。
2. 极大人数边界：n>100 时 base=0，第 101 人及以后比例可能为 0%，salesAllocPending 因存在 ratio<=0 判为待分摊（提交被拦）。现实中分摊人数远小于 100，可接受；如需兜底可对 n>100 做提示。
3. 历史草稿的展示口径：value 用 Math.round(ratio*100)。若读取到旧版本产生的 0.3333 类小数比例，输入框会显示为整数（如 33），而底层比例仍为小数，直到用户改动才归一。属遗留数据兼容问题，非本次逻辑缺陷。
4. 只读意向展示未同步：ratioPctText（用于「下单时已排」只读横幅）仍按 2 位小数格式化，draftIntent.test.ts 中 1/3 → 33.33% 用例保持通过。该函数与可编辑面板为两条展示路径，互不影响；如需全局统一整数口径可后续一并调整。
5. 浮点安全：显示 Math.round(ratio*100) 与写回 Math.round(v)/100 对 0.29/0.33/0.34 等回归为正确整数；ratioSumOf 已 round2，Σ 判定含 0.01 容差，无精度误判风险。

---

六、结论

• 变更范围小、内聚：仅涉及默认比例生成与输入控件精度，核心金额与提交链路未动，尾部差异由既有 largest-remainder 兜底，2 人/1 人场景完全向后兼容。
• 测试已同步更新并新增 n=2/6/7 与 Σ=100 覆盖，TDD 口径清晰。
• 静态质检：新增 0 / 修复 0。
• 综合评估：低风险，可合入；建议后续视需要处理「只读意向展示口径」与「>100 人」两个非阻断边界。