feat: 添加技术选型文章并更新相关内容

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

@@ -0,0 +1,47 @@
+# 技术选型这件小事：为什么我不再迷信“轻量”和“流行”了？
+
+最近在折腾新项目，又经历了一轮技术栈选型的纠结。
+
+说实话，过去几年我也算是个“追风少年”。从经典的 Express、Koa 到后来的 Fastify，甚至最近火得不行的 Hono、Elysia，我基本都尝试过。前端更不用说，Next.js 几乎曾是我的闭眼首选。但折腾的项目多了，我发现这种“追新”的过程其实挺累的，我心里的那杆秤开始往另一边斜了。
+
+今天想聊聊，我为什么在很多场景下，不再首选那些最轻、最火的东西，反而转向了一些被大家嫌弃“重”的工具。
+
+## 1. 灵活性，有时候是个坑
+
+以前选框架，我最看重的是“自由”。我想怎么写就怎么写，想用哪个库就接哪个库，觉得这才叫“掌控感”。
+
+但这种自由是有代价的。就拿 React 社区的 Next.js 来说，它确实厉害，但生态真的太碎了。光是一个状态管理，你就得在 Redux、Zustand、Jotai、Recoil 之间纠结半天；发个请求，又是 SWR 又是 TanStack Query。
+
+**这时候你会发现，你的时间没花在业务逻辑上，全花在“做选择”和“配环境”上了。**
+
+所以后来我更倾向于像 Nuxt 这种“全家桶”思维。它把路由、状态管理、SSR 甚至 UI 规范都给你定好了。你不需要去对比方案 A 还是方案 B，直接上手写代码就行。这种“约定优于配置”的感觉，真的只有当你被各种琐碎选型折磨过之后，才会明白有多省心。
+
+## 2. 框架重一点，大脑就轻一点
+
+后端这块，我最近反而更爱用 NestJS 了。
+
+很多人一听 NestJS 就摇头，说它太重了、概念太多、装饰器满天飞。对比起几行代码就能跑起来的轻量级框架，它确实显得像个巨兽。
+
+但我现在的想法变了：**框架重一点没关系，只要它能让我的心智负担变轻。**
+
+NestJS 这种高度标准化的结构，其实是一种保护。它强迫你把代码分层，强迫你写依赖注入。这带来的好处是：不管过了半年还是一年，我翻开代码，一看目录结构就能马上入场。
+
+而且说句实在的，现在咱们都用 AI 写代码（比如 Cursor 这种）。**AI 最喜欢这种条条框框明确的东西了。** 在 Nest 或者 Nuxt 这种结构严谨、约定清晰的框架里，AI 生成的代码准确率极高，因为它知道什么东西该放在什么位置。相反，那些太灵活、太天马行空的写法，AI 反而容易“胡言乱语”。
+
+## 3. 性能数据，往往是最大的烟雾弹
+
+现在的技术社区，各种基准测试（Benchmark）满大街跑，每个新框架出来都说自己比别人快几倍。
+
+但咱们摸着良心说，在真实的生产环境里，那点框架层面的微秒级差异，真的是瓶颈吗？
+
+**真正的瓶颈永远在数据库查询、在缓存策略、在你的架构设计、或者在那段写得稀碎的业务代码里。** 哪怕你用最快的框架写了一堆烂 SQL，或者完全没做负载均衡，那你的系统照样卡得动不了。
+
+所以我现在选型，**“好维护、好扩展、生态稳”** 的优先级，永远排在“性能数据好看”之前。
+
+## 4. 适合自己的，才是最好的
+
+折腾了这么一大圈，我最大的体会就是：**技术栈没有绝对的好坏，只有此时此刻它适不适合你。**
+
+如果你只是写个简单的小工具，那怎么轻量怎么来，怎么爽怎么写。但如果你是想做一个需要长期维护、或者要交给别人一起协作的项目，那么工程化、标准化、确定性，才是你真正的救命稻草。
+
+哪怕有人吐槽这些框架“笨重”或者“不如某某某优雅”，但我写得顺手、维护得省心、AI 辅助得给力，这就足够了。技术选型不应该是一场军备竞赛，而应该是为你的业务找一套最稳固的底座。

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

@@ -1,4 +1,4 @@
-# 我为什么放弃 Next.js，选择 Nuxt.js 和 NestJS
+# 从追逐流行到回归工程：我技术选型的“降噪”思考
 
 过去几年里，我尝试过很多 Node.js 框架和前端技术栈：**Express、Koa、Fastify、Hono.js**，以及前端的 **Next.js**。这些框架和工具都有各自的优点：轻量、灵活、性能好，社区里也有不少人推荐。然而，随着项目的深入，我逐渐发现了一个事实：**简单、快速实现、自己熟悉、生态完善、可扩展性好**，才是最重要的，而不是盲目追逐“最流行”或“性能最高”的框架。