VSCode内置重命名不等于安全重构，因其仅作用于Java源码AST节点，不扫描application.properties、@MapperScan字符串、MyBatis XML等非Java文件，且默认跳过配置文件、XML、JSON、YAML，无法处理反射调用或注解值变更，故无法保障跨文件、跨模块、运行时依赖的一致性。
VSCode 市场上标榜“智能重构”“一键优化”的插件，绝大多数不具备代码语义理解能力，其所谓“安全边界”本质是静态文本替换 + AST 节点遍历的组合，不校验业务逻辑、不感知运行时依赖、不检查配置文件外的副作用。真正在生产环境敢用的，必须满足三个硬条件：能识别注解值变更（如 @Component("user-service")）、能覆盖非 Java 文件引用（application.yml 中的类名字符串）、能拒绝跨模块硬编码字符串匹配（如 "UserService" 在工厂方法里的字面量）。
为什么 Refactor > Rename 本身不等于安全重构
VSCode 内置的 Java 重命名（通过 Extension Pack for Java）只作用于 AST 可解析的 Java 源码节点。它不会扫描：application.properties 里 service.class=user.UserServiceImpl 这种键值对；不会进入 @MapperScan(basePackages = "com.example.dao") 的字符串字面量；更不会处理 MyBatis XML 中 <select id="getUser" resultType="user.UserVO"> 这类硬编码类型名。
- 默认关闭
Include non-Java files，意味着配置文件、XML、JSON、YAML 全部被跳过 - Spring Boot 的
@ConditionalOnClass或@EnableAutoConfiguration注解中引用的类，不会触发自动更新 - 若类被反射调用（如
Class.forName("user.UserService")），AST 无法推断该字符串是否应随重命名同步修改
自动化重构插件常见的三类越界行为
很多插件打着“AI 重构”旗号，实则在 AST 层之外做危险操作：
- 直接正则替换整个工作区，把
UserService替成UserManager，结果把日志里的"UserService is unavailable"也改成了"UserManager is unavailable" - 调用
vscode.workspace.findFiles()扫描所有文件后强行写入，绕过 VSCode 的编辑器变更校验机制，导致 Git 差异混乱、Pre-commit Hook 失效 - 在后台启动子进程执行
mvn compile或gradle classes，并读取编译错误来“反推”引用位置——这会污染本地构建缓存，且在 Windows 上常因路径转义失败而静默丢弃部分结果
如何验证一个重构插件是否可信
别信宣传页，直接看它对以下场景的处理：
- 当类
UserDao被重命名为UserRepository时，它是否识别出application.yml中mybatis.mapper-locations: classpath:mapper/UserDao.xml需要同步改为UserRepository.xml？ - 它能否区分
@Value("${user.service.class}")（应保留）和@Value("user.UserServiceImpl")（应更新）？ - 执行前是否生成可审查的变更预览列表，并明确标注每一处修改来源（AST / 字符串 / 正则）？
- 是否提供回滚命令（如
Refactor: Undo Last Rename），而不是只靠 Git checkout 恢复？
真正关键的不是“能不能改”，而是“改完之后你敢不敢立刻提交 CI”。大部分插件卡在这一步——它们不暴露修改依据，也不留审计痕迹，一旦出错，只能靠人工逐行比对。
