webstorm无法直接提取if/else块为函数，因其要求片段必须语法完整、无控制流语句且为单一可求值表达式；可行方案是手动封装分支为具名函数并用shift+f6重命名维护一致性。
WebStorm 对 JavaScript 中复杂条件分支的重构支持有限，不能直接“提取 if/else 块”为独立函数或策略对象——它只接受语法完整、作用域自洽、无控制流中断的语句块。强行操作会报 Cannot extract fragment 或生成不可用代码。
为什么 Extract Method 在 if/else 里总失败
WebStorm 的 Extract Method（Ctrl+Alt+M）拒绝处理含 return、break、continue、throw 的片段，而真实业务中的条件分支常包含这些。更关键的是：它不识别“逻辑边界”，只认 AST 节点边界。
- 选中
if (user) { doSomething(); }中的doSomething();一行？可以，但只是抽一个调用，没解决分支复杂性 - 选中整个
if (...) { ... } else if (...) { ... } else { ... }？失败——因为 WebStorm 认为这不是一个可求值的表达式，也不是单一语句（它是 StatementList，不是 ExpressionStatement） - 在 React 组件里选中
if (loading) return <spinner></spinner>;？必然失败，return在 JSX 上下文外，且跨了 JS 和 JSX 边界
可行的替代路径：手动拆解 + 语义重命名
与其强求自动提取，不如分两步把条件逻辑显性化，再让 WebStorm 帮你安全更新引用：
- 先把每个分支体封装成具名函数：
handleActiveUser()、handleInactiveUser()、handlePendingUser()，写在条件判断外部 - 用
Shift+F6重命名这些新函数名——确保光标停在函数名上、文件类型是 JavaScript、右下角显示JavaScript而非Plain Text - 原条件块内只留调用：
if (user.status === 'active') handleActiveUser();，这样后续改分支逻辑时，只需改对应函数体，不碰条件结构
Extract Method 成功的最小可行单元
若坚持用 Extract Method，必须满足三要素：闭合、无跳转、纯计算。例如以下代码可安全提取：
const discount = calculateDiscount(user, order); const finalPrice = order.total * (1 - discount);
选中这两行（光标停在第一行开头），按 Ctrl+Alt+M → 得到 calculateFinalPrice(user, order)。但一旦加入 if (user.isVIP) { ... }，就不再符合。
- 提取后参数顺序按“首次读取”排列，不是声明顺序；想调整顺序，得先改原代码里变量使用次序
- 若原上下文有
this或闭包变量（如const id = props.id），提取后函数默认不带this绑定，需手动加.bind(this)或改用箭头函数 - React 函数组件中，提取出的函数不会自动套
useCallback，传给子组件前得自己补
真正需要重构的，其实是条件本身
当条件分支超过 3 层、嵌套深度 ≥2、或判断依据分散在多处时，问题不在“怎么抽”，而在“为什么还在用 if/else”。WebStorm 做不了策略模式自动转换，但能帮你稳住迁移过程：
- 用
Shift+F6把所有user.type === 'admin'重命名为user.role === 'admin'，确保类型字段统一 - 移动新策略类到
src/strategies/后，检查import路径是否自动更新——若没变，说明tsconfig.json的baseUrl和paths没被 WebStorm 识别，去Settings > Languages & Frameworks > TypeScript > Compiler勾选Use paths mapping from tsconfig.json - 最后删掉旧条件分支前，用
Find Usages（Alt+F7）确认无残留调用
复杂条件的重构，本质是把隐性规则显性化。WebStorm 不会替你设计策略，但它能确保每一步变量名、函数名、导入路径都精确同步——前提是别让它在语法边界外强行工作。
