代码清洁与整理指南#

核心目标： 让代码 意图清晰、自解释，大幅降低阅读和维护的认知成本。 主动询问，若用户未指定要清理哪些代码，就要主动询问要清理的代码的文件路径，或者某些模块，某些目录。

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

1. 去除无意义的包装层和冗余代码（最常见、最高优先级）
   • 多余的单行箭头函数 / 简单 setter 包装
   • 只用一次且名字没增加信息的中间变量
   • 不必要的解构 + 重新组装对象
   • 能用可选链 ?. / ?? 解决的复杂条件判断
2. 禁止把核心业务逻辑分散到副作用钩子中
   • 坏： handleSubmit() → 改状态 → watch 监听到状态 → 执行保存
   • 好： async handleSubmit() { 设置状态 → await 保存 → 更新状态 }
   • 原则：能写成顺序代码的，尽量不要拆成「动作 + 监听」
3. 命名必须表达意图而非实现细节
   • 差： handleData、 changeStatus、 doSubmit
   • 好： submitFormAndNotifyTeam、 toggleFavorite、 formatPriceWithCurrency
4. 必须补充关键注释 至少要注释：

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

重要但次优先的改进点#

• 结构与现代风格调整
  • 函数过长（>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 等副作用（尽量少）

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

diff

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