IDEA的重命名与提取方法依赖语义分析，非简单文本替换：重命名仅处理可静态解析引用，漏改常见于字符串拼接、反射调用等场景；提取方法参数顺序由变量声明顺序决定，跨类调用需关注访问修饰符，默认private易致unresolved reference；每次操作后须通过Refactor Preview核验变更范围。
重命名和提取方法不是“改名字”或“切代码”那么简单，IDEA 的语义分析能力决定了它能不能真正安全地做这件事——关键看符号是否被正确识别、引用是否被完整扫描、跨文件变更是否受控。
重命名时为什么有些变量没被一起改？
IDEA 默认只重命名「可静态解析」的引用。常见漏改场景包括：
- 字符串拼接里的类名：
"com.example." + className不会被识别为引用 - 反射调用：
Class.forName("MyService")中的字面量不会触发重命名联动 - 注释或文档中的名称：除非在
Settings → Editor → General → Refactor → Rename → Search in comments and strings中启用，否则跳过 - JSX 属性值（如
<component name="OldName"></component>）：React 组件重命名默认不覆盖 props 字符串值
遇到漏改，先检查右下角是否弹出 Refactor Preview 窗口；没弹就按 Ctrl+Shift+Alt+P（macOS 是 Cmd+Shift+Option+P）手动唤出，逐个确认文件。
Extract Method 提取后参数顺序错乱怎么办？
IDEA 会按变量首次出现顺序推导参数，但局部作用域嵌套深时容易误判。比如：
String url = "https://api.com/" + id; int timeout = config.getTimeout(); HttpClient client = new HttpClient(); client.request(url, timeout);
若只选中最后一行 client.request(...) 提取，IDEA 可能按 url、timeout、client 顺序生成参数，而实际方法签名要求 client 在前——这会导致编译失败。
解决办法：
- 提取前手动调整变量声明顺序，让依赖靠前的变量先出现
- 提取后立即在生成的方法签名上按
Alt+Enter→ 选择Change signature重排参数 - 对 Kotlin，注意
val声明顺序不影响推导，但 Java 中字段/局部变量顺序直接影响参数列表
React 组件重命名后 setter 没同步更新？
只有 useState 的标准写法才会触发 setter 联动重命名：
- ✅ 支持：
const [count, setCount] = useState(0)→ 重命名count会建议改setCount - ❌ 不支持：
const state = useState(0)或自定义 hook 返回数组时，IDEA 无法识别语义 - ❌ 不支持：解构别名写法：
const [value, updateValue] = useState("")→ 重命名value不会动updateValue
此时必须手动改 setter 名，或改用标准命名约定（如 [xxx, setXxx]），否则后续维护容易出错。
提取方法后调用处报 unresolved reference？
最常见原因是访问修饰符自动降级：IDEA 默认把新方法设为 private，但若原代码在另一个类里调用，就会编译失败。
操作时注意：
- 提取前光标停在跨类可访问的位置（如
public方法内），IDEA 会倾向生成public方法 - 提取后立刻检查生成方法的修饰符，手动改为
protected或public，再按Ctrl+Shift+F6重命名整个方法（含调用处） - Java records 下提取方法，IDEA 可能忽略 record 的不可变性，生成带副作用的 setter —— 这种情况要删掉生成的方法，改用 record 的 with 方法或构造新实例
重构不是点一下就完事的动作，尤其是跨模块或涉及泛型、Lambda、函数式接口时，IDEA 的静态分析仍有边界。每次提取或重命名后，务必扫一眼 Refactor Preview 里的文件列表，重点盯第三方库路径、测试文件、配置类——这些地方最容易因“看似无关”被忽略，结果上线才暴露问题。
