接到一个旧后台项目国际化改造的需求时，我第一个动作就是在 VSCode 里全局搜代码中的中文字符。这件事听起来极其简单，真做起来你才会发现一个正则根本不够用：注释里有中文、模板字符串里有中文、配置文件里有中文、甚至有人把中文写进了 Unicode 转义，搜索直接漏掉。这篇博文把我在这类任务里实际用过的 VSCode 正则方案、命令行替代方案和落地工程化的流程一起整理出来，给正在做国际化改造、排查乱码，或者单纯想清理代码里硬编码中文的开发者，省去反复试错的时间。
即便是只查一次，也有很多细节能直接影响搜索结果准不准：正则范围要不要覆盖扩展区、全角标点算不算中文字符、GBK 编码文件搜不搜得到，这些我都会一一讲到。先说明白"你以为在找什么"，比直接甩正则命令更重要。
1. 先搞清楚"找中文"这件事到底难在哪
1.1 你需要找中文字符的三个典型场景
大多数人打开 VSCode 搜索中文字符，都是为下面三件事之一。
第一是国际化改造。接到 i18n 任务，第一步永远是把所有硬编码在代码里的中文文案捞出来。这时候你搜索的目标不是"哪一行有中文"，而是"哪些文案需要被替换成词条 key"，所以注释里的中文、代码里的 console 日志、临时写死的 mock 数据，都会成为干扰项。
第二是乱码排查。文件编码被搞乱之后，页面上显示一堆"锟斤拷"或者问号，你需要在代码里定位出问题的源头，看看是不是有人往 UTF-8 文件里塞了 GBK 中文字符。这个场景下，你要找的不仅是中文字符，还包括校验哪些文件编码不符合项目规范。
第三是代码规范约束。有些团队规定代码中不允许出现中文字符串字面量，或禁止在注释以外的地方硬编码中文。这种场景下，你要找的是"违反规范的行"，精确度要求最高。
这三个场景的目标不同，最终选择的方法和正则就有差异。我见过不少开发者在 VSCode 里搜一个"中"字就开始替换，结果把注释里的示例文案也替换成了乱七八糟的 token，这就是目标没定义清楚。
1.2 代码里的中文有四种藏法，漏掉任何一种都不完整
直接搜索"中文"这两个字，最多只能覆盖普通字符串里的情况。我在实际项目中总结过，代码里的中文字符有四种常见藏法。
第一种是普通字符串，最直接，搜索就能看到。第二种是注释和文档里的中文，这类文本通常不需要做国际化，但在全量扫描时会被搜出来，制造大量噪音。第三种是模板字符串和变量拼接，比如`你好，${name}`、"今天天气" + weatherText，如果只搜"你"或"天气"还能找到，但如果是const prefix = getName(); text = prefix + "登录页面"这种，搜索关键词法就完全失效，必须用字符范围正则一网打尽。
第四种最阴间：Unicode 转义。有些编译工具、压缩脚本会把字符串变成'\u4f60\u597d'，这个在源代码层面根本看不到汉字，但浏览器执行结果就是"你好"。我接手过一个项目，混淆脚本把大量中文转成了\uXXXX，我用普通中文关键词搜索完全搜不到，后来一查发现匹配\\u[0-9a-fA-F]{4}才能找出来。如果你做国际化改造，这类转义字符也是实实在在需要处理的文案来源，千万别漏。
所以"查找代码中使用的中文字符"不是一个搜索动作，而是一套匹配策略。下面先讲 VSCode 里最快见效的内置方案。
2. VSCode 内置搜索：最快见效的正则方案与使用技巧
2.1 最小可用正则：[\u4e00-\u9fa5] 怎么用
VSCode 的全局搜索面板默认是不启用正则的，用的时候记得先点搜索结果框右侧的.*切换按钮。开启之后，在搜索框输入[\u4e00-\u9fa5]，回车就能匹配出所有包含基本汉字 U+4E00 到 U+9FA5 的行。
这个范围覆盖了绝大部分简体中文常用字，日常项目里用它做第一轮粗扫足够了。但这里有个体验问题：如果一行代码里既有英文也有中文，默认搜索只会高亮中文字符本身，你不会看到这一行前面的上下文。所以我更推荐搜索.*[\u4e00-\u9fa5].*，这样整行内容都会出现在结果里，方便判断这行是普通代码、注释还是字符串。
如果你只想在某个目录或某种文件类型里搜索，不需要额外配置目录：把光标放在文件资源管理器里的目标文件夹上，右键选择"在文件夹中查找"，搜索范围就自动限定在这个文件夹下。我经常用这个方式先扫src/pages，再单独扫src/components，分模块清点存量。
2.2 进阶正则：尽量只匹配代码字符串、减少注释干扰
直接搜中文字符，注释一定会一起出现。如果你搜出来的 500 条结果里有 300 条是注释，肉眼筛起来很痛苦。这时候可以把正则改成看起来像"引号内的中文"的匹配模式。
一个常用的写法是：
["'`][^"'`]*[\u4e00-\u9fa5][^"'`]*["'`]这个正则的含义是：先匹配一个引号（单引号、双引号或反引号），然后匹配任意个非引号字符，中间必须有一个中文字符，最后再匹配一个闭合引号。这样能把大部分字符串字面量捞出来，同时把纯注释行过滤掉，因为注释里的中文通常不在引号内。
不过要提醒一句，这个正则在真实项目中会有误报和漏报。误报出现在 HTML 属性里，比如<div title="中文提示">，引号内是中文但根本不需要做国际化；漏报出现在字符串拼接场景，比如"前缀" + name + "后缀"，中间被变量隔开，这个正则也会漏。所以进阶正则只能作为辅助筛选，不能盲信结果。
2.3 缩小搜索范围：files.exclude 与 search.exclude 的区别
VSCode 里有两个"排除"配置，很多人分不清。files.exclude控制的是文件资源管理器里哪些文件不显示，search.exclude控制的是搜索时哪些文件被跳过。如果你只想让搜索跳过 node_modules 和构建产物，去搜设置里改search.exclude就对了；改files.exclude虽然也能影响搜索，但副作用是整个资源管理器里的目录都隐藏了，容易误事。
我实际使用的检视配置里，通常会添加下面几个：
{ "search.exclude": { "**/node_modules": true, "**/dist": true, "**/build": true, "**/coverage": true, "**/*.min.js": true } }配置好后，再搜[\u4e00-\u9fa5]，结果数量通常会减少三分之一以上。另一个小技巧是搜索结果面板右上角的下拉菜单里可以直接按文件类型筛选，比如只看 TypeScript 文件，或者只看 Vue 文件。先按文件类型把搜索范围箍住，再做正则匹配，效率会高很多。
3. 边界比主路更考验人：标点、转义、编码和注释干扰
3.1 中文标点和全角符号要怎么一起找
[\u4e00-\u9fa5]只能匹配汉字，匹配不了中文标点。很多人清理中文字符时会忽略，代码里出现的，、。、！、；、全角括号（），也是硬编码中文的一部分。尤其是用户提示语和前端展示文案，这类的全角标点非常常见。
要一起找出来，可以把正则范围扩展为：
[\u3000-\u303F\uFF00-\uFFEF\u4e00-\u9fa5]其中\u3000-\u303F是中文标点区（包含顿号、句号、书名号等），\uFF00-\uFFEF是全角 ASCII 和全角标点区。这里有个小坑：\uFF00-\uFFEF也包含全角数字０１２３和全角英文字母ＡＢＣ，如果你只想找中文标点，不想要全角数字，需要把正则继续收紧到\uFF01-\uFF0F、\uFF1A-\uFF20、\uFF3B-\uFF40、\uFF5B-\uFF65这几个区间。
我在一次清理中就用这个正则把一些隐藏得很深的全角括号找了出来。当时页面上报了文案截断问题，代码里写的是（测试）而不是(test)，普通中文搜索搜不到括号，用上面这个扩展正则一搜，问题立刻暴露。
3.2 文件编码不是 UTF-8 时为什么搜不中
这是一个极容易被忽略的坑。VSCode 默认按 UTF-8 解码文件，如果你的项目里混着 GBK/GB2312 编码的源码，搜索框的[\u4e00-\u9fa5]可能搜不到中文字符，或者搜出来的内容在编辑器里显示为乱码。
遇到这种情况，先点开 VSCode 右下角的编码按钮，看看当前文件显示的是 "UTF-8" 还是 "GBK"。如果是 GBK，可以选择"通过编码重新打开"，改成 UTF-8 后重新搜索。我处理过一次某团队遗留的项目，十几个遗留页面文件全是 GBK 编码，全局搜索中文字符怎么都搜不全，最后用命令行批量把编码转换了才完成后续扫描。
批量转换时如果不想装额外工具，用系统自带的 iconv 就行：
iconv -f GBK -t UTF-8 target.js > target_utf8.js转换完再对比一下文件内容有没有变化，防止某些字符在转码过程中丢失。
3.3 注释里的中文：该不该查，按场景定
注释里的中文本质上不参与程序运行，如果是国际化改造，注释里的中文不用翻译；如果是排查页面乱码，注释里出现乱码完全可以忽略。但搜索时它一定会被搜出来，所以你需要先想清楚策略。
我的经验是分两轮处理：第一轮用[\u4e00-\u9fa5]全量扫一遍，谁也别漏；第二轮把搜索结果导出到文本文件，在编辑器里批量把明显以//或/* */开头的行删掉，剩下的才是真正需要处理的代码文案。这种做法比一开始就追求"精确排除注释"要高效得多，因为你根本不需要在每一步都做词法分析。
如果项目很大，注释中文和代码中文混在一起实在太多，可以考虑用脚本拼接注释节点信息来精确过滤，但这通常意味着引入编译器级别的解析能力，性价比不高。中小项目先用 VSCode 搜索结果人工筛一轮，反而更快。
4. 仓库大了之后，命令行和脚本更可靠
4.1 ripgrep：一条命令扫全仓并输出报告
当项目文件数量超过几千，VSCode 搜索结果面板会开始卡顿，打开一个大文件时尤其明显。这时候我把主力工具切换成 ripgrep，也就是rg命令。
ripgrep 支持 Unicode 字符类，可以直接匹配汉字，写法非常优雅：
rg -n "\p{Han}" src --glob '!**/node_modules/**' > cn_report.txt\p{Han}表示所有汉字 Unicode 属性，比[\u4e00-\u9fa5]覆盖得更全面，包括扩展区汉字和兼容汉字。-n输出行号，配合> cn_report.txt把结果落到文件里，后续可以慢慢筛。
想排除某些目录或文件，用--glob参数加排除规则。想同时匹配中文标点，可以把正则改成[\p{Han}\u3000-\u303F\uFF00-\uFFEF]。ripgrep 默认还会尊重.gitignore，意味着 node_modules、dist 这些已经被忽略的目录不会出现在结果里，这比 VSCode 默认的搜索行为更省心。
如果团队还在用 grep，注意 GNU grep 和 BSD grep 的区别。Linux 上grep -rP '[\x{4e00}-\x{9fa5}]'可以用 Perl 正则匹配 Unicode 范围，但 macOS 自带的是 BSD grep，不支持-P，会直接报错。所以我更推荐统一用 ripgrep，跨平台行为一致。
4.2 用 Node 写一个十来行的扫描脚本做精细过滤
命令行适合快速粗扫，但要做到可配置的精细过滤，还是得写脚本。我用 Node 写了一个简单的扫描器，核心逻辑只有十几行，却能解决 VSCode 搜索结果面板在大仓库里的性能问题。
const fs = require("fs"); const path = require("path"); const ROOT = process.argv[2] || "src"; const SKIP_DIRS = new Set(["node_modules", "dist", "build", ".git", "coverage"]); const ALLOWED_EXTS = new Set([".js", ".jsx", ".ts", ".tsx", ".vue", ".html", ".css", ".scss", ".json"]); const CN_CHAR = /[\u4e00-\u9fa5]/; function walk(dir, results = []) { for (const ent of fs.readdirSync(dir, { withFileTypes: true })) { if (ent.isDirectory()) { if (!SKIP_DIRS.has(ent.name)) walk(path.join(dir, ent.name), results); } else if (ent.isFile() && ALLOWED_EXTS.has(path.extname(ent.name))) { const filePath = path.join(dir, ent.name); const lines = fs.readFileSync(filePath, "utf8").split("\n"); lines.forEach((line, index) => { if (CN_CHAR.test(line)) { results.push(`${filePath}:${index + 1}: ${line.trim()}`); } }); } } return results; } const list = walk(ROOT); fs.writeFileSync("cn_report.txt", list.join("\n"), "utf8"); console.log(`扫描完成，共 ${list.length} 行包含中文字符`);这个脚本按照文件扩展名过滤，自动跳过依赖目录，输出格式和 ripgrep 一致。如果遇到 GBK 编码文件，可以先在脚本里用iconv-lite这类库做转码再匹配，防止结果遗漏。
4.3 把扫描结果固化成可复用配置
脚本写完后，别用完就删。把它提交到项目根目录的scripts/scan-cn.js位置，在 package.json 里加一个命令：
{ "scripts": { "scan:cn": "node scripts/scan-cn.js src" } }这样团队里任何人都能一键复现扫描结果，不用各自去记正则。后续要调整忽略目录、扩展名或输出路径，改脚本里的配置对象就行。
我后来把输出结果按文件分组，再用一个简单的排序函数统计每个文件的命中行数，可以直接看出哪个模块是中文重灾区，改造时优先安排人力。
5. 从"手动查询"到"自动拦截"：我的一次完整落地复盘
5.1 先定规则：什么中文必须处理，什么中文放行
拿到全量扫描报告后，第一件事不是冲上去改代码，而是把结果分类，定出处理规则。我在一个实际项目里把结果分成三类：必须替换的，包括页面文案、提示语、按钮文字；可以放行的，包括代码注释、测试用例里的中文、README 和文档里的中文；需要单独处理的，包括语言包文件里的中文、第三方扩展里自带的中文。
语言包文件本身就用来维护文案，不需要扫描，直接在脚本里加入白名单目录。这个过程必须在开始之前设计好，否则团队里每个人对"该不该处理"的判断标准都不一样，后期审核成本会非常高昂。
5.2 接入 Git 提交前检查和 CI 拦截
手动扫描只能管一次，管不住增量。我做完这轮存量清理后，把扫描逻辑接进了 Git 提交前的钩子。具体做法是：在一个自定义检查脚本里，先用git diff --name-only HEAD拿到本次改动涉及的文件列表，再对列表里的文件执行中文字符扫描，一旦发现有新增中文就输出错误信息并阻止提交。
如果团队有持续集成流水线，再加一道全局扫描任务，每天定时执行，任务失败时把报告发到群里。这样新增的硬编码中文会在最短时间内暴露，而不需要大家专门记住"提交前要跑一下扫描命令"。
5.3 大仓库性能优化：一次扫描两分钟，怎么压缩到十秒
当仓库文件数量达到数万级别，Node 逐行读文件的性能会变得不可接受。我实测下来，用 fs 逐行读取大文件确实比较慢，有几种优化手段值得尝试。
第一，扫描前先过滤文件列表，最好用 ripgrep 的--files参数获取符合扩展名的文件清单，再遍历。第二，只扫描变更文件而不是全量，日常增量检查只需要扫描本次提交涉及的文件。第三，把脚本拆成"收集文件"和"逐行匹配"两个阶段，前者负责目录遍历，后者可以并发处理，避免一个慢文件拖累整体。
改造之后，一个三千文件的仓库从全量扫描两分钟降到增量扫描一两秒，这个速度才适合放进提交前钩子。
5.4 搜到了却改不动的几个坑
最后分享几个我在实际过程中踩过的坑，每一个都花了不少时间才搞明白。
第一个是模板字符串误报。正则匹配到了反引号里的中文，但其中可能拼接了变量和表达式，直接改成 i18n 调用会破坏运行时逻辑，必须逐个确认上下文。第二个是搜索结果面板数据量过大导致卡死，VSCode 一次只能显示一千条结果，超过之后需要继续翻页，操作起来非常痛苦，所以我后来直接改用命令行输出到文件。第三个是转移义字符\u4f60\u597d这类内容，普通汉字搜索完全搜不到，必须单独写匹配\\u[0-9a-fA-F]{4}的正则，而且这类内容在代码里出现时，视觉上不容易让人意识到它其实是中文字符。
还有一个容易忽视的坑：搜索替换时，VSCode 的正则替换默认按 JS 正则语法处理 Unicode，在某些扩展字符集下表现跟预期不一样。遇到这种问题，我建议不要依赖编辑器直接替换，而是把命中行导出后用脚本统一做词条提取，再批量替换，安全得多。
这套方法走下来，VSCode 里的"查找中文字符"就从一个临时搜索动作变成了完整的治理链路。如果你只是临时想看一眼，记住Ctrl+Shift+F打开正则搜[\u4e00-\u9fa5]就够了；如果你想长期维护代码质量，建议立刻把脚本和 Git 钩子搭起来。我后来在这个项目里，每周只花十分钟看一次扫描报告，新增中文的拦截完全交给自动化处理，再也没出现过"上线后发现文案没翻译"的事故。
