feat: 添加全栈开发者的选型忏悔录文章

src/pages/zh/blog/posts/2026010801.md

@@ -0,0 +1,65 @@
+# 别再被“最佳实践”绑架了：一个全栈开发者的选型忏悔录
+
+> **写在前面：**
+> 本人是一名从前端转 Node.js 全栈的开发者。这篇文章只是基于我近期开发项目时的一些真实经历和感悟。由于个人知识储备和认知水平有限，文中的观点不一定正确，更不代表行业标准。这仅仅是我在踩了无数坑后的一点自我总结，发出来是希望能和大家交流，也给有类似纠结的朋友提供一个参考。如有谬误，欢迎评论区指正。
+
+最近我为了做一个只有 30 个接口的书签类小工具，把自己折腾疯了。
+
+起初，我像个在技术丛林里乱撞的猎人：哪里有亮光（新工具/大牛言论），我就往哪冲。结果发现，每一个亮光后面都藏着一个更深的坑。
+
+## 1. 追逐流行，是内耗的开始
+
+我最开始随大流选了 **Next.js + NestJS + shadcn-ui**。我想着，既然大家都说这是“全栈天花板”，那选它准没错。结果现实反手就给了我一巴掌。
+
+在 Next.js 里，为了选一个数据处理和状态管理方案（SWR 还是 Zustand？），我硬生生磨掉了一周。好不容易开工了，又被服务端渲染（SSR）带来的复杂度搞得头大——频繁定义 `"use client"` 指令、处理莫名其妙的“状态水合（Hydration）”报错、还要手动管理状态依赖并优化一堆回调函数。
+
+我当时就在想：**我只是想写个简单的业务逻辑，为什么要花 80% 的精力去处理框架带来的麻烦？**
+
+## 2. 框架重一点，心智负担就大一点
+
+后来前端切到了 Nuxt 确实顺手了些，但后端我依然守着 **NestJS**，追求所谓的“大而全”。
+
+但我一共才 30 个接口，业务逻辑极其简单。但在 NestJS 里，我不得不写 Controller、Service、Module、DTO……代码量翻了几倍。更崩溃的是 **ESM 的兼容问题**，NestJS 依然守着 CommonJS 的旧梦，导致我想用一些最新的 ESM 库时，各种配置文件报错。为了跑通一个简单的 TypeScript Worker 线程，我还得自己去研究 ESM 编译器。
+
+最心累的是 **Swagger 的集成**。现在大家都爱用 Zod 做验证，但 Swagger 深度绑定类装饰器模式（class-validator）。为了让 Swagger 识别 Zod Schema 并生成文档，我得自己手搓适配器和装饰器。
+
+**我感觉自己不是在开发产品，我是在修一辆零件互不兼容的破拖拉机。**
+
+## 3. Monorepo：独立开发者的“温柔陷阱”
+
+为了追求代码复用，我还折腾了 **Monorepo**。
+
+我想着，前后端共享类型、枚举、错误码，多优雅！但现实是：为了让纯 ESM 的前端和非纯血 ESM 的后端共享一个包，我陷入了无穷无尽的编译配置中。由于 NestJS 的环境问题，我必须为共享包进行编译导出才能使用，导致频繁修改调试代码时异常麻烦。
+
+原本一分钟写完的代码，因为要处理跨包调试、TS 类型同步和打包逻辑，硬生生变成了十分钟。
+
+**我悟了：Monorepo 是为了解决“组织协作”的，对于独立开发者，它往往是效率杀手。**
+
+## 4. 回归务实：我的“两套方案”
+
+在折腾的终点，我反思：有没有完美的框架？结论是没有，只有适合的。于是，我把我的选型逻辑简化成了两套：
+
+* **方案 A：快速验证（MVP / 个人项目）**
+    **技术栈：Nuxt 一把梭。** 别分前后端了，Nuxt 的内置 Server API（Nitro）足够处理中小业务。类型天然共享，没有跨域烦恼。在验证阶段，**“快”比“优雅”重要一百倍。**
+
+* **方案 B：复杂业务（大型项目 / 团队协作）**
+    **技术栈：Nuxt + NestJS 分离 + Monorepo。** 当业务复杂到需要严格的分层、需要依赖注入（DI）解耦、需要多人协作时，才去忍受这种“重”框架带来的仪式感和管理成本。
+
+## 5. 题外话：意外发现的新希望 AdonisJS
+
+就在我总结完上述方案后，我最近无意间发现了一个新的框架——**AdonisJS**。它被很多开发者评价为 Node.js 界的 Laravel。
+
+我简单看了一下它的设计理念，感觉它似乎精准地击中了我上述遇到的很多痛点：它原生支持 ESM、内置了强大的 ORM 和 Auth 方案、不需要像 NestJS 那样去折腾各种复杂的适配器来搞定自动化的 Swagger 文档生成。
+
+这种“约定优于配置”的全栈框架，似乎能平衡开发效率与工程质量。我准备在接下来的项目中实际试用一下，如果确实好用，有了心得后再专门写篇文章分享给大家。
+
+## 6. 总结：给开发者的一点建议
+
+1.  **没有完美的框架，只有最适合当下的。** 不要指望任何一个明星框架能解决所有问题，它们都有代价。
+2.  **不要在独立开发或工作中轻易尝试自己不熟悉的技术栈。** 除非你真的有大把的时间和精力去踩坑。你以为在学新技术，其实你是在浪费产品的寿命。
+3.  **警惕“大厂最佳实践”。** 很多在大公司里解决痛点的工具（如 Monorepo、过度分层），在个人项目里往往只会制造痛点。
+4.  **熟悉度大于先进性。** 哪怕一个框架被说成是“老古董”，只要你用得顺手、能让你早点下班，它就是你的银弹。
+
+**最好的技术栈，是那个能让你忘记技术本身，而专注于创造价值的工具。**
+
+最后想说，我总结的这些方案也仅仅是适合我个人的开发习惯和目前的认知，并不一定适合所有人。每个人面对的业务场景和技术背景都不同，**大家如果有更好的方案或想法，非常欢迎在评论区讨论，让我也有机会学习一下。** 不对的地方也希望各位大佬多多指教，先行谢过！