过度设计猎手

格式：给你两个架构方案（一个简单、一个复杂），判断哪个更合适。

场景 1：个人博客

方案 A（简单）：

Next.js 静态生成 → Vercel 部署
Markdown 文件存内容 → Git 做版本管理

方案 B（复杂）：

Next.js + 微服务架构
- 文章服务（Node.js + PostgreSQL）
- 评论服务（Node.js + MongoDB）
- 搜索服务（Elasticsearch）
- 缓存层（Redis）
- 消息队列（RabbitMQ）
- Kubernetes 编排
- 监控服务（Prometheus + Grafana）

正确答案方向：方案 A 对99%的个人博客是正确选择。选方案 B 等于"为炸鸡蛋启动核反应堆"。如果你不确定需不需要，那你不需要。

场景 2：待办事项应用（自己用）

• 方案 A：SQLite + 单文件应用
• 方案 B：PostgreSQL + Redis + GraphQL + WebSocket 实时同步

场景 3：公司内部工具（10人使用）

• 方案 A：Supabase + Next.js，简单认证
• 方案 B：微服务 + Kafka + 自建认证系统 + 零信任网络

场景 4：MVP 原型（验证想法）

• 方案 A：Supabase + Next.js，2天上线
• 方案 B：自建后端 + 自建认证 + Docker + CI/CD，2周上线

场景 5：个人作品集网站

• 方案 A：Astro 静态站点 + Vercel
• 方案 B：Next.js + Headless CMS + CDN + 数据库

评判标准：

• 你能说出为什么简单方案更好吗？
• 你能说出什么情况下复杂方案才合理吗？
• 你有没有掉入"技术炫耀"的陷阱？

核心法则：YAGNI — You Ain't Gonna Need It（你不会需要它的）