不能只靠“查找结果”面板确认替换效果，因其仅做静态文本扫描，无法识别替换是否发生在注释、字符串或结构错乱处，不显示原始行与上下文，且无diff预览能力，无法反映真实文件变更。
全局替换后必须通过 Git 差异视图审查变更，而不是依赖“查找结果”面板——后者只显示文本匹配，不反映实际文件修改位置和上下文影响。
为什么不能只靠“查找结果”面板确认替换效果
VS Code 的“查找结果”面板（Ctrl+Shift+F）只做静态文本扫描，它无法识别：已替换内容是否在注释里、是否被正则误捕获、是否因换行或缩进导致结构错乱。更关键的是，它不显示被替换前的原始行，也没有上下文快照。一旦点下“全部替换”，操作不可逆（除非你提前提交 Git），而面板本身不提供 diff 预览能力。
- 常见错误现象：
Replace All后发现import { foo } from 'bar'被替成import { foo } from 'baz'，但面板里只显示“已替换 12 处”，没告诉你其中 3 处原是字符串字面量"bar" - 性能影响：大项目中反复用
Ctrl+Shift+F搜新旧内容会触发多次全盘扫描，比直接看 Git 更慢 - 真正可靠的方式是切换到
Ctrl+Shift+G（源代码管理视图），它基于文件系统实际变更生成差异，零延迟、带语法高亮、支持逐行 Accept/Revert
执行替换前必须做的三件事
避免“替完才发现改错了”的核心在于前置控制，不是事后补救。
- 确保工作区已打开：右下角状态栏不能显示
No folder opened；否则Ctrl+Shift+H退化为单文件操作 - 手动限定范围：点击搜索框下方的
files to include，填入src/**/*.ts或*.vue，绝不依赖默认全扫——node_modules和dist会被跳过，但__tests__或mocks可能被误中 - 先点
Find All（或回车），确认匹配项数量和上下文合理；如果出现Too many results提示，立刻加过滤条件，不要硬点Replace All
正则替换时 $1 引用失败的典型原因
写对正则不等于能正确替换，VS Code 对捕获组引用极其严格，稍有偏差就静默失效（不报错，也不替换）。
- 必须点亮
.*图标启用正则模式，且.（跨行匹配）按钮未被误点——它会让.匹配换行符，通常不需要 - 捕获组必须用
()，非捕获组(?:)不生成$1；例如import\s+(?:\{.*?\}|[\w]+)\s+from\s+['"](.+?)['"]中只有第二个()对应$1 - 替换字段中必须用
$1，\1是无效的；要输出字面量$abc，得写成$$abc - 常见翻车：正则写了
console\.log$$([^)]+)$$，但替换填了debugger; // \1→ 实际输出就是debugger; // \1，因为引擎只认$1
检查差异时最容易忽略的细节
Git 差异视图（Ctrl+Shift+G）虽直观，但几个关键点常被跳过：
- 绿色新增行里是否混入了不该有的空格或缩进？比如把
foo()替成bar()（末尾多一个空格），diff 会高亮整行，但肉眼容易漏看 - 红色删除行是否包含被连带删掉的注释或空行？例如正则
^\s*//.*$\n清注释时，若没加$锚点，可能误删// something后面的空行，破坏代码段落结构 - 修改文件是否全在预期路径下？有时
files to include写成**/*.ts，结果types/*.d.ts也被扫进来了，而你本意只改实现文件 - 如果项目没开 Git，或当前分支未提交，
Ctrl+Shift+G将不可用——此时唯一补救方式是立即关闭所有编辑器标签，用文件系统对比工具打开替换前后的备份目录
