ripgrep FAQ 全解：从配置文件、着色语法、输出排序到 PCRE2 引擎与正则性能调优

ripgrep 仓库自带的 FAQ 是理解这个工具"为什么这样设计、遇到异常怎么排查"的核心文档，它覆盖了配置、man 页、shell 补全、排序、编码、压缩文件、多行匹配、PCRE2 高级正则、颜色配置、Windows 环境陷阱、正则大小限制、搜索替换与许可证等 27 个高频问题。读完本篇，你不仅能原样继承 FAQ 给出的每一条排查命令与配置片段，还能对照 ripgrep 源码（crates/core/flags/defs.rs、crates/core/flags/hiargs.rs、crates/searcher/src/searcher/core.rs）确认这些行为的底层实现与调用链，从而在实际排障时做到"知其然更知其所以然"。

问题总览

官方 FAQ 的完整问题清单（本文各小节与之对应）：

• 配置 / 发布 / 文档类：是否支持配置文件？最近改了什么？何时发布新版本？有没有 man 页？如何获取 shell 自动补全？
• 搜索结果与编码类：如何让结果顺序一致？如何搜索非 UTF-8 文件？如何搜索压缩文件？如何跨多行搜索？
• 正则引擎类：如何使用环视（lookaround）与反向引用（backreferences）？如何绕过正则大小限制？如何让 -f/--file 更快？启用 PCRE2 后为什么变慢？
• 颜色类：如何配置 ripgrep 颜色？如何在 Windows 上启用 true color？被 Ctrl-C 杀掉后终端颜色错乱如何恢复？
• Windows 专项：为什么以 / 开头的模式在 Windows 上失效？如何给 ripgrep 建别名？如何创建 PowerShell profile？如何在 Windows 上管道非 ASCII 内容？
• 使用边界类：ripgrep 能否搜索并替换？采用什么许可证？能否替代 grep？名字里的 "rip" 是什么意思？

配置、发布节奏与文档

是否支持配置文件？

支持。配置文件机制（通过 RIPGREP_CONFIG_PATH 环境变量指向一个包含命令行参数的文件）的完整说明见 使用指南 中的 "Configuration file" 小节，本文后面 Silver Searcher 风格输出一节会给出实际可用的配置示例。

最近改了什么？何时发布新版本？

• 版本变更：请查阅仓库中的 CHANGELOG.md。
• 发布时间：ripgrep 的贡献者都是志愿者，官方明确不会给出任何发布日期，发布采用尽力而为（best effort）的方式。唯一的例外是高影响 bug：如果某个发布存在严重回归，通常会推动尽快出一个补丁版本修复，但官方同样不做承诺。

有没有 man 页？

有。两种获取方式：

1. 如果你通过 Unix 包管理器安装，man 页一般已装好，直接 man rg 即可。
2. 否则可以让 ripgrep 自己生成 man 页：

$ mkdir -p man/man1
$ rg --generate man > man/man1/rg.1
$ MANPATH="$PWD/man" man rg

如果你的 man 支持 -l/--local-file 参数，可以更简单地：

$ rg --generate man | man -l -

man 页的选项文档与 rg --help 的输出等价；想查看更精简的"每行一个 flag"文档，运行 rg -h。man 页也随所有 ripgrep 二进制发布包一起分发。man 页内容的模板就存放在仓库中，例如 man 页模板，由 文档生成模块 在 --generate man 时渲染。

如何获取 shell 自动补全？

支持，且补全脚本由 ripgrep 自己生成。通过包管理器安装时通常会一并装好；否则可用命令行生成：

bash：

$ dir="$XDG_CONFIG_HOME/bash_completion"
$ mkdir -p "$dir"
$ rg --generate complete-bash > "$dir/rg.bash"

fish：

$ dir="$XDG_CONFIG_HOME/fish/completions"
$ mkdir -p "$dir"
$ rg --generate complete-fish > "$dir/rg.fish"

zsh（推荐做法）：

$ dir="$HOME/.zsh-complete"
$ mkdir -p "$dir"
$ rg --generate complete-zsh > "$dir/_rg"

然后在 $HOME/.zshrc 中把 $HOME/.zsh-complete 加入 fpath：

fpath=($HOME/.zsh-complete $fpath)

也可以在加载时动态生成，在 $HOME/.zshrc 中加入：

$ source <(rg --generate complete-zsh)

注意：这种做法更省事，但比上一种方式更慢，会增加 shell 启动时间。

PowerShell：生成补全脚本后，在 PowerShell profile 中"点源"它（注意开头的点）：

$ rg --generate complete-powershell > _rg.ps1

然后在 profile 里写 . _rg.ps1；若 _rg.ps1 不在 PATH 上，则写 . /path/to/_rg.ps1。

从源码结构看，这几类补全脚本分别由 bash.rs、fish.rs、zsh.rs、powershell.rs 生成，--generate 的解析逻辑集中在 crates/core/flags/complete/mod.rs。

搜索行为：顺序、编码、压缩与多行

如何让结果顺序一致？

默认情况下 ripgrep 使用并行搜索（线程间交错的执行顺序本身就是不确定的），因此输出结果的先后顺序在多次运行之间可能不同。要获得稳定顺序，唯一的办法是让 ripgrep 排序输出，而排序会关闭全部并行（在小型仓库上性能差异往往感知不明显）。使用 --sort path 即可按文件路径排序。

这一点在源码中可以得到直接印证：--sort flag 的官方文档字符串明确写着 "Note that sorting results currently always forces ripgrep to abandon parallelism and run in a single thread."，可选排序键为 none（默认，最快、可多线程）、path、modified、accessed、created；降序使用 --sortr。旧的 --sort-files flag 已废弃，文档提示改用 --sort=path。这些定义与测试用例都位于 crates/core/flags/defs.rs（struct Sort 与 test_sort 等）。

另外注意：如果排序键在当前系统不可用（例如 ext4 文件系统没有 creation time），ripgrep 会检测并报错退出。

如何搜索非 UTF-8 文件？

官方答案指向 使用指南 的 "File encoding" 小节：核心手段是 --encoding 相关 flag 与 -a/--text、-t/--text 配合。对于 UTF-16 文件，ripgrep 默认会自动探测编码并按行解码，无需显式转码——这也是 FAQ 在"能否替代 grep"一节中强调的特性之一。

如何搜索压缩文件？

-z/--search-zip 会让 ripgrep 自动搜索压缩文件，当前支持 gzip、bzip2、xz、lzma、lz4、Brotli 与 Zstd。实现方式是 shell out 到对应的外部二进制（gzip、bzip2、xz、lz4、brotli、zstd），因此这些命令必须已在系统中安装。注意 ripgrep 不搜索归档格式，例如 *.tar.gz 会被跳过。

仓库中的 decompress.rs 就是这个"外部进程解压"逻辑的所在模块；测试数据目录 tests/data 下也备有 sherlock.gz、sherlock.bz2、sherlock.xz、sherlock.zst、sherlock.br、sherlock.lz4 等压缩样例文件供回归测试使用。

如何跨多行搜索？

使用 -U/--multiline，让 ripgrep 报告跨多行的匹配结果。

正则引擎：PCRE2、环视与反向引用

如何使用 lookaround 与 backreferences？

ripgrep 默认的正则引擎基于有限状态机（FSM）实现，目的是保证所有输入上最坏情况线性时间复杂度。这一范式下反向引用无法实现，环视也很难高效实现——因此默认引擎都不支持。

替代方案是 PCRE2 引擎：用 -P/--pcre2 启用。例如在 ripgrep 仓库根目录找所有回文：

$ rg -P '(\w{10})\1'
tests/misc.rs
483:    cmd.arg("--max-filesize").arg("44444444444444444444");
globset/src/glob.rs
1206:    matches!(match7, "a*a*a*a*a*a*a*a*a", "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa");

如果当前 ripgrep 构建没有编译 PCRE2 支持，使用 -P 会得到错误：

$ rg -P '(\w{10})\1'
PCRE2 is not available in this build of ripgrep

这条错误消息并非 FAQ 杜撰，而是源码中的分支逻辑：在 crates/core/flags/hiargs.rs 中，构建函数通过 #[cfg(feature = "pcre2")] 决定走 PatternMatcher::PCRE2(...) 还是返回上述 anyhow! 错误，即 PCRE2 是编译期 feature，而非运行时开关。官方发布包默认带 PCRE2；若通过系统包管理器安装且未启用，需要联系该包的维护者。PCRE2 引擎的封装实现在 crates/pcre2。

颜色系统：--color 与 --colors

如何配置 ripgrep 的颜色？

ripgrep 有两个颜色相关 flag，分工明确：

• --color 控制何时用颜色；
• --colors 控制用哪种颜色。

--color 的取值：never、auto（默认）、always、ansi。auto 表示只有输出到终端时才着色，管道到文件或进程时会自动抑制颜色。

--colors 的通用格式：

--colors '{type}:{attribute}:{value}'

• {type}：path、line、column、match 之一，对应 ripgrep 输出中会着色的四类内容；
• {attribute}：fg（前景色）、bg（背景色）、style（样式，如是否加粗）；
• {value}：由 {attribute} 决定。若 attribute 是 style，取值范围为 nobold、bold、nointense、intense、nounderline、underline、noitalic、italic；若是 fg/bg，则取值为颜色。

颜色的三种表示法：

1. 八个英文名：red、blue、green、cyan、magenta、yellow、white、black；
2. 256 色编号：0–255 的整数，十进制（如 62）或十六进制（如 0x3E）；
3. RGB 三元组：三个逗号分隔的数（十进制或十六进制），即 1600 万色"true color"。

特殊用法：--colors '{type}:none' 会清空 {type} 的全部颜色与样式，让你从"干净画布"开始配置（而不是叠在 ripgrep 默认值之上）。

把匹配高亮为蓝底加粗白字的完整示例：

$ rg somepattern \
    --colors 'match:none' \
    --colors 'match:bg:0x33,0x66,0xFF' \
    --colors 'match:fg:white' \
    --colors 'match:style:bold'

颜色是配置文件的高频用途，建议写进 使用指南 所述配置文件中持久化（下文的 Silver Searcher 风格一节有完整示例）。

如何在 Windows 上启用 true color？

• Cygwin 等终端通常开箱即用；
• Windows 10 之前的 cmd/PowerShell 控制台，官方明确说没有已知办法实现 true color；
• Windows 10 控制台理论上开箱即用，但有一个坑：ripgrep 默认会给 match 加上 bold 样式，而 Windows 10 的 VT100 实现不允许 bold 与 true color ANSI 转义同时生效。解决办法是先用 none 清掉默认样式再自定义：

# 不推荐（默认 bold 样式与 true color 冲突）
$ rg somepattern --colors 'match:fg:0x33,0x66,0xFF'

# 正确写法
$ rg somepattern --colors 'match:none' --colors 'match:fg:0x33,0x66,0xFF'

被 kill 后终端颜色错乱怎么恢复？

在 cmd.exe 中键入 color；在 Unix-like 系统中执行 echo -ne "\033[0m" 恢复前景色。PowerShell 中可把下面代码加入 profile，Reset-ForegroundColor 会恢复原始前景色，Set-Alias 那行让你直接用 color 调用：

$OrigFgColor = $Host.UI.RawUI.ForegroundColor
function Reset-ForegroundColor {
    $Host.UI.RawUI.ForegroundColor = $OrigFgColor
}
Set-Alias -Name color -Value Reset-ForegroundColor

背景：ripgrep 曾在历史 PR 中专门处理过该问题（见其 PR #187），后相关行为又被弃用（issue #281），FAQ 给出了完整的 issue 链接供追溯。

Windows 专项：路径转义、别名与管道编码

为什么在 Windows 上用开头的 / 会失败？

在 Windows 的 cygwin 中执行 rg /foo 时，cygwin 可能悄悄对 /foo 做路径翻译，实际搜索的是 rg C:/msys64/foo。三种修法：

1. 不用 cygwin；
2. 用双斜杠转义开头的斜杠：rg //foo；
3. 临时禁用路径转换：MSYS_NO_PATHCONV=1 rg /foo。

如何给 ripgrep 建 Windows 别名？

PowerShell 的函数别名不像 Linux shell 别名那样简单，你必须显式传递参数和 stdin。function grep() { $input | rg.exe --hidden $args } 这种写法是错的。可参考的完整实现：

function grep {
    $count = @($input).Count
    $input.Reset()

    if ($count) {
        $input | rg.exe --hidden $args
    }
    else {
        rg.exe --hidden $args
    }
}

两个 PowerShell 特殊变量：$input 是 stdin 对象，$args 是参数数组。该别名先检查是否有 stdin 输入，有则转发；否则直接裸跑——因为空的 $input 会让 rg 误以为在搜索空 stdin。

如何创建 PowerShell profile？

PowerShell 用一个特殊的启动脚本来做开机定制，在控制台输入 $profile 可定位其路径，具体机制见微软官方文档。该文件中的任何 PowerShell 代码都会在控制台启动时求值，因此别名可以在此自动创建。

如何在 Windows 上向 ripgrep 管道非 ASCII 内容？

PowerShell 向原生可执行文件管道数据时，输入编码由 $OutputEncoding 控制，默认是 US-ASCII，任何 US-ASCII 没有的字符都会被替换成 ?。解决办法是把 $OutputEncoding 设为 .NET 编码对象，例如：

• UTF-8（无 BOM）：$OutputEncoding = [System.Text.UTF8Encoding]::new()
• 控制台输出编码：$OutputEncoding = [System.Console]::OutputEncoding

该变量在 PowerShell 重启后会被重置，想持久化就把该行写进 profile。若仍有编码问题，还可以强制控制台输出编码为 UTF-8：[System.Console]::OutputEncoding = [System.Text.Encoding]::UTF8（同样建议写入 profile）。

性能调优：正则大小限制与 DFA 缓存

如何绕过正则大小限制（regex size limit）？

如果模式特别大（或一次给了很多小模式），编译可能撞上预设上限而失败：

$ rg '\pL{1000}'
Compiled regex exceeds size limit of 10485760 bytes.

（注意：\pL{1000} 看着不大，但 \pL 是包含全部 Unicode 字母的字符类，本身很大，而且重复了 1000 次。）

绕过方法就是提高上限：

$ rg '\pL{1000}' --regex-size-limit 1G

把上限提到 1GB 不意味着 ripgrep 一定会用那么多内存，它只是"允许"正则构造最多占用大约这么多内存。

源码侧印证：--regex-size-limit 的 flag 定义位于 crates/core/flags/defs.rs 中 struct RegexSizeLimit 处，其官方文档说明"编译后的正则一般对应内存中一个能匹配所有给定模式的单一对象"，取值支持 K/M/G 后缀（kilobytes/megabytes/gigabytes），不带后缀按字节处理；test_regex_size_limit 测试确认了 --regex-size-limit 9G 解析为 9 * (1 << 30) 字节、--regex-size-limit=0 可显式清零，而非法数值（溢出）会解析失败。

如何让 -f/--file 更快？

-f/--file 允许指定一个文件，其中每行一个模式，ripgrep 报告匹配任意模式的行。

如果模式文件太大，ripgrep 可能显著变慢。通常原因是内部 DFA 缓存太小，导致 ripgrep 回退到更慢但更稳健的正则引擎。确认是这个原因后，可以用 --dfa-size-limit 提高缓存上限来找回速度。例如 --dfa-size-limit 1G 会把缓存上限设为 1GB（同样不意味着自动占用 1GB，只是允许引擎需要时用到）。

源码侧印证：--dfa-size-limit 的 flag 定义同样在 crates/core/flags/defs.rs（struct DfaSizeLimit），官方文档表述为"The upper size limit of the regex DFA"，并指出默认值对单个模式或许多小模式已经够用，仅在"非常大的正则输入、否则可能触发慢速 fallback 引擎"时才需要调整；K/M/G 后缀规则与 test_dfa_size_limit 测试行为与上节一致。

深度解析：为什么启用 PCRE2 后 ripgrep 反而更慢？

这是 FAQ 中最长、也最有源码价值的一节，值得完整继承。

两个引擎的范式差异

默认引擎是有限自动机（FA）实现，最坏情况线性时间；PCRE2 是回溯实现，因此能支持环视、反向引用等"花活"，代价是失去最坏情况线性保证。但实际测出的"PCRE2 更慢"另有两重原因，都源于 ripgrep 为保证"默认单行匹配"语义所做的工程约束。

原因一：单行匹配约束迫使逐行搜索。 ripgrep 默认只报告跨单行的匹配，而某些模式（如 foo\sbar 能匹配 foo\nbar）理论上可以跨行。逐行读取再逐行匹配最安全但最慢（每行都要找边界、起停搜索）。ripgrep 的优化是对模式做静态约束：静态地阻止模式跨过 \n。例如自动从 \s 字符类中剔除 \n；而当模式含 \n 字面量时直接报错：

$ rg '\n'
the literal '"\n"' is not allowed in a regex

默认正则引擎暴露了做这种模式语法分析的 API，剥离或检测 \n 很容易；PCRE2 没有类似 API，所以开启 -P 后 ripgrep 不做剥离，只能退回到"逐行搜索"的慢路径。

原因二：PCRE2 的 Unicode 支持与"任意数据"互斥。 PCRE2 开启 Unicode 模式时，数据必须是合法 UTF-8，否则是未定义行为；而 ripgrep 默认引擎开 Unicode 时仍能搜索任意数据（对本来就只匹配合法 UTF-8 的模式，它只是不匹配非法字节）。因此启用 PCRE2+Unicode 后，ripgrep 必须先对每个文件做 UTF-8 转码（非法字节替换为 Unicode 替换符），再关闭 PCRE2 自身的 UTF-8 校验——否则一旦喂入非法 UTF-8，PCRE2 会报 match error、中止该文件的剩余搜索，并打印不友好的错误。

用实测数据走一遍

FAQ 用一份字幕样本数据（约 2100 万行量级）和不含任何字面量的模式 ^\w{42}$（文件中恰好一处命中）做了多组对照，无字面量这一点很关键——它排除了字面量优化，让对比聚焦在引擎本身：

$ time rg '^\w{42}$' subtitles2016-sample
21225780:EverymajordevelopmentinthehistoryofAmerica

real    0m1.783s

$ time rg -P '^\w{42}$' subtitles2016-sample
21225780:EverymajordevelopmentinthehistoryofAmerica

real    0m2.458s

用 --trace 可以观察 ripgrep 到底走了哪条路径：默认引擎打印 "fast line searcher"（memory map + slice-by-line 快速路径），而 -P 版打印 "needs transcoding, using generic reader"、"roll buffer strategy"、"slow line searcher"——后者既逐行搜索又在解码文件内容，两处都是性能损耗。

$ rg '^\w{42}$' subtitles2016-sample --trace
TRACE|...: searching via memory map
TRACE|...: slice reader: searching via slice-by-line strategy
TRACE|...: searcher core: will use fast line searcher

$ rg -P '^\w{42}$' subtitles2016-sample --trace
TRACE|...: searching via memory map
TRACE|...: slice reader: needs transcoding, using generic reader
TRACE|...: generic reader: searching via roll buffer strategy
TRACE|...: searcher core: will use slow line searcher

这套 fast/slow 判定的实现就在 crates/searcher/src/searcher/core.rs 中：is_line_by_line_fast() 为真时输出 "will use fast line searcher" 并走 match_by_line_fast，否则走 match_by_line_slow；多行匹配器则直接进入另一分支。

逐项拆解两种损耗：

1. 逐行搜索：只有等 PCRE2 提供更好的模式自省 API 才能根治；
2. UTF-8 解码：可以用 --no-encoding 关闭 ripgrep 侧的自动转码，但那样会启用 PCRE2 自己的 UTF-8 校验——在作者构建里反而更慢（3.07s vs 2.46s）。一个可能原因是 PCRE2 的 UTF-8 校验未必比 ripgrep 所用的 encoding_rs 库（带 SIMD 优化）更快。副作用也很实际：--no-encoding 遇到非法 UTF-8 时 PCRE2 会直接报 "UTF-8 error: illegal byte" 并停止搜索该文件，而默认路径只会把坏字节显示为替换字符。

多行模式、非 Unicode 模式与最终组合拳

直觉上，既然该模式不可能跨行匹配，开 -U（multiline）应该能免掉逐行搜索的惩罚。实测：默认引擎开 -U 后 ripgrep 会检测到"模式不可能跨多行"，自动回落到快速逐行路径，速度不变；但 PCRE2 开 -U 后更慢（2.96s），因为 Unicode 模式下仍要解码，且多行搜索无法增量进行——匹配可能任意长，必须把整个文件一次读入内存，而 UTF-8 解码又排除了 memory map，最终整个文件被读进堆内存。

接着关闭 Unicode：默认引擎用内联模式 (?-u)^\w{42}$，PCRE2 用 --no-pcre2-unicode。默认引擎几乎不变，PCRE2 提升到约 2.0s，仍比默认慢（trace 显示它仍在用慢速逐行搜索器）。

最后组合两个结论——-U 摆脱逐行搜索 + --no-pcre2-unicode 摆脱 UTF-8 解码：

$ time rg -U '(?-u)^\w{42}$' subtitles2016-sample
real    0m1.714s

$ time rg -P -U '^\w{42}$' subtitles2016-sample --no-pcre2-unicode
real    0m1.121s

PCRE2 的 JIT 开始发力：不再逐行搜索、不再做 UTF-8 检查，文件被 memory map 后直接喂给 PCRE2 JIT，速度反超默认引擎。FAQ 还补了一个历史注脚："memory map + 多行 + 非 Unicode" 恰好就是 The Silver Searcher 当年使用的配置组合，这也解释了那套配置为何有效。

结论：如果你不在乎 Unicode 匹配、也不在乎匹配可能跨多行，想让 PCRE2 尽可能快，就用 -U + --no-pcre2-unicode。作者同时留了免责说明：他并非 PCRE2 专家，可能仍有未被发现的 API 或设计可进一步优化。

排障与使用边界

运行 rg 为什么会执行别的命令？

大概率是 shell 别名或另一个也叫 rg 的工具在干扰，先 which rg 确认（例如 Oh My Zsh 的 Rails 插件会把 rg 设为 rails generate 的别名）。解决方案：

• 用 OMZ Rails 插件的话，在 zsh 配置的 plugins 数组里关掉它；
• 临时绕过已有别名：command rg、\rg 或 'rg'；
• 临时绕过别名或其他工具：用完整路径，如 /usr/bin/rg、/usr/local/bin/rg；
• 永久解绑：在 shell 配置文件末尾加 unalias rg；
• 给 ripgrep 一个不冲突的别名：alias ripgrep='command rg'。

ripgrep 能搜索并替换吗？

单靠 ripgrep 不能——它是搜索工具，承诺不修改任何文件。但可以把 ripgrep 的输出管道给会改文件的工具。--files-with-matches 只输出包含匹配的文件名，配合 xargs + sed 即可完成替换：

rg foo --files-with-matches | xargs sed -i 's/foo/bar/g'

GNU sed 下 -i 即原地编辑，s/foo/bar/g 中 g 表示全局替换。macOS/FreeBSD 的 BSD sed 需要给 -i 一个备份后缀参数，传空串即不备份：

rg foo --files-with-matches | xargs sed -i '' 's/foo/bar/g'

若文件路径含空白，用 NUL 分隔更稳：rg foo --files-with-matches -0 | xargs -0 sed -i 's/foo/bar/g'（让 ripgrep 以 NUL 结尾输出路径，xargs 按 NUL 读取）。此外 Facebook 开源的 fastmod 工具与 ripgrep 共用部分底层库，可提供更顺滑的搜索替换体验（见 FAQ 中的官方链接）。

许可证：ripgrep 如何授权？

ripgrep 采用 Unlicense 与 MIT 双许可，你可以任选其一使用（两份文本分别见 UNLICENSE 与 LICENSE-MIT）。双许可的原因有二：一是作者希望借助 Unlicense 表达"放弃版权垄断"的立场；二是 Unlicense 知名度有限，叠加普遍被接受的 MIT 能让更多人放心使用。更严格的约束是：ripgrep 直接和传递依赖永远只使用宽松许可证，任何 GPL、LGPL、MPL、Creative Commons ShareAlike 等 copyleft 依赖（无论强弱 copyleft）都会被拒绝。

ripgrep 能替代 grep 吗？

"取决于你怎么理解这句话"。若理解为"处处同参数、同行为、逐 bug 兼容"，则不能，而且永远不会；若理解为"某些场景可替代、某些场景不行"，则确实如此。

倾向 ripgrep 的场景：

• 经常搜索代码仓库：ripgrep 默认尊重 .gitignore，免去为 grep 手写 --exclude 规则或包装脚本；
• 经常搜索 UTF-8 非 ASCII 文本：Unicode 特性默认开启，且不依赖 locale 设置；
• 需要搜索 UTF-16 文件且不想手动转码：ripgrep 自动处理；
• 搜索大目录/大文件：默认并行，通常快于 grep -r（除非你愿意手写 find ./ -print0 | xargs -P8 -0 grep）。

倾向 grep 的场景：

• 编写需要在各种环境中可移植的 shell 脚本——ripgrep 的普及度远不及 grep；
• 在意 POSIX 兼容性——ripgrep 从来不是、也永远不会是 POSIX 兼容的；
• 讨厌"聪明"的工具——ripgrep 的卖点恰恰就是聪明；
• 依赖某个 ripgrep 没有且永远不会有的 grep 特性——那就用 grep（若只是暂时没有，可以提 issue）。

"rip" 是什么意思？

作者亲历的命名史：最初叫 rep（grep 的短写），觉得不够直白改名 xrep（"给什么都加个 x 总是更好的，对吧？"）；首发前又不喜欢 xrep 的敲打手感，想叫 "rustgrep"/"rgrep" 又觉得太硬。最后保留 r（向 Rust 致意），花两天想以 r 开头的短词，"rip" 浮现出来——意为"快速"，如 "to rip through your text"。而 RIP 恰好也是 "Rest in Peace" 的缩写（暗含 "ripgrep kills grep"），这个巧合作者直到公开发布后才被人指出；如果事前发现，他大概率会改。既然改名在发布后很难，他就将错就错了。顺带澄清：鉴于上文"永远不是 grep 的 drop-in 替代品"的立场，ripgrep 既不是"grep killer"，也从未打算成为——它只是蚕食了 grep 的部分用例，而这类蚕食此前已有 ack、The Silver Searcher 等工具在做。

如何支持 ripgrep？

FAQ 的最后一问是捐赠问题：作者欢迎通过官方赞助渠道支持项目；或者把捐赠给喜欢的公益机构，作者点名了 Internet Archive、Rails Girls 与 Wikipedia。此处仅转述其立场，不提供外部链接。