feat(blog): 更新博客文章，分享全栈开发者的技术选型反思与经验

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

@@ -1,76 +1,78 @@
----
-layout: "@/layouts/BlogPostLayout.astro"
-title: "别再被\"最佳实践\"绑架了：一个全栈开发者的选型忏悔录"
-description: "一名全栈开发者在开发 30 个接口的小项目时，过度追逐技术潮流而陷入困境的真实记录。本文探讨了重型框架的心智负担、Monorepo 的陷阱，并提出了一套务实的两套技术栈选型方案。"
-date: "2026-01-08"
-image: "https://images.unsplash.com/photo-1518770660439-4636190af475?q=80&w=1470&auto=format&fit=crop"
-tags: ["技术栈选型", "全栈开发", "框架选择", "最佳实践", "开发者体验"]
-tagId: ["tech-stack", "fullstack", "framework", "best-practices", "developer-experience"]
-category: "技术分享"
-categoryId: "technology"
-readTime: "6 分钟阅读"
----
+# 折腾来折腾去，到底是为了什么？ 一个全栈开发者的工程化反思
 
-> **写在前面：**
-> 本人是一名从前端转 Node.js 全栈的开发者。这篇文章只是基于我近期开发项目时的一些真实经历和感悟。由于个人知识储备和认知水平有限，文中的观点不一定正确，更不代表行业标准。这仅仅是我在踩了无数坑后的一点自我总结，发出来是希望能和大家交流，也给有类似纠结的朋友提供一个参考。如有谬误，欢迎评论区指正。
+> 记录一下最近做项目选型时，那些真能把人搞崩溃的细节。是我自己跟自己较劲，来回折腾后的一点总结。不一定对，但每句话都是花时间踩坑换来的。
 
-最近我为了做一个只有 30 个接口的书签类小工具，把自己折腾疯了。
+最近想做个书签小工具，一共也就 30 来个接口，结果在“用什么技术”这个问题上，我纠结了快一个月。感觉就像在技术的林子里瞎转，看见哪儿有光就往哪儿跑，最后发现每个亮光后面都是个坑。
 
-起初，我像个在技术丛林里乱撞的猎人：哪里有亮光（新工具/大牛言论），我就往哪冲。结果发现，每一个亮光后面都藏着一个更深的坑。
+## 第一步：跟着“技术主流”走，结果浑身难受
 
-## 1. 追逐流行，是内耗的开始
+事情是这样的，我想自己做点小产品。工作上我一直用 Vue，很顺手。但网上看了一圈，大家都在说 **“Next.js + React + shadcn-ui”** 才是现在做东西的正道。生态好、组件多、未来可期。
 
-我最开始随大流选了 **Next.js + NestJS + shadcn-ui**。我想着，既然大家都说这是"全栈天花板"，那选它准没错。结果现实反手就给了我一巴掌。
+我一想，不能老用自己熟悉的，换个口味吧。于是放下 Vue，开始用 React。结果一上来就懵了：**选择太多了，不知道该用哪个。**
 
-在 Next.js 里，为了选一个数据处理和状态管理方案（SWR 还是 Zustand？），我硬生生磨掉了一周。好不容易开工了，又被服务端渲染（SSR）带来的复杂度搞得头大——频繁定义 `"use client"` 指令、处理莫名其妙的"状态水合（Hydration）"报错、还要手动管理状态依赖并优化一堆回调函数。
+根本不是简单的二选一，而是每个地方都有好几个选择，我大部分时间都在搜资料、看对比、做选择：
 
-我当时就在想：**我只是想写个简单的业务逻辑，为什么要花 80% 的精力去处理框架带来的麻烦？**
+* 数据请求是用 **SWR** 还是 **TanStack Query**？
+* 全局状态是用 **Zustand** 还是继续用 **Redux**、**Jotai**？
+* 服务端和客户端数据怎么同步？在这个边界上我反复拉扯。
 
-## 2. 框架重一点，心智负担就大一点
+感觉我的主要工作不是写代码，而是在研究“该用什么写代码”。更烦的是那些莫名其妙的 **“水合错误（Hydration Error）”**，写个页面一刷新就报错，然后就得花时间找哪里对不上。
 
-后来前端切到了 Nuxt 确实顺手了些，但后端我依然守着 **NestJS**，追求所谓的"大而全"。
+最心累的是到处都要加 `“use client”`。我感觉自己不是在写功能，是在给代码打标签。每加一行我就在想：**“如果这么多东西最终都要在客户端跑，那我为啥要选这个把前后端拆这么碎、心智负担这么重的框架？”**
 
-但我一共才 30 个接口，业务逻辑极其简单。但在 NestJS 里，我不得不写 Controller、Service、Module、DTO……代码量翻了几倍。更崩溃的是 **ESM 的兼容问题**，NestJS 依然守着 CommonJS 的旧梦，导致我想用一些最新的 ESM 库时，各种配置文件报错。为了跑通一个简单的 TypeScript Worker 线程，我还得自己去研究 ESM 编译器。
+## 第二步：用回顺手的，又怕自己落伍了
 
-最心累的是 **Swagger 的集成**。现在大家都爱用 Zod 做验证，但 Swagger 深度绑定类装饰器模式（class-validator）。为了让 Swagger 识别 Zod Schema 并生成文档，我得自己手搓适配器和装饰器。
+我回到熟悉的 Vue 生态，用了 Nuxt。果然舒服多了，开发效率起飞。
 
-**我感觉自己不是在开发产品，我是在修一辆零件互不兼容的破拖拉机。**
+但安静没两天，看网上还是到处在夸 Next.js 生态好。心里又开始想：**“我是不是选错了？会不会错过什么？”** 不信邪，又回头去试了几天 Next.js。结果，那些熟悉的、琐碎的麻烦全回来了。
 
-## 3. Monorepo：独立开发者的"温柔陷阱"
+这回我彻底认了：**技术没有绝对的好坏，只有合不合适。我相信自己用着舒服的感觉，这种“手感”骗不了人。**
 
-为了追求代码复用，我还折腾了 **Monorepo**。
+## 第三步：总想“搞得专业点”，结果给自己挖坑
 
-我想着，前后端共享类型、枚举、错误码，多优雅！但现实是：为了让纯 ESM 的前端和非纯血 ESM 的后端共享一个包，我陷入了无穷无尽的编译配置中。由于 NestJS 的环境问题，我必须为共享包进行编译导出才能使用，导致频繁修改调试代码时异常麻烦。
+前端定了，该写后端了。我选了大家说最工程化的 **NestJS**。为了显得更专业，又强行上了 **Monorepo**。这下彻底麻烦了，我亲手给自己搞了个大工程：
 
-原本一分钟写完的代码，因为要处理跨包调试、TS 类型同步和打包逻辑，硬生生变成了十分钟。
+* **开发摩擦力极大：** 在 Monorepo 里改个公共的枚举值或类型，要重新构建、等 Workspace 同步、重启服务。原本 10 秒钟的事，现在要等 1 分钟。
+* **兼容性地狱：** NestJS 守着 CommonJS 的旧梦，我想用个纯 ESM 的库或者跑个 TypeScript Worker 线程，配置文件的报错能让你怀疑人生，得花大把时间研究编译器路径。
+* **仪式感的内耗：** 就 30 个接口，要写一堆 Controller、Service、Module、DTO。代码量翻了几倍，但核心逻辑一点没变。
+* **Swagger 的折磨：** 我想用 Zod 做验证，Swagger 却只认装饰器（class-validator）。为了那张 API 文档，我得被迫维护两份几乎一样的数据定义，手动同步两份 DTO 的痛苦只有写过的人才懂。
 
-**我悟了：Monorepo 是为了解决"组织协作"的，对于独立开发者，它往往是效率杀手。**
+**我用一个可能永远用不上的“大团队优势”，换来了眼前的“低效率”。** 我想要的是快点做出来，但重框架让我优先考虑怎么让代码“更好维护”，这完全本末倒置了。
 
-## 4. 回归务实：我的"两套方案"
+## 第四步：换个轻量的，反而更不会写了
 
-在折腾的终点，我反思：有没有完美的框架？结论是没有，只有适合的。于是，我把我的选型逻辑简化成了两套：
+我决定不用这些重框架了，选了 **Fastify**，想着以后不行还能换回去。但我发现，问题不只是“重”，而是 **“自由带来的恐慌”**。
 
-* **方案 A：快速验证（MVP / 个人项目）**
-    **技术栈：Nuxt 一把梭。** 别分前后端了，Nuxt 的内置 Server API（Nitro）足够处理中小业务。类型天然共享，没有跨域烦恼。在验证阶段，**"快"比"优雅"重要一百倍。**
+Fastify 很自由，但对我这种习惯了某种结构的人来说，自由反而成了压力：
 
-* **方案 B：复杂业务（大型项目 / 团队协作）**
-    **技术栈：Nuxt + NestJS 分离 + Monorepo。** 当业务复杂到需要严格的分层、需要依赖注入（DI）解耦、需要多人协作时，才去忍受这种"重"框架带来的仪式感和管理成本。
+* “代码该放哪？”
+* “这个功能怎么组织成插件？”
+* 日志、队列、鉴权这些在 NestJS 里现成的，现在都要自己找库、集成、调试。
 
-## 5. 题外话：意外发现的新希望 AdonisJS
+我嫌重框架规矩多，但真给自由了，我又不知道该怎么用了。我从复杂的流程里出来，又掉进了“什么都要自己找”的坑。
 
-就在我总结完上述方案后，我最近无意间发现了一个新的框架——**AdonisJS**。它被很多开发者评价为 Node.js 界的 Laravel。
+**我终于明白：我选的那些框架，都基于我自己的知识惯性。我嫌重框架规矩多，但内心又想要固定结构，这种心态本身就是撕裂的。**
 
-我简单看了一下它的设计理念，感觉它似乎精准地击中了我上述遇到的很多痛点：它原生支持 ESM、内置了强大的 ORM 和 Auth 方案、不需要像 NestJS 那样去折腾各种复杂的适配器来搞定自动化的 Swagger 文档生成。
+## 终于想明白：技术是拿来用的，不是拿来供着的
 
-这种"约定优于配置"的全栈框架，似乎能平衡开发效率与工程质量。我准备在接下来的项目中实际试用一下，如果确实好用，有了心得后再专门写篇文章分享给大家。
+又一个加班到很晚的深夜，我对着屏幕问自己：**我折腾这么久，到底图啥？不就是想快点做出这个小工具吗？**
 
-## 6. 总结：给开发者的一点建议
+一下子通透了。我之前一直在用“大团队长期维护”的标准，来要求我这个“个人快速项目”。这就像为了去隔壁超市买菜，非要先修一条八车道的高速公路。
 
-1.  **没有完美的框架，只有最适合当下的。** 不要指望任何一个明星框架能解决所有问题，它们都有代价。
-2.  **不要在独立开发或工作中轻易尝试自己不熟悉的技术栈。** 除非你真的有大把的时间和精力去踩坑。你以为在学新技术，其实你是在浪费产品的寿命。
-3.  **警惕"大厂最佳实践"。** 很多在大公司里解决痛点的工具（如 Monorepo、过度分层），在个人项目里往往只会制造痛点。
-4.  **熟悉度大于先进性。** 哪怕一个框架被说成是"老古董"，只要你用得顺手、能让你早点下班，它就是你的银弹。
+我给自己定了个简单的规矩：
 
-**最好的技术栈，是那个能让你忘记技术本身，而专注于创造价值的工具。**
+* **做原型、小工具、简单应用**：直接用 **Nuxt 一把梭**。前后端在一个包里写，类型天然同步，没有跨域，没有同步内耗。目标就是快，能跑起来比什么都强。
+* **复杂系统、多人协作、长期维护**：再考虑 **Nuxt + NestJS + Monorepo**。这时候复杂点能接受，因为确实需要架构支撑。
 
-最后想说，我总结的这些方案也仅仅是适合我个人的开发习惯和目前的认知，并不一定适合所有人。每个人面对的业务场景和技术背景都不同，**大家如果有更好的方案或想法，非常欢迎在评论区讨论，让我也有机会学习一下。** 不对的地方也希望各位大佬多多指教，先行谢过！
+## 顺便提一句：看到个新选择
+
+折腾的时候注意到了 **AdonisJS**，有人说是 Node.js 里的 Laravel。简单看了看，它好像正好平衡了我的纠结：有我要的固定结构（ORM、Auth 都有），又是现代的风格，原生支持 ESM。下次可以试试。
+
+## 最后说几句
+
+1. **别盲目追技术热点**：适合别人的不一定适合你。
+2. **相信自己用着顺手的感觉**：这比流行趋势重要得多。
+3. **先做出来再优化**：对于个人项目，跑不起来的架构就是一堆废纸。
+4. **警惕“配置内耗”**：如果配置时间比写代码还长，就该换工具了。
+
+这些就是我折腾一圈的想法。**我的做法可能不对，甚至挺笨的。** 所以想听听你们怎么看。**你们有没有类似的问题？最后怎么解决的？** 欢迎在评论区聊聊，让我也学习一下。

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

@@ -1,76 +0,0 @@
-# 从追逐流行到回归工程：我技术选型的“降噪”思考
-
-过去几年里，我尝试过很多 Node.js 框架和前端技术栈：**Express、Koa、Fastify、Hono.js**，以及前端的 **Next.js**。这些框架和工具都有各自的优点：轻量、灵活、性能好，社区里也有不少人推荐。然而，随着项目的深入，我逐渐发现了一个事实：**简单、快速实现、自己熟悉、生态完善、可扩展性好**，才是最重要的，而不是盲目追逐“最流行”或“性能最高”的框架。
-
-## 为什么不是 Next.js？
-
-我也写过 React 和 Next.js，但总感觉生态太杂。尤其是 **状态管理**，从 Redux、MobX 到 Zustand、Jotai，再到 React Query、TanStack Query，每一种都有各自的优缺点，但选择过多反而让我心智负担加重。很多问题并不是没有解决方案，而是解决方案太多、没有统一的“最佳实践”。
-
-相比之下，**NuxtJS 在 Vue 生态下要更工程化**。比如：
-
-* 内置路由、布局、服务端渲染等功能，不需要额外选型。
-* Vue 的响应式和 Pinia 状态管理简单好用，不需要反复对比。
-* 配合 Nuxt UI、TailwindCSS，可以快速构建出一致的前端体验。
-
-对我来说，NuxtJS 的“约定优于配置”正好能让我聚焦在业务上，而不是被生态碎片化牵扯精力。
-
-## 为什么选择 NestJS？
-
-很多人说 **NestJS 太重**，但我的实际体验是：**它恰到好处**。
-
-* NestJS 自带 CLI，可以快速生成模块、控制器、服务，大大提升开发效率。
-* 内置依赖注入、装饰器模式，让代码组织更清晰、可维护。
-* 和 TypeScript 深度结合，不仅提高了开发体验，也减少了运行时错误。
-* 对数据库、认证、缓存、消息队列等都有完善的解决方案，遇到问题时社区文档和生态资源都很丰富。
-
-更重要的是，在 **AI 辅助开发** 的今天，像 NestJS 和 NuxtJS 这种约定清晰、工程化程度高的框架，更容易被 AI 理解和提供正确的解决方案。相比一些过于灵活的轻量框架，AI 在这类框架上的“知识盲区”更少。
-
-## 两套技术方案
-
-结合我的经验和实际需求，我总结出了两套适合的技术栈：
-
-### 1. 轻量级方案（业务简单）
-
-* **NuxtJS**
-* **Drizzle ORM**
-* **Nuxt UI**
-* **TailwindCSS**
-
-适合快速原型、简单应用、验证市场。
-
-### 2. 完整方案（业务复杂）
-
-* **NestJS**
-* **NuxtJS**
-* **Zod**
-* **Drizzle ORM**
-* **Redis**
-* **Postgres**
-* **Nuxt UI**
-* **TailwindCSS**
-
-适合需要后端独立、扩展性强的项目，可以通过微服务、缓存、消息队列等方式支撑更复杂的业务。
-
-## 性能并不是唯一的答案
-
-很多人推崇 **Hono.js**、**Elysia.js** 等轻量框架，说它们“简单、快、性能好”。确实，在 Hello World 或简单 API 的场景下，它们的性能数据很漂亮。但在真实的生产环境里，**性能瓶颈往往不在框架**，而在：
-
-* 数据库查询优化
-* 缓存策略
-* 多实例部署
-* 微服务架构
-* 负载均衡与扩展能力
-
-这时候，单一框架的“性能优势”几乎可以忽略。真正决定系统表现的，是整体架构设计和资源利用。
-
-## 结论
-
-我的体会是：**技术选型没有绝对的好坏，关键在于适合自己和项目需求**。
-对我来说，NestJS + NuxtJS 这套组合：
-
-* 工程化、生态完善，能快速实现功能。
-* 熟悉度高，减少了心智负担。
-* 易于扩展，能应对简单和复杂的业务场景。
-* 在 AI 辅助的今天，更容易获得准确支持。
-
-因此，哪怕有人说它们“重”或“不如某某框架”，我依然会坚持：**适合自己的，才是最好的技术栈**。