feat: 更新全栈开发者选型忏悔录文章，添加元数据和描述信息

src/pages/blog/posts/2026010801.md

@@ -1,4 +1,15 @@
-# Stop Being Held Hostage by "Best Practices": Confessions of a Full-Stack Developer’s Tech Stack Struggles
+---
+layout: "@/layouts/BlogPostLayout.astro"
+title: "Stop Being Held Hostage by 'Best Practices': Confessions of a Full-Stack Developer's Tech Stack Struggles"
+description: "A full-stack developer's honest reflection on getting trapped by chasing 'best practices' while building a simple 30-endpoint project. This article explores the cognitive load of heavy frameworks, the Monorepo trap, and proposes a practical two-tier tech stack selection strategy."
+date: "2026-01-08"
+image: "https://images.unsplash.com/photo-1518770660439-4636190af475?q=80&w=1470&auto=format&fit=crop"
+tags: ["Tech Stack", "Full-Stack Development", "Framework Selection", "Best Practices", "Developer Experience"]
+tagId: ["tech-stack", "fullstack", "framework", "best-practices", "developer-experience"]
+category: "Technology"
+categoryId: "technology"
+readTime: "6 min read"
+---
 
 > **Foreword:**
 > I am a developer who transitioned from Frontend to Node.js Full-Stack. This article is simply a summary of my recent experiences and reflections while developing a project. Given my limited knowledge and perspective, the views expressed here may not be universally "correct" or represent industry standards. This is just a personal debrief after stepping into countless pitfalls, shared in the hope of exchanging ideas with the community and providing a reference for those facing similar dilemmas. If there are any inaccuracies, please feel free to correct me in the comments.
@@ -40,7 +51,7 @@ Code that should have taken one minute to write took ten because I was busy deal
 At the end of all this exhaustion, I reflected: Is there a perfect framework? The answer is no; there is only the *suitable* one. Consequently, I have simplified my selection logic into two tiers:
 
 * **Tier A: Rapid Validation (MVP / Personal Projects)**
-    **Stack: Nuxt All-in-One.** Don't even separate the frontend and backend. Nuxt’s built-in Server API (Nitro) is more than enough for small to medium businesses. Types are naturally shared, and there are no CORS or build-sync headaches. At the validation stage, **"Speed" is a hundred times more important than "Elegance."**
+    **Stack: Nuxt All-in-One.** Don't even separate the frontend and backend. Nuxt's built-in Server API (Nitro) is more than enough for small to medium businesses. Types are naturally shared, and there are no CORS or build-sync headaches. At the validation stage, **"Speed" is a hundred times more important than "Elegance."**
 
 * **Tier B: Complex Business (Large Projects / Team Collaboration)**
     **Stack: Nuxt + NestJS (Decoupled) + Monorepo.** Only when the business is complex enough to require strict layering, Dependency Injection (DI) for decoupling, and multi-person collaboration will I endure the "ceremony" and management costs of these heavy frameworks.
@@ -64,4 +75,4 @@ This "Convention over Configuration" full-stack framework seems to balance devel
 
 **The best tech stack is the one that allows you to forget the technology itself and focus on creating value.**
 
-Finally, the solutions I've summarized are only what fits my personal habits and current understanding; they may not work for everyone. Everyone's business scenarios and technical backgrounds are different. **If you have better ideas or different solutions, I’d love to hear them in the comments so I can learn from you too.** If I've missed anything, please let me know. Thanks in advance!
+Finally, the solutions I've summarized are only what fits my personal habits and current understanding; they may not work for everyone. Everyone's business scenarios and technical backgrounds are different. **If you have better ideas or different solutions, I'd love to hear them in the comments so I can learn from you too.** If I've missed anything, please let me know. Thanks in advance!

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

@@ -1,4 +1,15 @@
-# 别再被“最佳实践”绑架了：一个全栈开发者的选型忏悔录
+---
+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 全栈的开发者。这篇文章只是基于我近期开发项目时的一些真实经历和感悟。由于个人知识储备和认知水平有限，文中的观点不一定正确，更不代表行业标准。这仅仅是我在踩了无数坑后的一点自我总结，发出来是希望能和大家交流，也给有类似纠结的朋友提供一个参考。如有谬误，欢迎评论区指正。
@@ -9,15 +20,15 @@
 
 ## 1. 追逐流行，是内耗的开始
 
-我最开始随大流选了 **Next.js + NestJS + shadcn-ui**。我想着，既然大家都说这是“全栈天花板”，那选它准没错。结果现实反手就给了我一巴掌。
+我最开始随大流选了 **Next.js + NestJS + shadcn-ui**。我想着，既然大家都说这是"全栈天花板"，那选它准没错。结果现实反手就给了我一巴掌。
 
-在 Next.js 里，为了选一个数据处理和状态管理方案（SWR 还是 Zustand？），我硬生生磨掉了一周。好不容易开工了，又被服务端渲染（SSR）带来的复杂度搞得头大——频繁定义 `"use client"` 指令、处理莫名其妙的“状态水合（Hydration）”报错、还要手动管理状态依赖并优化一堆回调函数。
+在 Next.js 里，为了选一个数据处理和状态管理方案（SWR 还是 Zustand？），我硬生生磨掉了一周。好不容易开工了，又被服务端渲染（SSR）带来的复杂度搞得头大——频繁定义 `"use client"` 指令、处理莫名其妙的"状态水合（Hydration）"报错、还要手动管理状态依赖并优化一堆回调函数。
 
 我当时就在想：**我只是想写个简单的业务逻辑，为什么要花 80% 的精力去处理框架带来的麻烦？**
 
 ## 2. 框架重一点，心智负担就大一点
 
-后来前端切到了 Nuxt 确实顺手了些，但后端我依然守着 **NestJS**，追求所谓的“大而全”。
+后来前端切到了 Nuxt 确实顺手了些，但后端我依然守着 **NestJS**，追求所谓的"大而全"。
 
 但我一共才 30 个接口，业务逻辑极其简单。但在 NestJS 里，我不得不写 Controller、Service、Module、DTO……代码量翻了几倍。更崩溃的是 **ESM 的兼容问题**，NestJS 依然守着 CommonJS 的旧梦，导致我想用一些最新的 ESM 库时，各种配置文件报错。为了跑通一个简单的 TypeScript Worker 线程，我还得自己去研究 ESM 编译器。
 
@@ -25,7 +36,7 @@
 
 **我感觉自己不是在开发产品，我是在修一辆零件互不兼容的破拖拉机。**
 
-## 3. Monorepo：独立开发者的“温柔陷阱”
+## 3. Monorepo：独立开发者的"温柔陷阱"
 
 为了追求代码复用，我还折腾了 **Monorepo**。
 
@@ -33,17 +44,17 @@
 
 原本一分钟写完的代码，因为要处理跨包调试、TS 类型同步和打包逻辑，硬生生变成了十分钟。
 
-**我悟了：Monorepo 是为了解决“组织协作”的，对于独立开发者，它往往是效率杀手。**
+**我悟了：Monorepo 是为了解决"组织协作"的，对于独立开发者，它往往是效率杀手。**
 
-## 4. 回归务实：我的“两套方案”
+## 4. 回归务实：我的"两套方案"
 
 在折腾的终点，我反思：有没有完美的框架？结论是没有，只有适合的。于是，我把我的选型逻辑简化成了两套：
 
 * **方案 A：快速验证（MVP / 个人项目）**
-    **技术栈：Nuxt 一把梭。** 别分前后端了，Nuxt 的内置 Server API（Nitro）足够处理中小业务。类型天然共享，没有跨域烦恼。在验证阶段，**“快”比“优雅”重要一百倍。**
+    **技术栈：Nuxt 一把梭。** 别分前后端了，Nuxt 的内置 Server API（Nitro）足够处理中小业务。类型天然共享，没有跨域烦恼。在验证阶段，**"快"比"优雅"重要一百倍。**
 
 * **方案 B：复杂业务（大型项目 / 团队协作）**
-    **技术栈：Nuxt + NestJS 分离 + Monorepo。** 当业务复杂到需要严格的分层、需要依赖注入（DI）解耦、需要多人协作时，才去忍受这种“重”框架带来的仪式感和管理成本。
+    **技术栈：Nuxt + NestJS 分离 + Monorepo。** 当业务复杂到需要严格的分层、需要依赖注入（DI）解耦、需要多人协作时，才去忍受这种"重"框架带来的仪式感和管理成本。
 
 ## 5. 题外话：意外发现的新希望 AdonisJS
 
@@ -51,14 +62,14 @@
 
 我简单看了一下它的设计理念，感觉它似乎精准地击中了我上述遇到的很多痛点：它原生支持 ESM、内置了强大的 ORM 和 Auth 方案、不需要像 NestJS 那样去折腾各种复杂的适配器来搞定自动化的 Swagger 文档生成。
 
-这种“约定优于配置”的全栈框架，似乎能平衡开发效率与工程质量。我准备在接下来的项目中实际试用一下，如果确实好用，有了心得后再专门写篇文章分享给大家。
+这种"约定优于配置"的全栈框架，似乎能平衡开发效率与工程质量。我准备在接下来的项目中实际试用一下，如果确实好用，有了心得后再专门写篇文章分享给大家。
 
 ## 6. 总结：给开发者的一点建议
 
 1.  **没有完美的框架，只有最适合当下的。** 不要指望任何一个明星框架能解决所有问题，它们都有代价。
 2.  **不要在独立开发或工作中轻易尝试自己不熟悉的技术栈。** 除非你真的有大把的时间和精力去踩坑。你以为在学新技术，其实你是在浪费产品的寿命。
-3.  **警惕“大厂最佳实践”。** 很多在大公司里解决痛点的工具（如 Monorepo、过度分层），在个人项目里往往只会制造痛点。
+3.  **警惕"大厂最佳实践"。** 很多在大公司里解决痛点的工具（如 Monorepo、过度分层），在个人项目里往往只会制造痛点。
-4.  **熟悉度大于先进性。** 哪怕一个框架被说成是“老古董”，只要你用得顺手、能让你早点下班，它就是你的银弹。
+4.  **熟悉度大于先进性。** 哪怕一个框架被说成是"老古董"，只要你用得顺手、能让你早点下班，它就是你的银弹。
 
 **最好的技术栈，是那个能让你忘记技术本身，而专注于创造价值的工具。**