10个我曾经极力推崇的开发者工具（我在2026年彻底替换掉的）

Source: Dev.to

（请提供需要翻译的正文内容，我将为您翻译成简体中文，并保持原有的格式、Markdown 语法以及技术术语不变。）

两年前的开发栈？是的，已经有一半过时了。

我并不是在夸张。回顾一下 2024 年初的配置，我真的笑了。曾经在 Twitter 上为之争论的工具现在已经……从我的机器上消失了。卸载了。被遗忘了。

这没关系，正该如此。

我们对工具产生依赖，就像它们是我们身份的一部分。

“我是个 VS Code 人。”
“我用 Postman，来挑战我吧。”

然后出现了更好的东西，你突然记不清当初为什么如此忠诚了。

下面列出 我今年彻底替换的 10 款工具，我换成了什么，以及为什么我不再回头。

Postman → Bruno

我用了多年 Postman。它是默认选择。要测试 API？Postman。每个教程都用它，每个招聘信息也都提到它。

后来 Postman 开始要求登录账号。接着他们加入了 workspaces，再是 teams，再是 collections sync。于是，一个用于发送 HTTP 请求的工具居然需要云账号，还要我为…发送 HTTP 请求付 $12 / month。

Bruno 是开源的，它把你的集合存成普通文件在文件系统里。这就是它的全部卖点。你的 API 集合就和代码放在一起，你可以把它们提交到 Git，根本不需要创建账号。它加载很快，因为它并不想成为协作平台。

我偶尔每月可能会打开一次 Postman，处理客户共享的奇怪遗留工作区。但对我自己的项目？整天用 Bruno。

VS Code → Cursor

这点我很难承认，因为 VS Code 基本上是我的家。我装了 30 多个扩展，熟悉每个快捷键，代码片段也配置得完美。

但 Cursor 改变了这一切。它基于 VS Code（所以所有扩展都能用），但 AI 集成远超我尝试过的任何 VS Code 扩展。标签补全不只是自动补全函数名——它能理解你在构建什么，读取你的其他文件，捕捉你的编码模式。

仅 “apply” 功能就帮我每天省下大约 30 分钟。你描述想要的改动，它展示差异，你点 apply。完成。再也不需要在 15 个文件里手动查找替换。

我仍然保留 VS Code，用于快速配置编辑以及需要一个没有 AI 建议的纯编辑器时。但真正的编码时段？Cursor 成为我的日常编辑器，我看不到它会改变。

Notion → Obsidian

Notion 是我的全能应用。笔记、任务、数据库、维基。我在 Notion 里搭建了完整的系统。甚至还卖 Notion 模板（现在仍在卖）。

后来 Notion 变慢了。明显变慢。打开一个页面要花 2‑3 秒。搜索要等很久。而且他们开始把 AI 功能塞进界面的每个角落。“Notion AI 可以总结此页面！”很酷，但我根本没要求。

Obsidian 把所有内容都存成本地文件夹里的普通 markdown 文件。没有服务器，没有同步问题，没有加载画面。它离线也能工作。如果 Obsidian 明天消失，你仍然拥有所有 .md 文件。试着从 Notion 导出 500 页吧——痛苦不堪。

我仍然在与他人共享数据库时使用 Notion，因为协作功能很稳固。但个人笔记和我的知识库？Obsidian 胜出，而且差距很大。

Slack → Discord

如果你在使用 Slack 合同的公司工作，这可能会有争议，但随它去吧。

Slack 出现在我所有的工作区——工作频道、社区群组，甚至个人项目聊天。后来我触碰到了免费层的消息上限，失去了几个月的聊天记录。那一刻，我决定转变。

Discord 免费提供无限消息历史，语音频道表现出色，支持屏幕共享，而且没有任何付费墙。开发者社区多年前就已经迁移到 Discord，氛围完全不同。Slack 感觉像在上班，Discord 则像和同样写代码的朋友们一起闲聊。

我仍然在使用 Slack whe

Source:

如果公司要求使用它——这几乎是唯一的理由。如果你在构建开发者社区或开源项目，Discord 是显而易见的选择。Discord 的线程系统也变得更好了。

Docker Desktop → OrbStack

如果你在 Mac 上仍在使用 Docker Desktop，我为你的内存感到难过。

Docker Desktop 只是在那儿就会占用 4 GB 的内存。启动容器有时需要 30 秒以上。风扇的声音像喷气发动机一样。再加上 GUI 也很笨拙。

OrbStack 正是 Docker Desktop 本该有的样子。它使用的内存少得多，容器可以在几秒钟内启动，macOS 的集成感觉也很原生。我从不停地查看活动监视器，变成了根本不去在意它。

整个切换大约用了 10 分钟。所有东西都能正常工作——所有的 docker‑compose 文件、所有镜像，都没有问题。说实话，我真的不明白现在还有谁会在 Mac 上继续使用 Docker Desktop。OrbStack 也提供个人使用的免费层。

Heroku → Railway

Heroku 曾是 “只要推送就能部署” 的平台。它在存在期间非常好用。随后他们在 2022 年 11 月关闭了免费层，成千上万的副项目一夜之间暗淡下来。

Railway 接过了 Heroku 的接力棒。每个月你会获得 $5 的免费额度，足以支撑大多数业余项目。部署过程同样简单：连接你的 GitHub 仓库，推送，完成。仪表盘简洁，日志也真正有意义。

我也使用过 Fly.io，它同样出色，尤其适合需要全球分布的场景。但对于 “我只想把这个东西跑起来” 的需求，Railway 是我的首选。开发者体验真的比 Heroku 曾经的水平还要好。数据库的创建只需一次点击，环境变量直接生效。

Heroku 仍然存在，也有公司仍在使用它。但对于个人项目和初创公司，Railway 才是正确的选择。

Create React App → Vite

这件事已经没有争议了。Create React App 正式宣告死亡。React 团队本身也建议停止使用它。

CRA 启动开发服务器需要 30 秒以上。热重载不可靠。构建时间令人痛苦。而且想要自定义 webpack 配置更是困难重重。

Vite 改写了这一切：超快的开发服务器、原生 ES‑module 支持，以及开箱即用的构建速度显著提升。插件生态蓬勃发展，配置文件只有一个且易读。

将项目从 CRA 切换到 Vite 通常只需要几条 npm 安装命令和一次小小的配置修改。仅凭性能提升就值得这么做。

(根据需要继续列表…)

Vite (no‑eject config)

• 快速启动 – Vite 在 毫秒 级别启动，而不是秒。
• 即时 HMR – 热模块替换是即时的。
• 可读性强的配置 – 配置文件易于阅读和编辑。
• 框架无关 – 可与 React、Vue、Svelte 或其他任何框架一起使用。
• 基于 Rollup 的构建 – 生成更小的 bundle。

如果你在 2026 年开始一个新的 React 项目，却仍然选择 Create React App，那就是在主动让自己受苦。使用 Vite。
如果需要 SSR，可以选择 Next.js。但请不要使用 CRA。

Redux → Zustand

我花了太多时间学习 Redux：actions、reducers、action creators、middleware、thunks、sagas……样板代码简直疯狂。要设置一个基本的全局计数器，需要 5 个文件 和 ≈80 行 代码。

Zustand 是一个全局状态库，你可以在大约 10 行 代码内完成设置：

import { create } from "zustand";

const useStore = create((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
}));

• 无需在整个应用外层包裹 provider。
• 无需 dispatch。
• 无需 connect。

如果你需要原子化的状态管理，Jotai 也是极好的选择。

我不会仅仅因为这个就把 Redux 从已有的生产代码库中剔除。
但对于任何新项目来说，除非你的团队已经对 Redux 了如指掌，否则没有任何理由在 Zustand 之上选择 Redux。

Jest → Vitest

如果你已经在使用 Vite（阅读 #7 后你应该这么做），Vitest 是显而易见的测试选择。

• 与 Jest 拥有相同的 API → 迁移几乎是复制粘贴。
• 速度更快 —— 使用 Vite 的转换管道，而不是它自己的。
  • Jest：在大型项目上启动需要 15‑20 秒。
  • Vitest：几乎瞬间启动，watch 模式真正可用。
• 配置更简洁；通常不需要单独的文件，因为 Vitest 会读取 vite.config.ts。
• 开箱即用兼容大多数 Jest 插件和匹配器。

我仍然在未使用 Vite 的项目中使用 Jest，因为仅为测试而迁移构建工具不划算。但 所有新项目都使用 Vitest —— 仅速度差异就值得这样做。

Google Search → Perplexity / Claude

“OK this one is the spiciest take on the list, and it happened gradually.”

我的旧工作流程：

1. 在 Google 上搜索 “how to center a div”、 “React useEffect cleanup”、 “TypeScript generic constraints”。
2. 点击 2019 年的 Stack Overflow 链接。
3. 阅读使用类组件的答案。
4. 向下滚动到评论：“this is deprecated.”
5. 找到另一个答案。重复。

现在我只会询问 Claude 或使用 Perplexity。得到的答案：

• 提供 当前最佳实践，而不是四年前的代码片段。
• 理解我的项目上下文。
• 让我粘贴实际代码并问 “why is this breaking?” —— 我得到真实的答案，而不是一连串的追问。

我仍然会使用 Google 来：

• 非开发相关的内容。
• 查找特定的文档页面。
• 对于像 “哪个托管提供商最适合 X” 之类的人类意见，AI 可能会太过圆滑。

但对于纯粹的编码问题和调试？ AI 搜索胜出一大截。

结束语

你的工具应该为你服务，而不是相反。

• 不要因为“这是我熟悉的”或“这是行业标准”而执着于某个工具。
• 行业标准会变化。2022 年的标准在 2026 年已经尘封。
• 尝试新东西。给它一个真正的机会（至少一周，而不是 20 分钟）。
  • 如果更好，就切换。
  • 如果不行，就回去。
• 开发者工具没有忠诚度计划。坚持使用 Redux 六年也不会给你积分。

这份清单的一半可能在 2028 年就已经过时——这没关系。我会再写一篇。

如果你觉得这有帮助，我会在 Telegram 上分享更多类似内容，并在 Boosty 上出售开发者工具包。