系统选型的权衡笔记：够用比完美更重要

做一个能上线的个人博客，你会不断遇到选型问题：单体还是拆分、ORM 还是手写 SQL、容器是否必须、统计要不要自建。真正耗时间的不是找「最佳答案」，而是承认每个选择都在拿某样东西换另一样东西，并写下你的取舍。这篇文章用博客场景把常见权衡摊开，帮助你减少无意义摇摆。

清晰的问题比时髦的方案重要

「我想做一个博客」不等于「我需要微服务」。当前问题如果是：写文章、展示、评论审核、小流量部署，那么单体后端 + 一个前端 + 一个数据库通常就够。过早拆服务，换来的是分布式事务、观测复杂度与部署负担，而不是可感知的收益。

同理，不必因为别处用了 Kubernetes 就上 Kubernetes。单机 Docker Compose + 宿主机 Nginx，对个人站是非常匹配的复杂度。技术雷达上的「推荐」针对的是特定规模；照搬到个人项目，常常是用运维时间换心理安慰。

先写下一句问题定义：用户是谁、核心路径是什么、约束是什么（一台云主机、一个人维护、周末才能发版）。选方案时反复对照这句，会被新名词带走的概率会小很多。

常见权衡轴

开发速度 vs 长期可控

ORM、脚手架、自动迁移能显著加快起步。代价是隐式查询、零值更新、结构漂移。早期可以用，但要知道何时收缰：热点路径看 SQL，生产迁移要可审查。完美的手写 SQL 从第一天铺开，也可能让你永远写不到上线。

运维简单 vs 能力边界

单机部署简单，备份、扩容、故障域都绑在一台机器上。对个人博客完全可接受；若以后要做高可用，再评估是否值得，而不是第一天假装自己是大型 SaaS。同机多站点则要求你把端口与入口约定做好——这是运维纪律，不是上集群的理由。

功能完整 vs 心智负担

评论、友链、标签、统计、RSS、全文搜索……每一项都合理，叠在一起会变成永远做不完的产品。先保证「写作—发布—阅读」主路径稳，再按真实痛点加功能。没有读者的搜索系统，是优雅的闲置代码。功能开关可以存在脑子里，但实现要排队。

安全默认值 vs 便利

默认管理员密码、仓库里的 JWT 密钥、对外开放的数据库端口，都是便利的短期解，长期是事故。个人项目被扫到并不罕见。便利只能留在本地开发，生产要显式配置。安全做「额外功能」时往往永远排不上；做默认值时反而能自然发生。

体验打磨 vs 上线闭环

主题动画、字体细节很加分，但若部署链路不稳、备份没有、后台发不了图，作品就还不是站点。建议把「可上线检查清单」置于视觉细节之前：域名、HTTPS、发布、备份、鉴权。观感问题可以迭代；数据丢失很难回放。

记录决策，避免反复摇摆

写一个很短的 ADR（Architecture Decision Record）就够：背景、决策、后果。例如：

• 决定前后端分离，因同源反代可同时服务公开站与后台
• 决定正文存 Markdown，因预览与内容可移植
• 决定容器不占 80/443，因同机多站点

三个月后你可能忘记为什么，但 ADR 会拦住无意义返工。「我们要不要换成某某框架」这种讨论，先翻 ADR：当初否决它的理由是否消失了？没消失就别换。

何时值得升级复杂度

出现这些信号再考虑加码：

• 单机备份与恢复已成为真实风险点
• 写入量让单库明显吃力，且优化索引后仍不足
• 多人协作发布，需要更细权限与审计
• 内容检索需求超出 LIKE 能承受的体验
• 你已经在为部署与排障付出不成比例的时间，且简化架构无法缓解

没出现这些信号时，优化代码清晰度与部署可靠性，通常比引入新组件更划算。升级复杂度应绑定可验证的收益：更短恢复时间、更低错误率、更好的写作体验——而不是「更现代」。

小结

系统设计的成熟度，不表现在你用了多少名词，而表现在你能否说清「为什么不选另一方案」。对博客而言，够用、可上线、可维护，已经是很高的完成度。把权衡写下来，下次动手时才不会被新鲜感带跑。够用不是将就，是把有限时间花在真正影响用户的路径上。