refactor: 调整语言类型导入顺序，删除无用的临时博客文章

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

@@ -1,47 +0,0 @@
-# 技术选型这件小事：为什么我不再迷信“轻量”和“流行”了？
-
-最近在折腾新项目，又经历了一轮技术栈选型的纠结。
-
-说实话，过去几年我也算是个“追风少年”。从经典的 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 辅助得给力，这就足够了。技术选型不应该是一场军备竞赛，而应该是为你的业务找一套最稳固的底座。