From 4a4fd423b24fed3b729f64187e13ab4c76c9a7fb Mon Sep 17 00:00:00 2001 From: joyzhao Date: Thu, 8 Jan 2026 17:30:49 +0800 Subject: [PATCH] =?UTF-8?q?refactor:=20=E8=B0=83=E6=95=B4=E8=AF=AD?= =?UTF-8?q?=E8=A8=80=E7=B1=BB=E5=9E=8B=E5=AF=BC=E5=85=A5=E9=A1=BA=E5=BA=8F?= =?UTF-8?q?=EF=BC=8C=E5=88=A0=E9=99=A4=E6=97=A0=E7=94=A8=E7=9A=84=E4=B8=B4?= =?UTF-8?q?=E6=97=B6=E5=8D=9A=E5=AE=A2=E6=96=87=E7=AB=A0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- src/pages/zh/blog/index.astro | 3 +- src/pages/zh/blog/posts/temp copy.md | 47 ---------------------------- 2 files changed, 2 insertions(+), 48 deletions(-) delete mode 100644 src/pages/zh/blog/posts/temp copy.md diff --git a/src/pages/zh/blog/index.astro b/src/pages/zh/blog/index.astro index ae06efb..344ea2b 100644 --- a/src/pages/zh/blog/index.astro +++ b/src/pages/zh/blog/index.astro @@ -5,7 +5,8 @@ import CategoryCard from '../../../components/blog/CategoryCard.astro'; import TagCard from '../../../components/blog/TagCard.astro'; import Container from '../../../components/ui/Container'; import { type BlogPost } from '@/types'; -import { type Lang, useTranslations } from '@/i18n/utils'; +import { useTranslations } from '@/i18n/utils'; +import { type Lang } from '@/types/i18n'; import { defaultLang } from '@/i18n/ui'; import { sortPostsByDate, extractCategories, extractTags } from '@/utils/blog-utils'; diff --git a/src/pages/zh/blog/posts/temp copy.md b/src/pages/zh/blog/posts/temp copy.md deleted file mode 100644 index 69a45c7..0000000 --- a/src/pages/zh/blog/posts/temp copy.md +++ /dev/null @@ -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 辅助得给力，这就足够了。技术选型不应该是一场军备竞赛，而应该是为你的业务找一套最稳固的底座。 \ No newline at end of file