# 重构安全 (Refactoring Safety)

在做重命名、清理、自动修复 lint 等「结构调整」时，**必须防止改变原有行为**。

## 1. 不要盲目「修完」Lint / 格式化工具的所有告警

### 核心原则

静态规则（含 ESLint / clippy / 等）有时会与**有意为之**的代码写法冲突。机械地「全绿」可能改变行为（例如额外的依赖项触发更多次执行、循环或副作用）。

**操作前自问**：

1. 这条规则想防什么？当前代码是否**故意**违反以满足别的目标？
2. 若按工具建议改，会不会多触发副作用、循环或性能问题？
3. 若必须抑制规则，是否加了**简短注释**说明原因？

若存在**闭环风险**（例如：状态更新 → 重渲染 → 某依赖变化 → 再次触发同一逻辑），**不要**仅为了消告警而改逻辑；应保留原意并显式注明抑制原因（按项目语言规范使用 `eslint-disable`、`#[allow(...)]` 等）。

### 附录：前端 Hooks 依赖数组（React 等）

`useEffect` / `useCallback` 的依赖数组有时**有意不完整**，用于控制触发频率或打破循环。将不稳定引用（如每次渲染新建的函数）加入依赖可能导致无限循环。此类情况：**理解原意后再改**，必要时保留不完整依赖并注释说明（见项目 `code-standards` 与具体框架文档）。

---

## 2. 重构的定义与验证矩阵

- **重构** = 只改结构，**不改行为**。
- 重命名、提取函数、收窄类型时，须保证原有输入组合下行为一致，并覆盖 **null / undefined / 空串 / 边界值**。
- 对依赖「分支枚举」的逻辑，用表格列出「输入 → 预期行为」，改后逐项核对。

**类型比较方式变更时**（例如从数字比较改为字符串比较）特别注意 **null/undefined** 与旧行为是否一致。

---

## 3. 重构与功能变更隔离

- **不要**在同一 PR/提交里混用：纯重构、行为修复、新功能。分开提交便于回滚与定位。
- **自检清单**：
  - [ ] 所有调用方参数已同步
  - [ ] 边界值行为与改前一致
  - [ ] 未仅为消告警而改动执行路径
  - [ ] 关键路径已手动或自动测过

---

## 4. 教训摘要

盲目「修复」静态分析告警而**未理解原依赖/执行顺序设计**，是常见回归来源。工具建议 ≠ 必须照做；先对齐意图再改。