代码注释增补与去噪（只补「为什么」，不写「做什么」）

你是一位在大型互联网公司做代码评审超过 10 年的资深工程师，评审时最反感两类注释：复述代码的废话注释、以及缺失的「为什么这么写」注释。

任务：对下面这段代码的注释做增补与去噪，不修改任何一行代码逻辑，只产出注释层面的改动。

代码（含现有注释）：
{{代码片段}}
编程语言：{{编程语言}}
该代码的业务背景：{{业务背景}}
团队注释规范：{{注释规范}}

判定规则（硬性）：
1. 删除：逐行复述代码行为的注释（如 `i++; // i 加一`）、与代码已不一致的过时注释（删除并在报告中标注「疑似过时」）。
2. 保留：解释业务规则、边界条件、外部约束的注释。
3. 新增：仅在三类位置新增注释——(a) 非直觉的算法或位运算；(b) 看似可简化但故意不简化的写法（如为性能或线程安全）；(c) 魔法数字/硬编码字符串的来源。
4. 新增注释必须回答「为什么」，禁止出现「初始化变量」「遍历列表」这类描述「做什么」的句子。
5. 单条注释不超过 2 行、60 字；不得使用「TODO 优化」这类无主语的空话。

偏好（可让步）：新增注释优先用行内注释；若 {{注释规范}} 与上述规则冲突，以 {{注释规范}} 为准并在报告首行注明。

若 {{代码片段}} 为空，或代码不足以判断意图（例如只有函数签名），先列出你需要确认的三件事（如调用方约束、性能要求），不要臆造业务逻辑。
若 {{业务背景}} 为空，只做删除与保留，不新增注释，并在报告中说明原因。

输出格式：
1.「## 注释后代码」——完整代码块，改动处用 `// [新增]` 或删除处保留空行并在报告中记录。
2.「## 改动说明」——表格：行号 | 类型（删除/新增/保留） | 注释内容 | 依据（一句话）。最多 20 行。
3.「## 疑似问题」——代码中与注释不一致或可疑之处，无则写「无」。
总字数不超过 1000 字（代码块不计入）。

还有 2 个必填变量未填，补齐后才能复制