一个人做产品，技术栈怎么选

关于技术选型，网上能搜到最多的是各种“对比表”：框架 A 对比框架 B，语言 X 对比语言 Y，最后给一个谁赢谁输的结论。

这类对比有一个共同前提 —— 它默认你有团队、有运维、有人能接手。 当你只有自己一个人的时候，这个前提不成立，那些结论往往也就不成立了。

这篇不讲哪个框架更好，只讲一件事：只有一个人维护时，用什么标准来选。

为什么“技术先进”排不到第一位

先说一个反直觉的判断：一个人做产品，选型的第一标准不是性能，也不是先进程度，而是“出了问题我能不能一个人定位”。

先进的技术通常意味着几件事同时成立：用的人少、踩过的坑少、现成的解决方案少、出问题时能搜到的答案少。这些成本在团队里会被分摊 —— 有人查文档、有人翻源码、有人去社区提问。一个人扛的时候，这些成本全都压在你身上，而且压在你最没空的时候，也就是出故障的时候。

我见过太多这种情况：为了“以后好扩展”选了一套自己并不熟的组合，第一版确实跑起来了。但等到某天线上出问题，光是把问题定位到哪一层就花掉一个下午，最后发现是自己的用法不对，跟框架本身没关系。

所以我把判断顺序调了一下：先看“我熟不熟、扛不扛得住”，再看好不好，最后才看先不先进。

四个真正影响成本的维度

“扛不扛得住”听起来很虚，拆开看其实是四件具体的事。

第一条：出问题时，你能否独立定位

想象一个具体的故障：接口返回 500，日志里只有一句框架内部的报错。

• 熟悉这套技术栈时，你知道该去哪个中间件、哪个配置项、哪个版本变更里翻 —— 这是可控的
• 只是“会用”的时候，报错来自一个你不了解的抽象层，你只能靠搜 —— 而搜到答案的概率，和这个技术的流行程度直接挂钩

一个简单的自测：问自己“如果这个框架内部出问题，我打算怎么查”。 答不上来，说明你对它的掌握还停留在“会调用”，撑不住生产。

第二条：可替代性 —— 你不做的时候谁接手

一个人做产品，迟早会遇到“要交给别人”的时刻：外包一部分、招一个人、或者自己换方向。

这时候，你的技术栈是不是主流就变成了成本。主流技术对应更多可选的开发者、更容易找到的外包、更成熟的文档；冷门技术意味着这件活只能你自己干。

我的判断很简单：核心业务逻辑可以自己写，但基础设施和框架尽量选主流。 前者是你的资产，后者是你的负担。

第三条：部署与运维的复杂度

这是最容易被低估的一条。开发阶段你感觉不到运维成本，因为本地跑起来就万事大吉了；真正的问题都在上线之后。

一个具体的分界线：这套东西出问题时，需不需要你半夜爬起来处理。

• 单体应用：进程挂了重启一下，日志在一个地方，数据库就一个
• 拆成多个服务：要先判断是哪个服务挂了、它们之间的依赖有没有连锁反应、调用链怎么查

还有一类隐性成本：这套技术栈的部署方式你熟不熟。 如果你只在一台服务器上手动部署过，那跨环境、自动发布、回滚这些步骤就都是新的学习成本，而这些成本和你的业务没有半点关系。

第四条：生态是否稳定

“稳定”不等于“老”，而是指：这个技术的维护节奏稳不稳、破坏性变更多不多、周边库有没有人维护。

一个人没有精力天天跟着框架升级。一个半年一次破坏性升级、周边库半死不活的技术栈，会让你在“要不要升级”这件事上反复消耗 —— 不升级担心安全，升级又要重测一堆东西。

选成熟稳定的版本，比自己追最新版省事得多。

三种常见组合，各自适合谁

上面四条讲完，落到具体的组合上就清楚了。我不推荐具体框架，只讲这三类结构各自适合什么情况。

组合一：单体全栈框架

前端模板、后端路由、数据库操作、后台管理都在一套框架里，一个部署包搞定。

适合： 后台系统、内部工具、后台 + 移动端接口这类以业务逻辑为主的产品。开发速度最快，出问题最好查，第一个版本能最快跑起来。

代价： 前后端耦合，前端体验一般，将来想单独换前端会麻烦。但对早期产品来说，这个代价基本可以忽略 —— 你还没到需要拆开的时候。

组合二：前后端分离

后端只提供接口，前端是一个独立的应用（后台用一套框架，移动端再用另一套或统一用跨端方案）。

适合： 前端交互比较重、需要多端复用同一套后端接口的产品。

代价： 你要维护两套构建、两套部署、一套接口契约。这里的成本不在“写代码”，而在接口定义发生变化时两端要同步改 —— 这也是我写过那篇“多端产品怎么少写一遍代码”的原因：真正的坑在契约层，不在框架本身。

组合三：Serverless / 低代码 / 托管服务

把数据库、认证、存储、定时任务都交给托管平台，你只写业务函数或配置。

适合： 验证阶段、单人快速上线、流量波动大的工具类产品。

代价要提前想清楚： 一是成本模型 —— 请求量大之后托管平台的账单可能比自建服务器贵；二是迁移成本 —— 业务逻辑和某个平台绑得越深，将来迁走越难；三是调试难度 —— 出问题时你只能看平台给的日志，看不到底层。

我的用法是：用托管服务换启动速度，但核心数据和业务逻辑不要和平台绑死。 别人替你扛基础设施是好事，但前提是你随时能搬走。

除了技术本身，还要看三件事

选型不只看技术，还有三件事经常被忽略。

第一，能不能快速做出第一版。 一个人做产品，最大的风险是“做了半年还没上线”，不是“架构不够优雅”。选型时优先考虑“多久能跑通第一个闭环”，把优化留到有用户之后 —— 那时候你才知道该优化哪里。

第二，是不是你已经会的东西。 除非新产品本身就是要学一门新技术，否则不要在项目里同时学语言、学框架、学部署。学习的成本要单独算，而且往往比你以为的高。

第三，两三年后还有没有人在用。 这不是让你预测未来，而是看这个技术的社区活跃度、招聘需求、文档质量。有人维护、有人提问、有人回答，你踩坑时才有地方问。

什么时候应该选“先进”的

上面一直在讲保守，但保守不是目的。有两种情况，我反而会主动选新的东西：

• 新技术正好解决你的核心问题。 比如你的产品本质就是一个实时协作工具，那为它选一个适合实时通信的技术是合理的，哪怕它不够主流
• 老技术已经明显拖后腿。 不是因为它旧，而是因为它在你这个场景下已经出现了具体的瓶颈，换掉它的收益大于学习成本

关键是理由要具体：要么它解决了你的确确实实的问题，要么你能说清换与不换的收益差。“大家都说它好”不算理由。

小结

把上面几条收成一句话：一个人选技术栈，选的是“将来出问题时你能不能扛住”，不是“现在看起来先不先进”。

落到动作上，就是四条：出问题能独立定位、将来有人能接手、运维复杂度压得住、生态别三天两头折腾你。三条都占，再谈好不好用；占不到，再先进也先放一放。