Sublime Text 做 Legacy 代码重构不是省事而是埋雷，因其不理解语法结构，易将 user 全局替换为 customer 而误伤 username 等；它仅适合纯文本批量清理（如删空行、统一缩进），涉及语义变更须用 AST 工具。
为什么直接用 Sublime Text 做 Legacy 代码重构不是“省事”，而是“埋雷”
Sublime Text 本身不理解语法结构，所谓“快速重构”很容易变成全局替换式暴力操作，把 user 替成 customer 时顺手把 username、debug_user 也干掉了。它适合做文本层面的批量清理（比如删空行、统一缩进），但一旦涉及变量重命名、函数签名变更、依赖关系调整，就该让位给真正懂 AST 的工具。
哪些操作 Sublime Text 确实能又快又稳地完成
前提是明确知道改的是纯文本，不跨作用域、不碰语义：
- 用
Ctrl+H（Windows）或Cmd+H（macOS）打开替换面板，勾选Match Case和Whole Word，避免误伤 - 正则替换清理注释残留：
// TODO:.*→ 空，但注意别匹配到字符串里的// - 批量修正缩进：选中代码块 →
Ctrl+Shift+P→ 输入Indentation: Convert to Spaces或Indentation: Reindent - 用
Ctrl+Shift+F全局搜索eval(、document.write(这类高危调用，人工逐个确认而非一键替换
遇到 ReferenceError: xxx is not defined 别急着搜变量名
Legacy JS（尤其没模块化、靠 script 标签顺序加载的）里，变量作用域和执行时机比想象中脆弱。Sublime Text 搜索 xxx 可能命中 20 处，但真正出错的只是某处 var xxx = ... 被删掉或挪到了调用之后。
- 先用浏览器开发者工具定位报错行号，再回 Sublime Text 查看上下文，而不是无脑全局改
- 搜索时加引号限定范围：
"xxx"匹配字符串，xxx =匹配赋值，function xxx匹配函数声明 - 对疑似全局变量，用
Ctrl+Shift+P→Find in Files搜window.xxx或this.xxx，确认是否真被挂到全局
别让插件自动帮你“优化”老旧语法
像 JsFormat 或 ESLint-Formatter 这类插件默认按现代标准格式化，会把 var a = 1, b = 2; 拆成两行，把 if (a) {b();} 加上换行和空格——看似整洁，实则可能触发 IE8 下的 ASI（自动分号插入）bug 或破坏原有压缩逻辑。
- 禁用所有自动格式化插件，或在项目根目录加
.jsbeautifyrc显式关闭brace_style和space_in_empty_paren - 如果必须格式化，先用
git stash保存现场，格式化后运行原环境测试用例，再决定是否保留 - 对
with、arguments.callee这类已废弃但仍在跑的语法，Sublime Text 不会警告，人得自己盯住
Legacy 代码的“重构”本质是逐步解耦和验证，不是一次性的文本手术。Sublime Text 是刀，但刀不负责判断哪块肉该切、哪根筋不能断。
