返回博客

技术选型的本质是成本管理

没有"最好的技术",只有"成本最低的技术"。

技术圈里有一种辩论,我称之为"宗教战争"——React vs Vue、TypeScript vs JavaScript、PostgreSQL vs MySQL、Rust vs Go。每一场辩论都有忠实的信徒,每一个信徒都坚信自己的选择是"正确的"。

但如果你仔细观察这些辩论,你会发现一个共同点:所有人都在讨论"技术特性",但几乎没有人讨论"成本"。

而我认为,技术选型的本质,不是"哪个技术更好",而是"哪个技术的总成本更低"。

四种成本,不是一种

当我们说"成本"的时候,大多数人想到的是金钱成本——服务器要多少钱,数据库要多少钱,CDN 要多少钱。但真正的技术选型成本,远不止这些。

开发成本:你花了多少时间把它做出来?

我最早用 Vue 写工具站的时候,一个简单的工具需要:创建组件、配置路由、管理状态、写模板、处理生命周期……一个功能,写 50 行代码,其中 30 行是"框架要求"的代码。后来改用纯 JavaScript,同样的功能 20 行搞定。

框架的优势是"在大型项目里提高开发效率",但它的代价是在小型项目里增加开发成本。你需要配置构建工具、管理依赖、处理版本兼容、理解框架约定。这些成本,在项目小的时候,可能比"不用框架直接写"的成本还要高。

开发成本不是"框架 vs 无框架",而是"框架的成本 vs 不用框架的成本"——你需要比较的是两者的差距,而不是其中一方的绝对值。

维护成本:未来修改它要花多少时间?

这是最容易被忽略的成本。大多数人在选型时只考虑"现在怎么快",不考虑"以后怎么改"。

我见过一个例子:一个团队用了一个很新的前端框架,开发效率确实很高,三个月就上线了。但一年后,这个框架发布了三个大版本,每个版本都有 breaking changes。团队花在"升级框架"上的时间,比"开发新功能"的时间还多。最终,他们决定重写整个项目——这次,选了一个更稳定的技术栈。

维护成本包括:依赖升级、安全补丁、文档更新、人员交接。这些东西不会出现在"选型对比表"里,但它们会在项目生命周期的后半段,成为你最大的消耗。

一个技术的维护成本,和它的"稳定度"成反比——越新、越热、变化越快的技术,维护成本越高。

学习成本:你和你的团队要花多久掌握它?

我选择在工具站上使用纯 HTML + CSS + JavaScript,一个重要原因是学习成本为零——我已经懂了。我不用学 Tailwind 的配置方式,不用学 React 的 Hook 规则,不用学 Next.js 的渲染模式。而这些"不用学"的内容,加起来至少需要几周的全职学习时间。

如果你是一个人在做项目,学习成本就是你的时间。如果你是一个团队,学习成本就是所有人的时间,再加上"学习曲线带来的生产力低谷"。

很多人被"新技术"的诱惑所吸引——"这个新框架看起来好厉害,我们来用它吧"。但"厉害"不等于"低成本"。你需要问自己:学习这个新技术,值得吗?它带来的收益,能覆盖学习成本吗?

机会成本:选了 A,你就不能选 B

这是最抽象但最真实的成本。你花时间学一个新技术,这些时间就不能用来做别的事。你花精力维护一个复杂的架构,这些精力就不能用来做新功能。

我选择纯静态网站,本质上是在说:我不想把时间花在"维护框架"上,我想把时间花在"写内容"和"做工具"上。这个选择的机会成本计算是:如果我用了 Next.js,我每个月要花 10 小时在维护和升级上。这 10 小时,如果用来写文章,我可以写 2-3 篇。如果用来做工具,我可以做 1-2 个新工具。那么,Next.js 带来的"技术优势",值不值得我每个月放弃 2 篇文章或 1 个新工具?

对我来说,答案显然是不值得。对你来说,答案可能不同。但关键是:你要意识到这个成本的存在,并主动比较它。

我的选型决策框架

基于以上四种成本,我总结了一个简单的决策框架,每一次技术选型都问自己四个问题:

这四个问题没有标准答案,因为它们取决于你的场景。但只要你问了这四个问题,你的选型就已经比 90% 的人更理性了。

为什么"用过时的技术"有时是最优解

理解了"成本"视角之后,你会发现一个反直觉的结论:在很多场景下,"过时的技术"反而是最优解。

为什么?因为"过时"意味着:稳定(没有 breaking changes)、文档完善(社区已经踩过所有坑)、学习成本低(你已经会了)、维护成本低(几乎不需要维护)。

我写这篇文章用的就是纯 HTML。没有框架,没有构建工具,没有依赖。有人觉得这是"技术保守",但我觉得这是"成本意识"。我不需要"最先进的技术",我需要"最让我省心的技术"。而"过时"的技术,恰好满足这个条件。

新技术的价值,在于它解决了旧技术的"真问题"。如果你没有遇到那个"真问题",新技术对你来说就是"纯成本"。

写在最后

下次你参加技术选型讨论的时候,试着把话题从"哪个技术更好"转向"哪个技术的成本更低"。你会发现,讨论的质量会立刻提升一个层次——因为"更好"是主观的,而"成本"是可以计算的。

技术选型不是信仰,是计算。而计算的公式,就是你自己的场景、你团队的能力、你项目的生命周期。当你不确定怎么选的时候,记住一句话:没有最好的技术,只有最适合你的成本结构的技术。