晨阳
作为一个只实现了登录、注册、用户信息修改和座位云同步的个人小项目，数据库换了两次——从 MongDB 到 PostgreSQL，连后端框架也在半年内换了三次——从 Koa 到 Fastify，最后落在NestJS上。说起来有点“折腾”，但每一步都让这个简单的项目变得更好维护。
为啥折腾框架和数据库？
最初用 Koa+MongoDB，图的是 “快”。MongoDB 的文档结构存座位结构确实方便，Koa 搭个简单接口也快。但用着用着发现问题：
座位同步需要关联用户 ID，MongoDB 的关联查询总觉得别扭，查 “某用户的所有座位” 得写好几行代码。
Koa 的代码越堆越乱，登录校验和座位查询的逻辑混在一个文件里，改个密码规则都得小心翼翼。
试了阵子 Fastify，速度快了点，但代码组织还是没章法，数据库那块的别扭劲儿也没解决。最后干脆一步到位，框架换 NestJS，数据库也换成 PostgreSQL。
用 Koa：快是快，乱也是真的
一开始选 Koa，纯粹是图它轻量。就这几个基础功能，几行代码搭个服务器，配个路由中间件，连数据库写几句 SQL，一天就跑通了核心流程。
但问题也来得快。用户登录的 token 验证、座位同步的数据库操作、用户信息修改的参数校验，全堆在几个路由文件里。某天想改个“密码长度限制”，得在注册和修改信息两个地方各改一遍，调试时绕了半天。就我一个人开发，代码却乱得像堆杂物，找个函数得全局搜索。
试 Fastify：性能过剩，规范不足
换Fastify是想试试“更现代”的框架。它的响应速度确实快，座位同步时前端刷新更及时；自带的schema校验也方便，定义个用户信息的规则，前端传错格式直接拦截，省了些 if 判断。
但对我的小项目来说，“快”有点多余——总共没几个用户，Koa 和 Fastify 的速度差异根本感知不到。更麻烦的是，它没给我一个清晰的代码组织方式，业务逻辑还是散着的。比如座位同步要先查用户权限，这段代码既在登录校验里有，又在同步接口里重复写，改一次得动两个地方，纯属给自己挖坑，要是将校验代码抽出的话又显得结构不太清晰。
定 NestJS：规矩立好了，省心
最后换NestJS，是被“模块化”打动了。我把项目拆成了三个小模块：
UserModule：管登录、注册、信息修改，验证逻辑和数据库操作分开，改密码规则只动一个地方。
SeatModule：专门处理座位同步，坐标计算和存储逻辑全在这里，清晰得很。
AuthModule：放一些通用的工具，比如 token 生成、参数校验，哪里需要就引入。
TypeScript 的类型定义也帮了大忙，座位行列数必须是数字、用户名不能为空，这些约束写进代码里，写代码过程中不规范的话，IDE直接报错，比自己记规则靠谱多了。
现在加功能特别顺，比如想给座位同步加个“历史记录”，直接在 SeatModule 里加个服务和接口，半小时搞定。哪怕隔阵子没碰项目，看一眼模块结构，马上就能上手。
小结：小项目也需要“规矩”
对只有几个功能的个人项目来说，框架不用追求“高大上”，但得用着省心。Koa 快却乱，Fastify 炫却散，NestJS 的规矩刚好适合我——不用自己琢磨代码该放哪，框架帮你把架子搭好，剩下的精力只用专注在功能上。这种“不用和自己写的代码打架”的感觉，对 solo 开发者来说，太重要了。
