UpUpUppppppp摘要：独立开发的技术栈，不是越新越好，也不是越全越好。尤其是主业之外做副业项目，真正重要的是：晚上下班后你还愿不愿意打开它、能不能快速改、能不能稳定上线。
前几天写到一个人做网站，最开始不一定需要后端。
这篇顺着往下写：如果先不急着上复杂后端，那我现在做独立开发，到底会怎么选技术栈？
先说一句不太“高级”的实话：
我现在对技术栈的要求，已经不再是“看起来很厉害”。
而是：
我下班回来还能不能改得动。
项目出问题的时候，我能不能快速定位。
隔两周没碰这个项目，再打开的时候，我会不会完全不想看。
这几个问题，比“用了什么最新框架”更现实。
因为我不是全职在做独立开发。
我的情况更像是：主业之外，抽时间做工具站、小程序、AI 应用、博客内容和一些副业尝试。
所以技术栈对我来说，不只是技术选择，也是精力管理。
我以前也容易把技术栈想复杂
刚开始做项目的时候，我也会忍不住想很多。
前端用什么框架？
后端用什么语言？
数据库选哪一个？
部署用哪套方案？
登录、权限、支付、后台管理是不是都要先搭好？
甚至页面还没写几行，脑子里已经开始规划一套“未来可以扩展到很大”的架构。
这种感觉挺像收拾行李。
明明只是出门两天，结果把一年四季的衣服都塞进箱子里。
看起来准备很充分，但最后真正拖累自己的，往往也是这个箱子。
我现在更愿意反过来问：
这个项目第一版，最小需要哪些东西？
哪些技术是今天必须有的？
哪些只是我想象中以后可能会用到的？
如果一个东西现在不用也能上线，我就尽量先不把它放进来。
我现在会把技术栈分成四层
这不是标准答案，只是我目前更舒服的一种拆法。
第一层：页面和交互。
也就是用户真正看到、真正使用的部分。
对工具站来说，这一层通常是最重要的。
用户点进来，不关心你后面用了什么架构，他只关心：
这个页面能不能打开。
这个按钮点了有没有反应。
这个工具能不能解决他的问题。
所以我现在会把很多精力放在页面结构、表单体验、结果展示、移动端适配、加载速度上。
第二层：内容和静态数据。
很多小项目一开始并不需要数据库。
比如工具说明、功能列表、常见问题、更新记录、导航分类，这些完全可以先用 Markdown、JSON、配置文件，或者简单的静态页面来维护。
它不一定优雅，但足够直接。
最重要的是，我自己能快速改。
第三层：部署和访问。
这个阶段我会优先考虑轻部署。
比如静态站点托管、自动构建、域名解析、HTTPS、重定向、基础 SEO 信息。
这些东西看起来不如写功能有成就感，但它们决定了一个项目能不能真正被访问到。
一个页面写得再好，如果部署麻烦、访问不稳定、搜索引擎看不懂，也很难积累长期价值。
第四层：后续再补的能力。
比如账号、数据库、支付、后台管理、用户历史记录、会员体系、数据分析看板。
这些不是不要。
而是先放在“等需求出现再做”的位置。
对副业项目来说，这个顺序很重要。
因为你先做重能力，很可能还没等到用户，就先把自己累到了。
我的真实选择：优先选“维护成本低”的工具
如果让我现在重新做一个小网站，我大概会按这个思路选：
前端先选自己熟悉、能快速出页面的方案。
不一定非要追最新。
如果你熟 React，就用 React。
如果你熟 Vue，就用 Vue。
如果只是很简单的页面，甚至普通 HTML、CSS、JavaScript 也可以。
关键不是别人说哪个更先进，而是你能不能在半夜改一个样式、加一个字段、修一个 bug。
样式方案也一样。
不要为了“工程化”把自己绕进去。
第一版只要能保持统一、好维护、页面不丑，就已经够用了。
部署尽量选简单稳定的。
比如静态网站可以先走 Cloudflare Pages、Vercel、Netlify 这类平台。
它们不一定适合所有场景，但对早期小项目来说，能帮你省下很多服务器维护成本。
数据存储先克制一点。
能不用数据库，就先不用。
能用静态文件解决，就先用静态文件。
确实需要收集用户反馈，可以先用表单、问卷、邮件、第三方服务顶一下。
等你真的看到有人使用，再决定要不要把这部分做成自己的系统。
这套选择听起来不性感。
但对我这种兼职做副业项目的人来说，它有一个好处：
项目不容易死在“太麻烦”上。
如果你也在选技术栈，我建议先看 5 个标准
这部分是这篇文章真正想给读者带走的东西。
不要先问“哪个技术栈最强”。
先问下面 5 个问题。
- 你自己熟不熟？
副业项目最怕的是每一步都在学习新东西。
学习当然重要，但如果你的目标是先把产品做出来，第一版尽量用你已经能掌控的技术。
否则你以为自己在做产品，其实大部分时间都在补课。
- 出问题时你能不能定位？
技术栈不是只在写代码时有用。
真正考验它的是出问题的时候。
部署失败、页面白屏、接口报错、移动端错位、构建不通过。
如果每次遇到问题都要查半天，副业项目很容易被这种小阻力消耗掉。
- 隔一段时间回来，你还看得懂吗？
这个标准很现实。
副业项目经常不是每天连续推进，而是断断续续。
今天改一点，过几天再改一点。
所以技术栈和代码结构一定要让“未来的自己”能看懂。
别让一个月后的自己像接手陌生项目一样痛苦。
- 它会不会拖慢上线？
如果一个技术选择让你多花一周搭环境、多花三天读文档、多花两晚解决部署问题，那就要谨慎。
不是说它不好。
而是它可能不适合你的第一版。
早期项目最重要的是验证。
验证用户需不需要，验证你能不能持续做，验证内容和产品有没有积累价值。
- 以后能不能平滑升级？
轻量不等于乱来。
第一版可以简单，但最好别把路走死。
比如目录结构清晰一点。
页面和数据稍微分开一点。
组件命名别太随意。
部署流程留好。
这些小习惯不会增加太多成本，但以后扩展会轻松很多。
我现在最怕的技术栈，不是旧，而是重
有些技术并不新，但很稳定、好维护、资料多。
这类技术我反而挺喜欢。
我现在真正警惕的是“重”。
重到你每次启动项目都要想一下命令。
重到改一个页面要牵动一堆配置。
重到部署一次要盯着好几个服务。
重到你还没开始做功能，已经在处理工程问题。
这类技术栈不是不好。
它可能适合团队，适合中大型系统，适合明确商业化后的产品。
但对一个刚开始做副业项目的人来说，它可能会让你一开始就背着很大的包。
我现在的判断是：
项目越早期，技术栈越应该轻。
需求越不确定，架构越不应该重。
用户越少，越不要提前为“百万用户”设计。
先把第一个真实用户服务好，比想象一百万用户更重要。
技术栈也会暴露一个人的做事方式
以前我会觉得，技术栈只是工具。
现在我觉得，它也会暴露一个人的做事方式。
有人喜欢先搭一个完整系统，再慢慢填功能。
有人喜欢先做出一个能用的东西，再一点点补齐。
这两种方式没有绝对对错。
但如果你和我一样，是在主业之外做独立开发，我会更建议第二种。
因为副业项目不是考试。
没有人给你架构打分。
用户也不会因为你用了某个新框架就多停留 30 秒。
他们只会关心：
这个东西对我有没有用？
打开快不快？
能不能解决我的问题？
下次我还会不会回来？
技术栈最后应该服务这些问题。
而不是反过来，让项目服务技术栈。
今天的小结
我现在的独立开发技术栈，核心不是某一个具体框架。
而是一套选择原则：
熟悉优先。
简单优先。
上线优先。
维护优先。
按需升级。
如果你也准备做自己的第一个工具站、小程序或者产品页，我建议不要先去收藏一堆“最佳技术栈”文章。
先问自己：
我能不能用这套东西，在一周内做出一个别人能打开的版本？
我能不能在下班后继续维护它？
它能不能帮我更快验证真实需求？
如果答案是能，那它对你来说就是好技术栈。
不一定高级。
但能让项目活下来。
这对独立开发早期来说，已经很重要了。
下一篇我会开始写小程序相关内容：我做的第一个小程序“创业人格测评”第一版，到底长什么样，以及我为什么先做这么一个轻量产品。
大家可以关注的公众号：UP独立开发笔记，我会持续更新我的独立开发历程