使用Ctrl+Shift+F或Cmd+Shift+F打开全局查找替换面板，输入查找与替换内容，在Where中设置并排除node_modules等目录，启用正则可捕获分组实现复杂替换，替换前提交Git以便回滚，替换后通过git diff检查修改、运行测试验证功能，并用原字符串再次搜索确认无遗漏。
Sublime Text里想在整个项目里批量替换字符串，其实就是用它内置的“在文件中查找/替换”功能。这玩意儿是处理大规模代码重构、统一命名规范的利器，比你一个文件一个文件地手动改，效率高了不知道多少倍，还能大大降低出错的概率。
解决方案
在Sublime Text中进行项目全局搜索与替换，操作路径很直接：
-
打开查找/替换面板： 使用快捷键
Ctrl+Shift+F
(Windows/Linux) 或Cmd+Shift+F
(macOS)。这会弹出一个专门的面板，而不是普通的行内查找。 - 输入搜索内容 (Find What): 在第一个输入框里，填入你想要查找的字符串。
- 输入替换内容 (Replace With): 在第二个输入框里，填入你希望替换成的新字符串。
-
配置搜索范围 (Where): 这是关键。
- 默认通常是
，你需要改成
来表示当前打开的项目。 - 你也可以指定具体的文件夹路径，或者用逗号分隔多个路径。
- 高级用法：使用
-
来排除某些文件或文件夹，比如
会在项目内搜索，但排除所有, -*.min.js, -build/* .min.js
文件和build
文件夹。
- 默认通常是
-
调整匹配选项：
.*
(Regex): 启用正则表达式匹配，这对于复杂模式的查找和替换非常有用。Aa
(Case Sensitive): 区分大小写。Ab
(Whole Word): 全词匹配，只匹配完整的单词。
- 执行查找： 点击“Find”按钮，Sublime Text会在底部的输出面板中列出所有匹配项。你可以逐个查看这些匹配项，确认它们是否是你想要替换的。
-
执行替换：
- Replace： 选中输出面板中的某一个匹配项，点击“Replace”会只替换当前选中的那一个。
- Replace All： 点击“Replace All”会一次性替换所有匹配项。注意： 在点击“Replace All”之前，务必确认你的搜索和替换规则是正确的，因为这个操作是不可逆的（除非你用了版本控制）。
为什么项目全局替换如此重要？它能解决哪些痛点？
说实话，作为写代码的人，谁没遇到过那种改个变量名、调整个函数接口，结果发现几十上百个文件里都有引用，然后不得不像个机器人一样逐个点开、修改、保存的经历？那感觉简直是噩梦。项目全局替换的重要性，就在于它能把我们从这种重复、低效、还容易出错的体力活中解放出来。
想想看，当你的项目从一个老旧的API切换到新版，或者团队决定统一某个命名规范，比如把
user_id改成
userId，如果靠手动，你可能要花一整天，甚至更长时间，而且还保不齐哪个角落漏掉了，导致运行时出bug。我以前就吃过这种亏，一个不起眼的文件没改到，结果上线后某个边缘功能直接崩了。这种痛点，全局替换简直是解药。它不仅能瞬间完成大量修改，更重要的是，它保证了修改的一致性，大大降低了人为错误的风险。对我们开发者来说，这不仅仅是效率提升，更是代码质量和项目稳定性的保障。
Sublime Text进行批量替换时，有哪些高级技巧可以提升效率？
要说Sublime Text在批量替换上的高级玩法，正则表达式（Regex）绝对是排在第一位的。这玩意儿一旦用熟了，简直是无所不能。
比如，你想把所有
getUserInfo(id)这种调用，改成
fetchUserInfo({ userId: id })，如果只是简单的字符串替换，你可能得写好几条规则。但用正则，一条命令就能搞定：
-
查找 (Find What):
getUserInfo\((.*?)\)
-
替换 (Replace With):
fetchUserInfo({ userId: $1 })
这里的
(.*?)是一个捕获组，它会匹配括号里的任何内容（非贪婪模式），然后
$1在替换时就代表了捕获到的第一个组的内容。这只是个简单的例子，正则表达式的强大之处在于它可以匹配复杂的模式，比如特定格式的注释、HTML标签属性、或者有条件地替换。
另一个提升效率的技巧是精确控制搜索范围。在“Where”字段里，除了
，你还可以用逗号分隔来包含多个文件夹，或者用
-来排除不需要搜索的文件类型或文件夹。比如，我经常会排除
node_modules这种第三方库目录，或者
.min.js这种压缩文件，避免误改或者搜索结果过于庞杂。
-
示例：
这表示在整个项目里搜索，但跳过, -node_modules/, -*.min.js node_modules
文件夹和所有.min.js
文件。
还有就是大小写敏感和全词匹配的按钮，它们虽然看起来简单，但在特定场景下能避免很多不必要的替换。比如，你只想替换
color这个单词，而不是
backgroundColor里的
color，全词匹配就能派上用场。
批量替换操作后，如何确保代码的正确性和稳定性？
批量替换这活儿，虽然高效，但风险也并存。一旦操作失误，那可就是“牵一发而动全身”了。所以，替换完之后，怎么确保代码没出问题，这比替换本身更重要。
首先，也是最关键的，版本控制系统（比如Git）是你的救命稻草。在执行任何大规模替换前，我都会习惯性地提交一下当前的工作。这样，万一替换结果不理想，或者引入了新的bug，我可以随时
git reset --hard HEAD回滚到替换前的状态，或者
git stash起来，给自己留条后路。替换完成后，第一件事就是
git diff，仔细检查所有被修改的文件，看看改动是不是符合预期，有没有意外的修改。
其次，测试是验证正确性的核心。如果你有单元测试、集成测试，甚至端到端测试，跑一遍这些测试套件，是最直接、最有效的验证方式。如果测试都通过了，那至少说明基本功能没受影响。要是没有测试，那也得手动跑一遍项目，把所有相关的功能点都点一遍，确保没问题。
再者，对于特别复杂或者影响范围大的替换，我会考虑分批次进行。先替换一小部分，验证没问题后，再进行下一批。这样即使出了问题，排查范围也小得多。
最后，替换完之后，用旧的字符串再做一次全局搜索，确认一下是不是真的全部替换掉了，或者有没有遗漏。这就像是给自己做个双重检查，多一层安心。毕竟，代码的稳定运行，才是我们最终追求的目标。
