内容摘要：去年帮朋友搭一个内部工单系统，后端选了Node.js加Express，数据库用SQLite。原因很简单：用户不超过20人，并发几乎为零，没必要上Spring Boot或Django那种重型框架。结果跑

去年帮朋友搭一个内部工单系统，后端后端选了Node.js加Express，网站数据库用SQLite。后端原因很简单：用户不超过20人，网站并发几乎为零，后端没必要上Spring Boot或Django那种重型框架。网站结果跑了半年，后端稳得很，网站连重启都没几次。后端这事让我重新想了一个问题——后端网站到底该选什么技术栈？网站多数时候答案不是“最好的”，而是后端“最不碍事的”。

很多人一上来就问：后端用Java还是网站Go还是Python？这问题本身就偏了。语言只是后端入口，真正决定后端长什么样的网站，是后端业务的数据流和访问模式。拿一个博客站举例。文章读多写少，缓存策略比语言选择重要十倍。你拿Go写一个每篇文章都查三次数据库的接口，照样慢；用PHP配一层Redis，反而快得离谱。

一个真实的小型后端结构

我拿之前写过的一个书签管理服务来说。功能就三个：用户注册登录、保存书签、按标签筛选。后端代码不到800行，目录结构是这样的：

server/ app.js routes/ auth.js bookmarks.js db/ schema.sql index.js middleware/ auth.js 

没有service层，没有DTO，没有依赖注入容器。路由里直接调数据库。听起来很“脏”，但改一个字段从改表到接口返回，五分钟搞定。这种项目上六边形架构就是自残。后端网站的第一原则：结构复杂度匹配业务复杂度，多一层抽象就多一层维护成本。

接口设计里的坑

我见过不少后端把RESTful当成宗教。比如一个“获取当前用户信息”的接口，非要设计成GET /api/v1/users/{ id}，然后前端还得先知道自己的id。其实直接GET /api/me，从session或token里取身份，少一次参数传递，也少一个越权漏洞。REST是风格，不是法律。后端网站是给人用的，不是给论文评委看的。

另一个常见问题是状态码滥用。用户没登录返回200，body里写{ "code": 401}。前端每个请求都要解析body判断成功失败。正确的做法是401就401，403就403，前端拦截器统一处理。我接手过一个项目，后端所有接口都返回200，错误信息藏在msg字段里，前端写了三十个if-else。这种设计省了后端五分钟，坑了前端五天。

数据库不是越“高级”越好

SQLite被低估了。一个日活几千的网站，SQLite完全扛得住。它没有网络层，没有连接池配置，备份就是复制文件。我有个side project用SQLite跑了两年，数据量到40万行，查询带索引依然在10ms内。什么时候换PostgreSQL？当你需要并发写入、需要JSONB字段查询、需要全文检索的时候。不是“因为大家都用”。

ORM也是。Prisma、TypeORM、Sequelize，用好了省事，用不好就是性能黑洞。我倾向于手写SQL加一个轻量查询构建器，比如Knex。至少我知道每条查询最终长什么样。ORM生成的N+1查询，在开发环境数据少时看不出来，上线后直接拖垮数据库。

部署别想太复杂

一个后端网站，如果日请求量不到十万，一台2核4G的VPS足够。Nginx做反向代理，PM2或systemd管进程，Certbot自动续HTTPS证书。整套下来每月不到五十块。Kubernetes、服务网格、分布式追踪，这些是给几百个微服务准备的。你的工单系统不需要。我见过一个三人团队花两个月搭K8s集群，结果业务代码只写了三天。后端网站的价值在业务逻辑，不在基础设施的复杂度。

后端网站的例子千千万，但核心就一句话：让数据可靠地进出，让接口清晰地说话，让运维简单到不用专门雇人。剩下的都是锦上添花，搞不好就是画蛇添足。