代码清洁与整理指南

核心目标：

让代码意图清晰、自解释，大幅降低阅读和维护的认知成本。

主动询问，若用户未指定要清理哪些代码，就要主动询问要清理的代码的文件路径，或者某些模块，某些目录。

优先级最高的清理原则（先做这些，收益最大）

1. 去除无意义的包装层和冗余代码（最常见、最高优先级）
• 多余的单行箭头函数 / 简单 setter 包装
• 只用一次且名字没增加信息的中间变量
• 不必要的解构 + 重新组装对象
• 能用可选链 ?. / ?? 解决的复杂条件判断

1. 禁止把核心业务逻辑分散到副作用钩子中
• 坏：handleSubmit() → 改状态 → watch 监听到状态 → 执行保存
• 好：async handleSubmit() { 设置状态 → await 保存 → 更新状态 }
• 原则：能写成顺序代码的，尽量不要拆成「动作 + 监听」

1. 命名必须表达意图而非实现细节
• 差：handleData、changeStatus、doSubmit
• 好：submitFormAndNotifyTeam、toggleFavorite、formatPriceWithCurrency
2. 必须补充关键注释

至少要注释：

• 所有的响应式变量，函数，特别是核心业务函数
• 复杂的业务规则 / 计算逻辑
• 重要分支的「为什么」
• 边界情况 / 特殊处理的原因
• 难以从名字一眼看出的副作用

重要但次优先的改进点

• 结构与现代风格调整
• 函数过长（>30–40行）→ 拆成单一职责小函数
• 魔法值 → 抽取为命名常量（优先用 const enum / as const）
• 嵌套过深（>3层）→ 优先使用早返回（guard clause）
• 重复逻辑 → 抽取为 composable / util / shared hook

• 顺序与分组规范
• 推荐顺序（从上到下）：

1. import（分组：第三方 → @/别名 → ./相对路径）
2. 类型 / 接口 / const enum
3. 常量 / 配置
4. ref / reactive / 计算属性（数据）
5. 核心业务函数（按调用频率或重要性排序）
6. 事件处理函数（handleXxx）
7. 生命周期钩子 / watch / onMounted 等副作用（尽量少）

输出格式建议（给用户看改动时使用）

改动概要（用中文，简洁有力）
示例：
  - 删除了 4 处无意义单行函数包装
  - 合并了分散在 watch 中的保存逻辑到 handleSubmit
  - 优化命名：handleData → refreshAndNotify
  - 减少临时变量 5 个，代码行数减少约 18%
  - 核心业务逻辑增加 3 处「为什么」注释