VS Code全局替换前必须先执行“查找全部”预览。需确认已打开完整项目、正确设置大小写/正则/全字匹配选项，并在“包含文件”中限定范围；预览时须展开上下文检查语义、路径及结构；替换后务必通过Git差异视图验证变更；高风险场景推荐用多光标编辑预览式修改。
点击“查找全部”前先确认搜索范围和模式
VS Code 的全局替换预览，本质是“查找全部”的结果列表——它不是独立功能，而是替换操作的前置步骤。很多人点 Ctrl+Shift+H 后直接输词就按“全部替换”，结果发现改错了地方，根本原因就是跳过了这一步预览。
关键动作有三个：
- 确保已通过
File → Open Folder…打开了完整项目（状态栏不能显示No folder opened） - 检查搜索框右上角三个按钮状态：
Aa（大小写）、.*（正则）、^$（全字匹配）是否符合你当前需求；比如搜user却把username也替了，大概率是没开^$ - 在“包含文件”框里填好范围，例如
**/*.ts或src/**/*.{js,jsx}，否则预览结果可能漏掉目标文件或混入无关文件
预览时重点看上下文展开和文件路径
点击“查找全部”后，左侧“查找结果”面板会列出所有匹配项。但默认只显示单行，容易误判——比如 console.log("user") 和 const user = 看起来一样，实际语义完全不同。
必须手动点击每条结果左侧的 ▶ 展开上下文（默认显示前后 2 行），快速确认：
- 匹配是否出现在字符串字面量、注释或正则字面量中（这类通常不该动）
- 所在文件路径是否合理（比如
node_modules/下的匹配，除非你明确要改依赖源码） - 是否有意料之外的嵌套结构（如 JSX 中的
className="user"vsdata-user="123"）
如果一次展开太多影响判断，可以先在“排除文件”里临时加 **/node_modules/** 或 **/dist/** 过滤干扰项。
用 Git 差异视图验证替换前后的实际变更
“查找结果”只是静态匹配，真正生效的修改得靠 Git。这是最容易被跳过的环节，也是唯一能看清“到底改了什么”的方式。
操作很简单：
- 执行替换前，确保工作区干净（
git status无未提交变更），或至少已git add -A && git commit -m "before global replace" - 替换完成后，按
Ctrl+Shift+G切到源代码管理视图 - 点开任一被修改的文件，VS Code 显示的 diff 是红绿高亮的原始对比：红色是被删掉的旧内容，绿色是新内容，连空格、换行、缩进差异都一目了然
特别注意：diff 里如果出现大段绿色新增或红色删除，说明你的正则可能跨度过大（比如用了 .* 却没加 ? 非贪婪修饰），或者替换内容意外破坏了语法结构（如 JSX 闭合标签错位）。
多光标预览式编辑比“全部替换”更可控
当你对某类匹配有疑虑，又不想逐个点“替换”按钮，可以用多光标模拟预览效果：
- 在“查找结果”面板中，按住
Ctrl（macOS 为Cmd）点击多个你认为安全的匹配项 - 全部选中后按
Enter，VS Code 会跳转到第一个位置，并在所有选中处创建光标 - 此时输入替换内容，所有光标同步变化；如果发现某处格式崩了（比如缩进错乱、引号不闭合），立刻
Esc退出，回去调正则
这个技巧适合小批量、高风险替换（比如改 CSS 类名、Vue 组件名），它把“试错成本”压到最低——毕竟 Ctrl+Z 只能撤回最后一次操作，而多光标编辑是实时可中断的。
真正难的不是怎么替换，而是怎么确认“这里确实该被替换”。预览不是走形式，是重构前的最后防线。一旦跳过，修复成本远高于重做一遍。
