折腾来折腾去，到底是为了什么？一个全栈开发者的工程化反思

记录一下最近做项目选型时，那些真能把人搞崩溃的细节。是我自己跟自己较劲，来回折腾后的一点总结。不一定对，但每句话都是花时间踩坑换来的。

最近想做个书签小工具，一共也就 30 来个接口，结果在“用什么技术”这个问题上，我纠结了快一个月。感觉就像在技术的林子里瞎转，看见哪儿有光就往哪儿跑，最后发现每个亮光后面都是个坑。

第一步：跟着“技术主流”走，结果浑身难受

事情是这样的，我想自己做点小产品。工作上我一直用 Vue，很顺手。但网上看了一圈，大家都在说 “Next.js + React + shadcn-ui” 才是现在做东西的正道。生态好、组件多、未来可期。

我一想，不能老用自己熟悉的，换个口味吧。于是放下 Vue，开始用 React。结果一上来就懵了：选择太多了，不知道该用哪个。

根本不是简单的二选一，而是每个地方都有好几个选择，我大部分时间都在搜资料、看对比、做选择：

感觉我的主要工作不是写代码，而是在研究“该用什么写代码”。更烦的是那些莫名其妙的 “水合错误（Hydration Error）”，写个页面一刷新就报错，然后就得花时间找哪里对不上。

最心累的是到处都要加 “use client”。我感觉自己不是在写功能，是在给代码打标签。每加一行我就在想：“如果这么多东西最终都要在客户端跑，那我为啥要选这个把前后端拆这么碎、心智负担这么重的框架？”

我回到熟悉的 Vue 生态，用了 Nuxt。果然舒服多了，开发效率起飞。

但安静没两天，看网上还是到处在夸 Next.js 生态好。心里又开始想：“我是不是选错了？会不会错过什么？” 不信邪，又回头去试了几天 Next.js。结果，那些熟悉的、琐碎的麻烦全回来了。

这回我彻底认了：技术没有绝对的好坏，只有合不合适。我相信自己用着舒服的感觉，这种“手感”骗不了人。

前端定了，该写后端了。我选了大家说最工程化的 NestJS。为了显得更专业，又强行上了 Monorepo。这下彻底麻烦了，我亲手给自己搞了个大工程：

开发摩擦力极大： 在 Monorepo 里改个公共的枚举值或类型，要重新构建、等 Workspace 同步、重启服务。原本 10 秒钟的事，现在要等 1 分钟。
兼容性地狱： NestJS 守着 CommonJS 的旧梦，我想用个纯 ESM 的库或者跑个 TypeScript Worker 线程，配置文件的报错能让你怀疑人生，得花大把时间研究编译器路径。
仪式感的内耗： 就 30 个接口，要写一堆 Controller、Service、Module、DTO。代码量翻了几倍，但核心逻辑一点没变。
Swagger 的折磨： 我想用 Zod 做验证，Swagger 却只认装饰器（class-validator）。为了那张 API 文档，我得被迫维护两份几乎一样的数据定义，手动同步两份 DTO 的痛苦只有写过的人才懂。

我用一个可能永远用不上的“大团队优势”，换来了眼前的“低效率”。 我想要的是快点做出来，但重框架让我优先考虑怎么让代码“更好维护”，这完全本末倒置了。

我决定不用这些重框架了，选了 Fastify，想着以后不行还能换回去。但我发现，问题不只是“重”，而是 “自由带来的恐慌”。

Fastify 很自由，但对我这种习惯了某种结构的人来说，自由反而成了压力：

我嫌重框架规矩多，但真给自由了，我又不知道该怎么用了。我从复杂的流程里出来，又掉进了“什么都要自己找”的坑。

我终于明白：我选的那些框架，都基于我自己的知识惯性。我嫌重框架规矩多，但内心又想要固定结构，这种心态本身就是撕裂的。

又一个加班到很晚的深夜，我对着屏幕问自己：我折腾这么久，到底图啥？不就是想快点做出这个小工具吗？

一下子通透了。我之前一直在用“大团队长期维护”的标准，来要求我这个“个人快速项目”。这就像为了去隔壁超市买菜，非要先修一条八车道的高速公路。

我给自己定了个简单的规矩：

折腾的时候注意到了 AdonisJS，有人说是 Node.js 里的 Laravel。简单看了看，它好像正好平衡了我的纠结：有我要的固定结构（ORM、Auth 都有），又是现代的风格，原生支持 ESM。下次可以试试。

这些就是我折腾一圈的想法。我的做法可能不对，甚至挺笨的。 所以想听听你们怎么看。你们有没有类似的问题？最后怎么解决的？ 欢迎在评论区聊聊，让我也学习一下。