sublime text 的 find in files（ctrl+shift+f）可批量提取关键词并粗略统计出现行数，但需先打开文件夹、合理设置路径与正则（如\bfetch\b），结果中的“x matches”指匹配行数而非真实词频；精确计数应使用单文件 count 按钮，它实时响应正则/范围调整，比 find all 更可靠；结构化提取需用捕获组正则（如fetch\s(\s["'](1*)["']），复制结果后手动清洗；超出手动处理规模时（如多词跨多文件计数、大文件、复杂统计），应转向 grep 或 python 脚本。"' ↩
怎么用 Find in Files 批量提取关键词并粗略计数
Sublime Text 本身不生成词频表，但 Find in Files（Ctrl+Shift+F）是提取和横向对比关键词出现密度最实用的入口。关键前提是：必须先通过 File → Open Folder… 加载项目根目录，否则搜索范围仅限已打开文件标签页，结果严重失真。
操作要点：
- 在
Where栏填具体路径前缀（如src/或**/*.py），避免扫全盘拖慢响应；**仅在正则开启时生效，日常用src/更稳 - 勾选
Regular Expression（.*图标），才能用\bfetch\b精确匹配单词边界，避免fetch匹配到refetch - 每搜一个词，结果页左上角显示类似
3 files, 21 matches—— 这个21是“匹配行数”，不是“词频”，若一行含两个axios，它只算 1 行 - 想逼近真实词频？得切回单文件，用
Ctrl+F+\baxios\b+Count按钮逐个统计，无法批量出多词报表
为什么 Count 按钮比 Find All 更适合精确计数
Count 按钮（查找面板右上角数字加等号图标）直接返回当前视图中匹配总数，而 Find All（Alt+Enter）只在状态栏显示“X matches in Y file”，且依赖状态栏开启（View → Show Status Bar）。更重要的是：Count 实时响应开关变化——改正则、切 Whole Word（W）、调整范围（全文件 / 仅选中），数字立刻刷新；Find All 则需反复触发，还可能因高亮干扰判断。
常见误操作：
- 只选中一段文本就点
Count，结果只统计那段——想查全文，光标放任意位置、别选中文本 - 没关
Match Case（Aa）导致User和user被算作不同词 - 用
.正则统计字符数，漏掉换行符或误算\r，纯属不可靠凑数
如何用正则提取特定结构关键词（比如 API 调用名）
真正需要“提取”而非“计数”时，重点不在频次，而在结构化抓取。例如从 JS 文件中提取所有 fetch、axios.get、useQuery 的调用主体，就得靠带捕获组的正则，配合 Find in Files 输出结果页当临时数据源。
典型正则写法：
- 提取
fetch("https://...")中的 URL：fetch\s*\(\s*["']([^"']*)["']，注意.要转义为\. - 匹配
axios.get或axios.post：axios\.(get|post)\s*\(\s*["']([^"']*)["'] - 捕获
useQuery第一个参数（常为 key 字符串）：useQuery\s*\(\s*["']([^"']*)["']
执行后，在结果页按 Ctrl+A 全选 → Ctrl+C 复制，粘贴到新标签页，再用列编辑（Ctrl+Shift+L）或替换清理冗余内容。别指望 Sublime 直接导出 CSV —— 它没这功能。
什么时候该放弃 Sublime，转向命令行或脚本
Sublime 的关键词处理止步于“人眼可判”的规模。一旦遇到以下情况，硬撑只会浪费时间：
- 要统计 50 个词在 200 个文件里的独立出现次数（非行数），手动切 50 次
Count不现实 - 原始语料含 GB 级日志或 HTML 混排文本，Sublime 渲染卡顿，
Find in Files响应超 10 秒 - 需区分中英文词频、过滤停用词、做 TF-IDF 权重计算——这些超出编辑器能力边界
此时直接导出文本，用 grep -o "fetch" *.ts | wc -l 或 Python 的 collections.Counter 更可靠。Sublime 的价值在于快速探查、小范围清洗、辅助构造正则——把它当瑞士军刀用，别当服务器使。
