feat: 添加关于选择 Nuxt.js 和 NestJS 的文章

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

@@ -0,0 +1,76 @@
+# 我为什么放弃 Next.js，选择 Nuxt.js 和 NestJS
+
+过去几年里，我尝试过很多 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 辅助的今天，更容易获得准确支持。
+
+因此，哪怕有人说它们“重”或“不如某某框架”，我依然会坚持：**适合自己的，才是最好的技术栈**。