我见过不少小团队踩同一个坑：项目刚起步，技术选型就开始追新——这块用Serverless Functions，那块接托管数据库，认证用第三方服务，队列再接一个托管平台。每个单独看都挺合理，合在一起就是噩梦。
等到真正要排查一个bug，你得同时打开四五个控制台，每个平台的日志格式不一样，权限体系各自独立，环境变量散落在不同地方。流量一涨，账单从各个方向同时膨胀，而且你很难搞清楚钱到底花在哪里。
收敛才是小团队的正确姿势
对资源有限的小团队来说，系统越集中，认知负担越低，出问题的时候排查路径越短。
一套我觉得足够实用的架构长这样：
后端用Hono——轻量、性能好、TypeScript原生支持，跑在Docker里，不依赖任何特定平台。数据库用PostgreSQL，自己管，数据在自己手里。反向代理用Caddy，自动HTTPS，配置比Nginx简单很多，新手也能上手。整套东西打包部署到Hetzner的VPS上，2核4GB的机器月费不到10欧，足够支撑大多数中小业务的早期阶段。
数据备份放Cloudflare R2，按量计费，存储成本极低，还不需要额外维护一套备份服务。
前端可以用TanStack Start，边缘逻辑部署到Cloudflare Workers处理加速和轻量请求。这样核心计算仍然在你可控的服务器上，边缘层只做它最擅长的事。
整套跑下来，一个月十几美元基本覆盖，结构清晰，每一层出了问题都知道去哪里找。
Serverless的问题不是技术，是边界
Serverless本身没有问题，它有它适合的场景：极轻量的事件触发任务、流量波动极大的场景、真正不需要状态管理的纯函数计算。
但它不适合被当成"默认架构"用在功能持续迭代的业务产品上。原因很具体：
执行时间有限制，复杂任务需要拆分或绕路。冷启动在某些场景下影响用户体验，而且你对它的控制权很有限。连接池管理是个真实的痛点，数据库连接在Serverless环境下需要额外处理，否则很容易耗尽连接数。最麻烦的是，当架构开始为了适配平台的限制而变形，技术债就已经在悄悄累积了。
更现实的问题是成本。早期流量小的时候Serverless便宜，看起来比VPS划算。但调用次数、存储、带宽、数据库连接，每一项单独收费，等到项目进入增长阶段，账单增长的速度往往比你预期的快得多，而且很难提前预测。
一个具体的部署参考
如果你想按这个思路搭一套，大致步骤是这样的：
在Hetzner买一台CX22（2核4GB，约€4.5/月），装Ubuntu 22.04。
安装Docker和Docker Compose：
curl -fsSL https://get.docker.com | sh
apt install docker-compose-plugin -y
一个基础的docker-compose.yml把Hono后端、PostgreSQL、Caddy组合起来：
version: '3.8'
services:
app:
image: your-hono-app
restart: always
environment:
DATABASE_URL: postgresql://user:password@db:5432/mydb
depends_on:
- db
db:
image: postgres:16
restart: always
environment:
POSTGRES_USER: user
POSTGRES_PASSWORD: password
POSTGRES_DB: mydb
volumes:
- pg_data:/var/lib/postgresql/data
caddy:
image: caddy:latest
restart: always
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile
- caddy_data:/data
volumes:
pg_data:
caddy_data:
Caddyfile配置反向代理和自动HTTPS只需要几行：
yourdomain.com {
reverse_proxy app:3000
}
Caddy会自动申请和续期Let's Encrypt证书，不需要手动配置。
数据备份用rclone连接Cloudflare R2，定时任务推送：
0 3 * * * pg_dump mydb | gzip | rclone rcat r2:backup/db-$(date +%Y%m%d).sql.gz
整个架构从零搭起来，有Docker基础的话两三个小时可以跑通。
技术决策的本质
技术选型不是炫技，是服务业务。
对于追求稳定现金流、需要持续迭代功能的小团队来说，可控、集中、依赖少的架构往往比"最现代"的那套更有生命力。出了问题知道去哪里找，扩展的时候知道升级哪一层，账单增长和业务增长是线性关系而不是指数关系。
用到的服务越少，系统越清晰。能长期跑下去的项目，往往不是技术栈最潮的那个，而是最克制的那个。