---
layout: "@/layouts/BlogPostLayout.astro"
title: "折腾来折腾去，到底是为了什么？ 一个全栈开发者的工程化反思"
description: "关于技术选型困境的真实反思。一个开发者在'最佳实践'诱惑下的挣扎与醒悟：技术是工具不是目的，如何避免过度工程化，找到真正适合自己的方案。"
date: "2026-01-08"
image: "https://images.unsplash.com/photo-1518770660439-4636190af475?q=80&w=1470&auto=format&fit=crop"
tags: ["全栈", "工程化", "开发感悟"]
tagId: ["fullstack", "engineering", "development-reflection"]
category: "工程化"
categoryId: "engineering"
readTime: "8 min read"
---

> 记录一下最近做项目选型时，那些真能把人搞崩溃的细节。是我自己跟自己较劲，来回折腾后的一点总结。不一定对，但每句话都是花时间踩坑换来的。

最近想做个书签小工具，一共也就 30 来个接口，结果在“用什么技术”这个问题上，我纠结了快一个月。感觉就像在技术的林子里瞎转，看见哪儿有光就往哪儿跑，最后发现每个亮光后面都是个坑。

## 第一步：跟着“技术主流”走，结果浑身难受

事情是这样的，我想自己做点小产品。工作上我一直用 Vue，很顺手。但网上看了一圈，大家都在说 **“Next.js + React + shadcn-ui”** 才是现在做东西的正道。生态好、组件多、未来可期。

我一想，不能老用自己熟悉的，换个口味吧。于是放下 Vue，开始用 React。结果一上来就懵了：**选择太多了，不知道该用哪个。**

根本不是简单的二选一，而是每个地方都有好几个选择，我大部分时间都在搜资料、看对比、做选择：

* 数据请求是用 **SWR** 还是 **TanStack Query**？
* 全局状态是用 **Zustand** 还是继续用 **Redux**、**Jotai**？
* 服务端和客户端数据怎么同步？在这个边界上我反复拉扯。

感觉我的主要工作不是写代码，而是在研究“该用什么写代码”。更烦的是那些莫名其妙的 **“水合错误（Hydration Error）”**，写个页面一刷新就报错，然后就得花时间找哪里对不上。

最心累的是到处都要加 `“use client”`。我感觉自己不是在写功能，是在给代码打标签。每加一行我就在想：**“如果这么多东西最终都要在客户端跑，那我为啥要选这个把前后端拆这么碎、心智负担这么重的框架？”**

## 第二步：用回顺手的，又怕自己落伍了

我回到熟悉的 Vue 生态，用了 Nuxt。果然舒服多了，开发效率起飞。

但安静没两天，看网上还是到处在夸 Next.js 生态好。心里又开始想：**“我是不是选错了？会不会错过什么？”** 不信邪，又回头去试了几天 Next.js。结果，那些熟悉的、琐碎的麻烦全回来了。

这回我彻底认了：**技术没有绝对的好坏，只有合不合适。我相信自己用着舒服的感觉，这种“手感”骗不了人。**

## 第三步：总想“搞得专业点”，结果给自己挖坑

前端定了，该写后端了。我选了大家说最工程化的 **NestJS**。为了显得更专业，又强行上了 **Monorepo**。这下彻底麻烦了，我亲手给自己搞了个大工程：

* **开发摩擦力极大：** 在 Monorepo 里改个公共的枚举值或类型，要重新构建、等 Workspace 同步、重启服务。原本 10 秒钟的事，现在要等 1 分钟。
* **兼容性地狱：** NestJS 守着 CommonJS 的旧梦，我想用个纯 ESM 的库或者跑个 TypeScript Worker 线程，配置文件的报错能让你怀疑人生，得花大把时间研究编译器路径。
* **仪式感的内耗：** 就 30 个接口，要写一堆 Controller、Service、Module、DTO。代码量翻了几倍，但核心逻辑一点没变。
* **Swagger 的折磨：** 我想用 Zod 做验证，Swagger 却只认装饰器（class-validator）。为了那张 API 文档，我得被迫维护两份几乎一样的数据定义，手动同步两份 DTO 的痛苦只有写过的人才懂。

**我用一个可能永远用不上的“大团队优势”，换来了眼前的“低效率”。** 我想要的是快点做出来，但重框架让我优先考虑怎么让代码“更好维护”，这完全本末倒置了。

## 第四步：换个轻量的，反而更不会写了

我决定不用这些重框架了，选了 **Fastify**，想着以后不行还能换回去。但我发现，问题不只是“重”，而是 **“自由带来的恐慌”**。

Fastify 很自由，但对我这种习惯了某种结构的人来说，自由反而成了压力：

* “代码该放哪？”
* “这个功能怎么组织成插件？”
* 日志、队列、鉴权这些在 NestJS 里现成的，现在都要自己找库、集成、调试。

我嫌重框架规矩多，但真给自由了，我又不知道该怎么用了。我从复杂的流程里出来，又掉进了“什么都要自己找”的坑。

**我终于明白：我选的那些框架，都基于我自己的知识惯性。我嫌重框架规矩多，但内心又想要固定结构，这种心态本身就是撕裂的。**

## 终于想明白：技术是拿来用的，不是拿来供着的

又一个加班到很晚的深夜，我对着屏幕问自己：**我折腾这么久，到底图啥？不就是想快点做出这个小工具吗？**

一下子通透了。我之前一直在用“大团队长期维护”的标准，来要求我这个“个人快速项目”。这就像为了去隔壁超市买菜，非要先修一条八车道的高速公路。

我给自己定了个简单的规矩：

* **做原型、小工具、简单应用**：直接用 **Nuxt 一把梭**。前后端在一个包里写，类型天然同步，没有跨域，没有同步内耗。目标就是快，能跑起来比什么都强。
* **复杂系统、多人协作、长期维护**：再考虑 **Nuxt + NestJS + Monorepo**。这时候复杂点能接受，因为确实需要架构支撑。

## 顺便提一句：看到个新选择

折腾的时候注意到了 **AdonisJS**，有人说是 Node.js 里的 Laravel。简单看了看，它好像正好平衡了我的纠结：有我要的固定结构（ORM、Auth 都有），又是现代的风格，原生支持 ESM。下次可以试试。

## 最后说几句

1. **别盲目追技术热点**：适合别人的不一定适合你。
2. **相信自己用着顺手的感觉**：这比流行趋势重要得多。
3. **先做出来再优化**：对于个人项目，跑不起来的架构就是一堆废纸。
4. **警惕“配置内耗”**：如果配置时间比写代码还长，就该换工具了。

这些就是我折腾一圈的想法。**我的做法可能不对，甚至挺笨的。** 所以想听听你们怎么看。**你们有没有类似的问题？最后怎么解决的？** 欢迎在评论区聊聊，让我也学习一下。