以前写代码我常年同时开着四十多个 Chrome 标签页。Jira 用来追任务Confluence 用来翻文档Postman 用来测接口Slack 里挂着三个团队的消息Figma 放设计稿DataDog 看监控GitHub 做代码审查。工具一个不少窗口一层套一层电脑却越来越像在替我受刑。最夸张的时候笔记本风扇吼得像飞机起飞内存占用长期贴着 95% 徘徊。每开一个新标签页就得先狠心关掉一个旧的。那种感觉不是在工作更像是在和机器抢最后一点呼吸权。后来我的电脑真撑不住了直接罢工。等新电脑寄来的那几天我只能 SSH 连到一台远程服务器上干活手头能用的东西极其寒酸vim、curl再加一个终端。没有 Electron 应用没有网页后台没有那些花里胡哨的图形界面。就几件最基础的工具。结果偏偏就是那三天我交付出去的东西比前两周加起来还多。也是从那一刻起我突然意识到一个不太舒服的事实很多开发工具并没有真正让我们变得更高效它们只是更擅长消耗资源而已。于是我给自己定了个目标——把那些又重又慢、存在感极强的开发软件换成真正“干活不碍事”的轻量工具。下面这 6 个工具基本替换掉了我原来那套笨重的工作流。我的电脑谢谢它们我的专注力更谢谢它们。1. jq 替代了 Postman顺手还干掉了我一半自写脚本Postman 本质上是在做什么发 HTTP 请求、看响应、格式化 JSON。可问题是为了做这几件事它经常要吃掉几百 MB 内存。就为了发个请求、看个返回值代价未免太高。而 curl 加 jq 呢两者加一起差不多也就几 MB。功能不花哨但真够用。以前我在 Postman 里通常是这么干的发送请求 等界面慢吞吞加载 点来点去找响应内容 复制 JSON 再贴到别的工具里筛字段 然后继续重复现在呢我直接这样写# 获取用户数据只提取邮箱和订阅状态 curl -s https://api.example.com/users/123 \ -H Authorization: Bearer $TOKEN \ | jq {email: .email, subscribed: .subscription.active} # 输出 { email: userexample.com, subscribed: true }如果要同时测试多个接口也完全不必点界面。丢进一个 bash 脚本就行#!/bin/bash # test_api.sh BASE_URLhttps://api.example.com TOKENyour-token-here endpoints( /users/123 /users/123/orders /users/123/preferences ) for endpoint in ${endpoints[]}; do echo Testing $endpoint response$(curl -s -w \n%{http_code} $BASE_URL$endpoint \ -H Authorization: Bearer $TOKEN) http_code$(echo $response | tail -n1) body$(echo $response | sed $d) if [ $http_code -eq 200 ]; then echo ✓ Success echo $body | jq . else echo ✗ Failed with status $http_code fi echo --- done这个脚本我直接放在项目仓库里跟代码一起版本管理。它可以在 CI 里跑也不会像某些桌面应用一样在你切到别的事情时还默默占着几百 MB 内存不撒手。但真正让我离不开 jq 的不只是“替代 Postman”而是它对 JSON 的处理能力实在太顺手了# 从数组中取出所有用户邮箱 curl -s https://api.example.com/users | jq .[].email # 按订阅状态筛选用户 curl -s https://api.example.com/users \ | jq [.[] | select(.subscription.active true)] # 重塑数据结构 curl -s https://api.example.com/orders \ | jq map({id: .order_id, total: .amount, date: .created_at})当然我并没有把 Postman 卸得干干净净。遇到复杂认证流程或者要把请求分享给不懂技术的同事时它还是方便的。然而至少 90% 的接口测试场景里curl jq 都更快、更轻也更容易脚本化。2. fzf 替代了文件搜索工具以前在代码库里找文件我习惯依赖 Sublime Text 的 “Go to Anything”或者 VS Code 的模糊搜索。它们确实做得不错问题只是这些功能都寄生在一个动辄两三百 MB 的编辑器里。后来我发现了 fzf。它是个命令行模糊查找器体积小得惊人差不多只有几 MB却异常能打。# 查找并打开文件 vim $(fzf) # 搜索文件内容并跳到对应行 rg TODO --line-number | fzf | awk -F: {print $2 $1} | xargs vim # 查找目录并进入 cd $(find . -type d | fzf)真正强的地方在于它可以和 shell 快捷键绑在一起直接融进你的日常操作# 写进 .bashrc 或 .zshrc # Ctrl-T模糊查找文件并插入到命令行 export FZF_CTRL_T_OPTS--preview bat --coloralways --line-range :50 {} # Ctrl-R增强历史命令搜索 export FZF_CTRL_R_OPTS--preview echo {} --preview-window down:3:hidden:wrap # Alt-C模糊查找目录并 cd 进去 export FZF_ALT_C_OPTS--preview tree -C {} | head -50这样一来Ctrl-R 不再只是翻 bash 历史而是可以带预览地模糊查找Ctrl-T 也能让我一秒在项目里捞出任意文件。整个过程快、直接而且几乎没额外负担。我通常还会把它和 ripgrep 搭配起来做代码定位# 搜索函数定义并打开 rg ^function.*exportReport --line-number \ | fzf \ | cut -d: -f1-2 \ | xargs -I {} sh -c vim $(echo {} | cut -d: -f2) $(echo {} | cut -d: -f1)看上去有点复杂但我早就给它配好别名了。核心不是命令长不长而是我现在用不到原来那种沉重的 GUI 编辑器也能比 VS Code 更快地搜完整个代码库内存占用却低得多。3. tmux 替代了我所有“花式终端分屏”习惯以前我习惯用 iTerm2开很多 tab再切很多 split。只要一直在本机工作这套方式没有太大问题。可一旦切到远程开发场景尤其是 SSH 到服务器上我那套操作习惯就立刻失灵。后来我学会了 tmux。它最打动我的地方不是“炫”而是它在哪都能用。本地行远程也行换机器可以换 Unix 系统也照样不耽误。你不需要重新适应环境肌肉记忆直接继承。# 给每个项目开一个会话 tmux new -s api-service tmux new -s frontend tmux new -s infrastructure # 分屏 # Ctrl-b % 纵向分屏 # Ctrl-b 横向分屏 # 切换会话 # Ctrl-b s # 分离与重新连接 tmux detach tmux attach -t api-service它最狠的一点是会话会一直活着。我可以 SSH 到远程开发机在一个 pane 里跑 dev server在另一个 pane 里跑测试在第三个 pane 里盯日志。晚上合上电脑回家第二天早上再连回去执行一次tmux attach一切都还停留在昨天离开的地方。开发服务没停日志还在滚vim 还开着。这种“上下文不丢”的体验真的会让人上瘾。我自己的配置文件承担了不少工作# ~/.tmux.conf # 把前缀键改成 Ctrl-a unbind C-b set-option -g prefix C-a # 用 | 和 - 分屏 bind | split-window -h bind - split-window -v # 类 Vim 的 pane 切换 bind h select-pane -L bind j select-pane -D bind k select-pane -U bind l select-pane -R # 开启鼠标支持 set -g mouse on # 不自动重命名窗口 set-option -g allow-rename off # 扩大滚动缓冲区 set-option -g history-limit 10000iTerm2 当然依旧是个不错的本地终端工具。不过tmux 更轻也更通用。更重要的是不管你身处本地还是远程操作逻辑都完全一致不需要来回切脑子。4. entr 替代了文件监视工具Nodemon、Webpack dev server、Parcel还有各种热更新工具很多人一装就是一整套。它们的确方便可代价也很明显为了监控文件变化然后执行一个命令往往要挂着不小的资源开销。entr 这个工具就简单粗暴得多。体积小能力清晰工作方式也毫不拐弯监控文件文件一变就跑命令。完了。# 监听 Python 文件并跑测试 find . -name *.py | entr pytest # 监听 Markdown 并重建文档 ls docs/*.md | entr make docs # 监听源码并重新构建 find src -name *.ts | entr -c npm run build-c参数会在每次运行前清屏-r则适合重启长时间运行的服务# 文件变化时自动重启服务 find . -name *.py | entr -r python app.py我通常会在每个项目里都放一个简单脚本#!/bin/bash # watch.sh case $1 in test) find . -name *.py -not -path ./venv/* | entr pytest ;; lint) find . -name *.py -not -path ./venv/* | entr -c pylint src/ ;; server) find . -name *.py -not -path ./venv/* | entr -r python -m uvicorn main:app ;; *) echo Usage: ./watch.sh [test|lint|server] ;; esac没有配置地狱没有插件生态也没有一层套一层的抽象。只是老老实实盯着文件变了就执行命令。说白了它有点“无聊”可也正因为无聊所以特别稳。5. bat 和 ripgrep 取代了我的文本搜索界面Sublime Text 的全文搜索确实很强这一点没什么可否认的。但问题还是那个问题你得先启动一个不算轻的编辑器还要让它去索引整个项目之后才能愉快搜索。ripgrep 就不一样了。它快得离谱资源占用又低很多时候你甚至感觉不到它存在。# 基础搜索 rg function handleSubmit # 带上下文搜索 rg -C 3 handleSubmit # 只搜特定文件类型 rg TODO -t python rg FIXME -t js -t ts # 只列出匹配文件名 rg -l import React # 忽略大小写 rg -i error再配上 bat 这个更好看的cat体验会再上一个台阶# 带语法高亮查看文件 bat src/main.py # 查看指定行范围 bat -r 50:100 src/main.py # 显示 git diff 信息 bat --diff src/main.py我自己最常用的一组组合拳是这样的# 找出包含某个模式的文件并预览 rg -l handleSubmit | fzf --preview bat --coloralways {}这条命令会先把所有包含 “handleSubmit” 的文件列出来然后你可以继续模糊过滤同时右边直接看到带语法高亮的预览内容。说真的这套体验比我以前用过的大多数 GUI 搜索工具还顺。更快也更省。6. 纯文本文件替代了我所有笔记类应用Notion 我试过Evernote 我试过Obsidian 我也认真用过一阵。它们都不算差甚至各有优点。可共同的问题也很明显偏重、格式体系各有门道、笔记一多就开始拖沓。最后我还是回到了最朴素的办法——纯 Markdown 文件放进一个 Git 仓库。我的目录大概长这样~/notes/ ├── work/ │ ├── 2024-03-01-api-redesign.md │ ├── 2024-03-08-performance-investigation.md │ └── meeting-notes/ ├── learning/ │ ├── postgres-performance.md │ ├── rust-ownership.md │ └── distributed-systems.md └── personal/ ├── ideas.md └── reading-list.md我的工作流也很简单# 新建笔记 note() { local date$(date %Y-%m-%d) local title$1 local file$HOME/notes/work/${date}-${title}.md echo # ${title} $file echo $file echo Date: $(date %Y-%m-%d) $file echo $file vim $file } # 搜索笔记 search_notes() { rg $1 ~/notes/ | fzf --preview bat --coloralways $(echo {} | cut -d: -f1) } # 每日工作日志 log() { local date$(date %Y-%m-%d) local file$HOME/notes/work/daily-${date}.md if [ ! -f $file ]; then echo # Work Log - ${date} $file echo $file fi echo $(date %H:%M) - $* $file }平时我就这么用# 新建一篇笔记 note api-redesign # 追加到工作日志 log Fixed bug in payment processor log Meeting with frontend team about new API # 搜索所有笔记 search_notes postgres performance这种方式带来的好处其实非常实在。文件是纯文本的足够长期、足够稳定所有内容都能被 Git 追踪改了什么一目了然离线也能用不会被同步故障绑架搜索几乎是秒出结果不存在厂商锁定因为它本来就只是 Markdown更关键的是只有打开时才占资源平时基本没负担。我现在就在不同机器之间用 Git 同步这整个目录。要分享内容的时候也根本不需要什么“导出”按钮直接复制 Markdown 就好了。它天生就是可迁移的。最后这些工具虽然用途不同却有一个很鲜明的共性它们只把一件事做好然后迅速退到后台不打扰你。它们不想把自己做成平台不急着构建生态也不热衷于把你的一切工作都收编进去。它们只是老老实实解决某个具体问题而且解决得足够高效。你有没有把某个笨重工具换成更轻方案之后就再也回不去的经历最后精通 React 面试从零到中高级CSS终极指南Vue 设计模式实战指南20个前端开发者必备的响应式布局深入React:从基础到最佳实践完整攻略python 技巧精讲React Hook 深入浅出CSS技巧与案例详解vue2与vue3技巧合集全栈AI·探索涵盖动效、React Hooks、Vue 技巧、LLM 应用、Python 脚本等专栏案例驱动实战学习点击二维码了解更多详情。