feat: 添加全栈开发者的选型忏悔录文章

src/pages/blog/posts/2026010801.md

@@ -0,0 +1,67 @@
+# Stop Being Held Hostage by "Best Practices": Confessions of a Full-Stack Developer’s Tech Stack Struggles
+
+> **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.
+
+Recently, I set out to build a small bookmark-style tool with only about 30 endpoints. I thought it would take two weeks; instead, I spent over a month just "wrestling" with the tech stack.
+
+I felt like a hunter lost in a technical fog: wherever I saw a light (a new tool or an "expert" opinion), I rushed toward it, only to find a deeper pit hidden behind every glow.
+
+## 1. Chasing Trends is the Start of Internal Friction
+
+I started by following the crowd and chose **Next.js + NestJS + shadcn-ui**. I thought, "Since everyone says this is the 'Full-Stack Gold Standard,' I can't go wrong." The reality, however, gave me a swift wake-up call.
+
+In Next.js, I wasted a whole week just deciding on a data-fetching and state management solution (SWR vs. Zustand?). Once I finally started, I was overwhelmed by the complexity of Server Components (RSC) vs. Client Components—constantly defining `"use client"`, fixing mysterious Hydration errors, and manually managing state dependencies while optimizing endless callback functions.
+
+I kept thinking: **I just want to write some simple business logic. Why am I spending 80% of my energy dealing with the overhead of the framework?**
+
+## 2. The Heavier the Framework, the Heavier the Cognitive Load
+
+Later, I switched the frontend to Nuxt, which was indeed smoother. But on the backend, I stuck with **NestJS**, chasing so-called "standardization" and "enterprise engineering."
+
+But I only had 30 endpoints. The logic was incredibly simple. In NestJS, I was forced to write Controllers, Services, Modules, DTOs... the amount of code tripled. Even worse was the **ESM compatibility issue**. NestJS still clings to the CommonJS dream, leading to constant configuration errors when I tried to use modern ESM-only libraries. To run a simple TypeScript Worker thread, I had to spend hours researching ESM compilers.
+
+The most frustrating part was **Swagger integration**. Most people prefer Zod for validation now, but Swagger is deeply coupled with the Class-Validator (Decorator) pattern. To get Swagger to recognize my Zod schemas and generate documentation, I had to manually write adapters and custom decorators.
+
+**I felt like I wasn't building a product; I was repairing a broken tractor with incompatible parts.**
+
+## 3. Monorepo: The "Tender Trap" for Indie Developers
+
+To pursue "code reuse," I even set up a **Monorepo**.
+
+I thought: *Front-end and back-end sharing types, enums, and error codes—how elegant!* The reality: trying to get a pure ESM frontend to share a package with a non-pure ESM backend plunged me into a bottomless pit of build configurations. Due to the NestJS environment, I had to compile and export the shared package every time I made a change, making frequent debugging and code modification an absolute nightmare.
+
+Code that should have taken one minute to write took ten because I was busy dealing with cross-package debugging, TS type synchronization, and build logic.
+
+**I finally realized: Monorepos are built to solve "organizational collaboration." For an indie developer, they are often a productivity killer.**
+
+## 4. Returning to Pragmatism: My "Two-Tier Strategy"
+
+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."**
+
+* **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.
+
+
+
+## 5. A Side Note: A New Hope in AdonisJS
+
+Just as I was summarizing these strategies, I stumbled upon a new framework—**AdonisJS**. Many developers describe it as the "Laravel of Node.js."
+
+I took a quick look at its philosophy, and it seems to precisely hit the pain points I mentioned: it supports ESM natively, has a powerful built-in ORM and Auth solution, and doesn't require jumping through hoops with custom adapters just to get automated Swagger documentation.
+
+This "Convention over Configuration" full-stack framework seems to balance development efficiency with engineering quality. I plan to use it in my next project and will share my findings once I have more experience.
+
+## 6. Conclusion: A Few Words of Advice
+
+1.  **There is no perfect framework, only the one that fits the moment.** Don't expect any "star" framework to solve all your problems; they all come with a cost.
+2.  **Do not easily try a tech stack you aren't familiar with during indie development or tight deadlines.** Unless you truly have the time and energy to burn. You think you're learning new tech, but you're actually burning your product's lifespan.
+3.  **Be wary of "Big Tech Best Practices."** Many tools built to solve pain points in giant corporations (like Monorepos or extreme layering) only create pain points in personal projects.
+4.  **Familiarity > Modernity.** Even if a framework is called "old school," if it's intuitive to you, lets you finish work early, and helps you write clearer logic with AI assistance, it is your "silver bullet."
+
+**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!

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

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