ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

终端效率工具教程:fzf、rg、bat、jq、tmux组合实战

终端效率工具教程:fzf、rg、bat、jq、tmux组合实战 最近网上刷到“偶遇好朋狗一只”这个梗时我第一反应想到的不是路边的小狗而是终端里那些“好朋友”型的开发工具。它们平时不声不响一旦用熟就能用一串命令把日常开发里的重复操作全部串起来快速找文件、搜日志、跳目录、解析 JSON、查命令手册、保持远程会话。这篇就把我实际工作中真正高频使用的一套终端效率工具整理成完整教程包含安装、配置、常用参数、组合实战和常见问题排查新手可以照着装有基础的开发者也能从中挖到几个平时容易忽略的用法。1. 背景与核心理念1.1 什么是终端效率工具终端效率工具指的是那些安装在命令行环境里用来提升查找、浏览、跳转、编辑效率的辅助程序。它们不像 Git、Nginx、数据库那样是一个完整的软件系统而是更像“命令行的插件”或“瑞士军刀”单个看功能都很小组合起来却能极大减少无意义的重复操作。举个例子没有工具时我想在项目里找一个包含某个关键词的文件会用grep -r 关键词去扫文件很多时输出会刷屏还得自己翻。有了 ripgrep 配合 fzf 之后我可以一边输入关键词一边看到一个实时筛选的文件列表按一下回车就能打开对应文件。这种体验上的提升不是“少敲几条命令”能概括的而是整条操作链路变得流畅了。1.2 为什么是“组合”而不是单个工具很多人会把每个工具单独使用比如只在需要时运行jq解析一次 JSON然后就不管了。这当然没问题但效率工具真正的威力来自管道和 Shell 函数。以日志排查为例rg负责找到包含error的文件fzf负责把一堆结果变成可交互选择列表bat负责高亮显示文件内容jq负责把结构化日志提取成可读性更强的文本zoxide负责帮你瞬间跳回那个项目目录tmux负责让这些操作在一个长期存活的分页终端里迭代。每一个工具解决一个点串成一条线之后你会发现排查问题的节奏快了很多。这篇教程会先讲清楚七个工具各自的定位和核心用法再用一个完整的本地日志排查案例把它们组合起来跑一遍。2. 环境准备与版本说明2.1 系统与工具链说明本文示例以 Linux 环境为主同时给出 macOS 的安装命令。Windows 用户建议先在 WSL 2 里操作很多工具在原生 Windows 命令行下的体验差异较大。版本方面不写死具体数字因为这几个工具迭代都比较快不同系统源里的版本也不一样。你只要保证系统能正常使用apt或brew再根据提示处理依赖即可。重点是掌握每个工具的用法和组合思路而不是纠结某一个小版本。进入正文前可以先确认一下基础环境# 查看系统版本Linux cat /etc/os-release # 查看当前 Shell echo $SHELL # 查看代码包管理器版本macOS 使用 brew node --version npm --version如果后面安装 tldr 需要 Node.js可以参考上面的node --version输出确认环境。2.2 快速安装清单下面这套组合是目前终端效率工具里口碑比较稳定的七个工具工具作用一句话定位fzf交互式模糊查找文件、历史命令、目录的“搜索引擎”ripgrep全文搜索比 grep 更快、更懂代码库zoxide目录智能跳转让cd记住你的习惯bat文件查看带语法高亮的catjqJSON 解析命令行版 JSON 处理器tldr命令速查简化版man手册tmux终端管理器会话保持 分屏LinuxDebian/Ubuntu 系可以一次性安装大部分sudo apt update sudo apt install -y fzf ripgrep bat jq tmuxmacOSbrew install fzf ripgrep zoxide bat jq tmux注意 Linux 下包名写的是bat但在某些 Debian/Ubuntu 发行版里由于和历史包冲突装完后的可执行文件叫batcat。这个问题很常见后面的常见问题部分会专门说明。zoxide 在 apt 源里也有但版本可能不够新而且不同系统差异较大。更通用的做法是通过包管理器安装# macOS brew install zoxide # Linux 如果有 Cargo cargo install zoxidetldr 一般通过 npm 安装sudo npm install -g tldr如果你不想用 npm也可以直接装 Rust 版的tlrc命名与用法略有区别本文以 npm 版为准。2.3 初始化 Shell 配置安装完不是终点有几个工具需要把初始化代码写进 Shell 配置文件才会生效。fzf 建议用官方安装脚本方式安装这样它会自动配置键位绑定git clone --depth 1 https://github.com/junegunn/fzf.git ~/.fzf ~/.fzf/install安装过程中会询问你是否要更新~/.bashrc或~/.zshrc一般选 yes 即可。如果用的是 apt 安装则可能需要手动添加# 在 ~/.bashrc 中追加 source /usr/share/doc/fzf/examples/key-bindings.bash source /usr/share/doc/fzf/examples/completion.bash不过这个路径在不同发行版里不一样更推荐用官方 git 安装方式完成后自动配置少踩路径坑。zoxide 需要初始化对应的 Shell# bash eval $(zoxide init bash)把上面这行追加到~/.bashrc末尾。如果使用 zsheval $(zoxide init zsh)这里要解释一下为什么要eval。zoxide init bash不是简单输出一段静态文本它会在当前 Shell 环境里定义z函数同时注册 Shell 的钩子事件用来在每次cd时记录目录。如果不执行evalz命令就不存在。3. 核心工具逐个拆解3.1 fzf文件与历史命令的模糊搜索引擎fzf 又叫“fuzzy finder”核心能力是在输入关键词时做“模糊匹配”。你不需要输入完整文件名只要记住其中几个连续的片段就能搜出来。例如文件叫user_profile_controller.py输入upc或prof都能匹配到很适合记不清全名的情况。安装并初始化后最常用的三个键位CtrlT将当前目录下的文件列表交给 fzf 交互选择选中后会把文件路径插入命令行。CtrlR搜索历史命令比默认的history翻页体验好太多。AltC目录跳转选择选中后直接cd进去。除了键位绑定fzf 更重要的用法是管道。任何多行文本都可以用printf之类的方式喂给 fzf然后把选中的结果交给下一个命令处理# 选择项目文件并用 vim 打开 vim $(fzf)这一行看起来简单但背后做了大量工作它会启动交互界面、监听输入、执行匹配、最后把选中的文件名作为参数返回。如果没选任何文件它不会执行vim不会误操作。fzf 还支持预览窗口fzf --preview bat --coloralways {}这里的{}会被替换成当前光标所在的那一行文本也就是文件名。于是你在上下移动光标时侧边会实时显示该文件的内容高亮预览。--coloralways是强制 bat 输出 ANSI 颜色否则在管道环境下 bat 会自动降级为无颜色输出。3.2 ripgrep比 grep 更懂代码库的全文搜索ripgrep 的常用命令是rg。它和 grep 最大的区别是默认就会读取.gitignore规则自动跳过.git目录、二进制文件、隐藏文件除非显式指定。也就是说你不需要像 grep 那样先手动排除一堆目录在代码仓库里搜关键词的体验非常干净。常用参数# 带行号搜索 rg -n error src/ # 忽略大小写 rg -ni error src/ # 只搜指定类型的文件 rg -n error --type py src/ # 根据 glob 过滤文件 rg -n error --glob *.json logs/ # 只输出文件名不输出匹配内容 rg -l error logs/-n是行号-i是忽略大小写--type py可以理解为“只查 Python 文件”-l在多文件场景很适合配合 fzf 使用。举个例子rg -l error logs | fzf --preview rg -n error {}这条组合的语义是先让 rg 找出所有包含error的文件名再让 fzf 在结果里交互选择选中后预览该文件里所有匹配error的行。这样既能看到“哪个文件有问题”又能立刻看到“问题出现在哪一行”。3.3 zoxide让 cd 记住你的习惯如果你整天在不同项目之间切换cd输入的路径通常是最浪费时间的操作。zoxide 的思路是记录你访问过的目录并给目录打分然后通过关键字跳到最可能的目标。安装后初始化eval $(zoxide init bash)然后正常使用cd跳目录即可zoxide 会在后台记录。下次只需要z project它就会跳到“历史上最符合条件的那个 project 目录”即使完整路径是/home/user/work/backend-projects/project-a也能匹配。对于经常目录嵌套很深的项目这是非常舒服的数字体验。zoxide 也支持手动添加目录z --add /home/user/scripts删除历史记录可以用z --remove /home/user/scripts实际项目中我经常配合z一键跳到日志目录再结合 rg 和 fzf 进入排查流程整条链路没有一次手动输入完整路径。3.4 bat带语法高亮的 catcat是查看文件最常用的命令但它没有任何语法高亮看代码时很难快速区分注释、字符串和关键结构。bat 相当于“增强版 cat”它会根据文件扩展名自动做语法高亮还支持行号显示。基本用法bat app.log bat main.py --line-range 10:20--line-range 10:20表示只显示 10 到 20 行适合大文件局部查看。bat 最需要注意的是管道场景。直接运行bat file时它会自动检测是否连接到终端如果连接到管道默认会关闭颜色和分页。所以在 fzf 预览或脚本里需要显式加强制颜色bat --coloralways --line-range :100 app.log在 Debian/Ubuntu 环境下二进制名可能是batcat如果你在脚本里统一依赖bat命令建议在 Shell 配置里加一个别名alias batbatcat这样后续命令就不用区分发行版了。3.5 jq命令行版 JSON 处理器JSON 是后端日志、接口返回、配置文件里最常见的格式之一。直接看一大段 JSON 确实能看但要做字段提取、过滤、格式化jq 是最通用轻量的工具。基本用法# 格式化输出 echo {name:dev,level:error} | jq . # 提取字段 echo {name:dev,level:error} | jq .name # 输出数组里的所有元素 echo [{id:1},{id:2}] | jq .[] # 过滤符合条件的对象 echo [{level:info},{level:error}] | jq .[] | select(.level error).代表整个输入对象.name是取字段.[]是遍历数组元素select(.level error)是过滤。这几个语法覆盖了日常 80% 的场景。-r参数很常用它表示“原始输出”也就是去掉字符串两边的双引号。当你希望把提取结果直接拼接成一行文本时一定要加-recho {level:error,msg:db timeout} | jq -r \(.level): \(.msg)输出为error: db timeout这种写法在日志统计和告警脚本里非常实用可以直接把 JSON 里的多个字段拼成可读文本。3.6 tldr简明版命令手册man手册很完整但对新手来说信息量过大更像读完就忘的说明书。tldr 是社区维护的速查手册它把每条命令最常用的几个场景和对应参数列出来几行就能看完。安装好之后直接使用例如tldr tar tldr curl tldr docker以tar为例你会看到类似下面的精简示例- 创建 tar 压缩包 tar cf target.tar file1 file2 - 解压 tar xf source.tar - 列出内容 tar tf source.tar它不是替代man而是给“我只是想查个参数”的场景提供入口。遇到不熟悉的命令先tldr看常用示例再man查细节学习效率会高很多。3.7 tmux会话保持与终端分屏tmux 是一个终端复用器。它能让你在远程服务器或本地终端里维护多个会话并且保证断线之后会话不会消失。对部署、排查生产问题、长时间跑脚本的场景来说非常实用。最核心的操作# 新建会话 tmux new -s demo # 从会话中分离类似挂起到后台 # 先按 CtrlB松开后再按 d # 查看所有会话 tmux ls # 重新接入某个会话 tmux attach -t demo分屏也是常用能力CtrlB %左右分屏CtrlB 上下分屏CtrlB 方向键切换光标所在窗格tmux 和 fzf 还有一个联动fzf 支持在 tmux 内启动一个独立小窗口命令是fzf-tmux在 tmux 会话里使用 fzf-tmux选择结果不会占用整个终端界面而是一个临时的底部小窗格体验更顺滑。4. 完整实战本地日志排查工作流前面的工具单独看都不难但组合起来才是效率的体现。下面通过一个完整的本地日志排查场景把七个工具全部串起来。4.1 创建演示项目结构先模拟一个后端服务目录包含若干日志文件mkdir -p ~/demo-project/logs cd ~/demo-project创建一份 JSON 格式的日志文件cat logs/app.json EOF {level:info,timestamp:2025-01-01 10:00:00,service:order,message:service started} {level:error,timestamp:2025-01-01 10:00:03,service:order,message:database connection timeout} {level:error,timestamp:2025-01-01 10:00:05,service:pay,message:redis retry failed} {level:info,timestamp:2025-01-01 10:00:08,service:pay,message:service recovered} EOF再创建一份普通文本日志cat logs/app.log EOF 2025-01-01 10:00:00 order INFO service started 2025-01-01 10:00:03 order ERROR database connection timeout 2025-01-01 10:00:05 pay ERROR redis retry failed 2025-01-01 10:00:08 pay INFO service recovered EOF此时项目结构是~/demo-project └── logs ├── app.json └── app.log4.2 用 rg 定位关键词我想找出所有出现error的文件和行号cd ~/demo-project rg -n -i error logs预期输出会同时包含app.log和app.json且带行号logs/app.json:2:{level:error,timestamp:2025-01-01 10:00:03,... logs/app.json:3:{level:error,timestamp:2025-01-01 10:00:05,... logs/app.log:2:2025-01-01 10:00:03 order ERROR database connection timeout logs/app.log:3:2025-01-01 10:00:05 pay ERROR redis retry failed如果只想看日志来源文件用-lrg -l -i error logs输出logs/app.json logs/app.log4.3 用 fzf 交互选择文件当文件很多时我不希望在一个终端页面里手动翻找。可以这样rg -l -i error logs | fzffzf 会把上面两个文件展示成一个可搜索的列表输入json可以过滤到只剩logs/app.json回车后文件名被输出到终端。更进阶的版本是加上预览让选择前就能看到文件内容rg -l -i error logs | fzf --preview bat --coloralways {}此时上下移动光标预览窗口里会实时显示对应文件的完整内容。由于是 JSON 文件和普通日志文件bat 会自动判断语法类型。4.4 用 bat 查看具体文件挑选出logs/app.json后直接查看bat logs/app.json如果发行版使用batcat记得先配置别名alias batbatcat默认输出带行号和高亮。如果只想看前几行bat --line-range 1:3 logs/app.json4.5 用 jq 解析结构化日志这一步才是真正体现 JSON 日志价值的地方。我不用再去肉眼匹配而是让 jq 直接过滤level error的记录jq -r select(.level error) | [\(.timestamp)] \(.service): \(.message) logs/app.json预期输出[2025-01-01 10:00:03] order: database connection timeout [2025-01-01 10:00:05] pay: redis retry failed再进一步统计每个服务的错误次数jq -r select(.level error) | .service logs/app.json | sort | uniq -c这条命令相当于先提取出错的服务名排序再用uniq -c统计数量。对于真实的多服务日志这样的统计能在几秒内完成。4.6 zoxide 快速跳转与 tmux 保持现场排查到一半我需要切到另一个目录查看配置但接下来还要回来继续处理日志。这时候 zoxide 和 tmux 的价值就体现了。先记录当前目录cd ~/demo-project以后随便在哪个目录想回来时只要z demo-project如果手头有多个项目前缀相似z会自动匹配分数最高的那个目录。如果想保持当前排查现场可以开启一个新的 tmux 会话tmux new -s demo然后在里面反复执行 rg、fzf、jq 组合。需要临时查看配置时CtrlB后按c新建一个窗口切到配置目录查看再CtrlB按数字键切回日志窗口。这样即使用CtrlB d分离会话远程连接断了所有窗口里的命令和输出都还在。4.7 组合成一个 Shell 函数把上面这些操作封装成一个函数放到~/.bashrc里以后排查日志就能一键进入交互流程function fbat() { local file file$(fzf --preview bat --coloralways {}) if [[ -n $file ]]; then bat $file fi }保存后重新加载配置source ~/.bashrc然后进入项目目录直接执行fbat体验就是先输入关键词筛选文件实时预览内容回车后看到完整高亮文件。整个过程没有一次手动输入完整路径或文件名。还可以做一个直接搜日志关键词的函数function rgf() { rg -l -i $1 . | fzf --preview rg -n $1 {} }用法rgf error它会先搜当前目录下所有包含error的文件然后在 fzf 列表里选择预览时只显示该文件里匹配error的行正好对应日志排查场景。5. 常见问题与排查思路这些工具安装简单但配置过程中仍有一些高频踩坑点。下面按“问题现象、常见原因、解决思路”整理了一份表格问题现象常见原因解决思路fzf 的 CtrlT / CtrlR 没反应shell 配置未 source或使用的是旧版 key bindings用官方 git 方式安装并执行~/.fzf/install确认~/.bashrc里有对应 sourceDebian/Ubuntu 执行bat提示 command not found安装包内部二进制名是batcat与历史包冲突使用batcat或添加alias batbatcatrg 搜索不到某些文件rg 默认读取.gitignore且跳过隐藏文件文件被忽略了使用rg -u包含隐藏文件或--no-ignore忽略 ignore 规则jq 报 parse error输入不是合法 JSON可能是多行 JSON 或日志前缀混入文本先用jq .测试确认原始输出解析日志时可以用tail -f配合逐行过滤zoxide 的z命令不存在没有执行eval $(zoxide init bash)或当前 shell 是 zsh 但只初始化了 bash检查配置文件确保 init 命令与当前 shell 对应tldr 安装后仍然 command not foundnpm 全局目录不在 PATH 中执行npm config get prefix并确认对应 bin 目录已加入 PATHtmux attach 后窗口内容丢失误重新创建了同名的会话先用tmux ls查看已有会话再 attach不要直接new5.1 排查思路说明遇到命令行工具不生效先别急着重新安装。通用的排查顺序是输入which 工具名或type 工具名确认工具是否真的被安装检查当前 Shell 是 bash 还是 zsh很多初始化命令是 shell 相关的确认配置是否写入正确的文件bash 用~/.bashrczsh 用~/.zshrc改动配置后必须source ~/.bashrc或重新打开终端否则不会生效如果是管道内命令输出异常先单独执行每一段确认哪一步出的问题。比如rg -l error logs | fzf没有结果先跑rg -l error logs看有没有输出再看 fzf 的预览命令里是否依赖了bat而系统里只有batcat此时就会因为找不到命令导致预览窗口空白。6. 最佳实践与工程建议6.1 配置持久化与别名效率工具的配置都建议放在自己的 dotfiles 仓库里这样换新机器时能快速恢复。除了每个工具的初始化命令还可以整理一批别名alias batbatcat # Debian/Ubuntu 环境下统一 bat alias searchrg -n # 快速搜索 alias ffzf # 简化 fzf alias devz ~/work # 一键跳到开发目录这里要注意别把别名和函数混成一个概念。别名适合固定前缀函数适合带逻辑的组合命令比如前面写的fbat和rgf。如果你的 Shell 脚本需要发布给别人使用尽量把复杂逻辑写成函数而不是一串复杂的别名。6.2 与编辑器和 IDE 配合fzf、rg 这些工具不只属于终端也可以反哺到日常编辑器里。Vim/Neovim 有大量 fzf 集成插件比如在命令面板里搜索文件、搜索 buffer、搜索历史命令。VS Code 的插件生态里也有 rg 作为后端搜索的实现替代内置的全局搜索。如果你固定使用某款 IDE不妨先试着在终端里熟练掌握这几个工具再把同样思路迁移到 IDE 的快捷键和工作区搜索里这样终端和编辑器之间的切换成本会低很多。6.3 脚本和 CI 环境中的注意事项fzf 是交互式工具不要在自动化脚本里直接裸用否则脚本会在等待输入时卡住。如果需要“选择”逻辑可以设置FZF_DEFAULT_OPTS或直接用rg、jq完成确定性筛选。例如在 CI 里要提取某个 JSON 字段直接用 jq 完成jq -r .version package.json不要为了“看起来自动化”而把 fzf 塞进 CI 流程。另外zoxide 的目录记忆是依赖 Shell 钩子的在 Docker 容器或 CI 环境里建议不要依赖z跳转直接用绝对路径避免评分数据不完整导致跳错目录。6.4 性能与安全这几个工具底层大多是 Rust 实现单次执行性能都很强真正需要注意的反而是组合使用时的大目录问题。在巨大的项目目录里执行rg --files | fzf时第一次搜索会扫描全目录建议先用--glob *.log或--type json收紧范围减少不必要的 IO。安全方面也要留意不要拿着sudo去安装自己并不完全了解的脚本包。安装 fzf、zoxide 这类工具时优先使用系统包管理器或官方仓库而不是随意执行网上复制来的curl | sh安装命令。可以先用curl -sSL 地址 -o 文件名下载下来人工查看再决定是否执行。6.5 学习路线建议如果以前完全没用过这些工具不建议一次装七个然后全部学习会有点消化不良。建议按下面顺序逐步引入先装rg、bat、jq把“搜索、查看、解析”的基本功打牢再上fzfzoxide优化文件选择和目录跳转最后加入tmux管理远程会话再回头把 fzf 的预览、tldr 的速查集成到日常习惯里。每引入一个工具就刻意用一周左右直到不假思索能敲出最常用的命令再引入下一个。效率工具的核心不是“装了多少”而是“实际用熟了几个”。7. 写在最后这套终端效率工具组合是我日常开发里最像“好朋狗”的一批软件不占界面、不用伺候、不会像 IDE 那样偶尔卡顿只要把初始化配置写好它们就安静地待在 Shell 里被你用管道串起来解决一个又一个实际问题。如果你还没试过建议今天就装一个最感兴趣的喜欢搜索就试 ripgrep喜欢交互选择就试 fzf喜欢快速跳目录就试 zoxide。用熟之后再回到本文学其他工具你会比一次性装完更容易建立肌肉记忆。遇到配置问题也不要慌先按文中的排查步骤确认 PATH、Shell 类型和配置文件大多数问题都是“没 source”或“命令名不一致”导致的。欢迎在评论区分享你常用的终端组合看看谁的“好朋狗”最顺手。
返回列表