重构应聚焦“难读、难改、易错”代码：拆分超25行函数或超4参数函数；提取深嵌套逻辑为命名函数；消除重复与魔法值；用语义化命名替代模糊标识符；以策略模式替代冗长条件分支；每次小改后立即验证行为不变。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
代码重构卡壳，不是能力问题，而是缺少清晰的切入点。与其从头重写，不如聚焦“哪里难读、哪里难改、哪里容易出错”——这些才是重构真正该优先解决的地方。
先找“一眼就累”的代码块
人眼对重复、过长、嵌套太深的代码天然排斥。这类代码往往意味着逻辑耦合紧、职责不清晰。
- 函数超过25行，或参数多于4个，大概率需要拆分
- 连续3层以上缩进（比如 if → for → if），建议提取成独立函数并命名其意图，例如 filterActiveUsers() 而不是 processData()
- 同一段逻辑在多个地方复制粘贴，哪怕只差一两行，也该封装为带参数的小函数
把“魔法值”和“模糊命名”换成会说话的名字
变量名、函数名不是占位符，是代码的说明书。AI能帮你快速识别并替换，但关键是要理解“为什么这个名更好”。
- bad：res、tmp、data1 → 不说明用途，下次看还是猜
- good：userPreferences、isEmailValid()、calculateDiscountForLoyaltyTier()
- 数字字面量别硬写，比如 if (status === 3) 改成 if (status === STATUS_PENDING) 或 if (isPending(status))
用小函数代替大条件分支
一长串 if-else 或 switch 很难维护，尤其当新增一种状态就得改多处。结构上更稳的方式，是让每个分支变成可测试、可复用的独立单元。
- 把每个分支逻辑抽成函数，再用对象或 Map 映射状态到处理函数，例如：handlerMap[status]?.execute()
- 相同判断条件反复出现（如 user.role === 'admin' && user.isActive），封装为 canAccessAdminPanel(user)
- 避免在条件里写复杂表达式，先赋值再判断，提升可读性和调试效率
重构不是一步到位，而是有节奏地验证
每次改完一小块，立刻运行测试或手动验证行为没变。这是安全重构的底线。
- 没有测试？先补1–2个关键路径的单元测试（比如输入X，输出应为Y）
- 改函数名或拆分函数时，IDE 的重命名功能比手动搜更可靠，别跳过这步
- 提交记录写清楚“为什么改”，比如：refactor: extract payment validation logic to validatePaymentRequest()，比 fix bug 有用十倍
