选技术栈最容易踩的坑，是拿"最流行"当标准。流行的东西通常没错，但它不一定匹配你的约束。这篇说清这套组合是怎么定下来的 —— 重点不是"它多好"，而是"它为什么匹配我这边的条件"。
一、先列约束，再挑技术
动手前只有三条约束，但它们决定了后面所有取舍：
一个人维护：没有团队分工，出问题得自己查；
要长期改：不是一次性项目，几个月后还会回来加内容、改样式；
预算和精力有限：不想在环境、构建、部署这些环节上反复折腾。
把这三条摆出来，"要不要上框架""要不要拆微服务"这类问题其实就不用纠结了。
二、前端：为什么不上框架
这是最容易被质疑的一点。现在的默认答案是 React / Vue，但对我这个场景，它们的收益和成本不匹配：
这个站是内容型的：页面结构相对固定，交互集中在少数几个地方；
上框架就要上构建工具链：多一层依赖，就多一层排错面；
SEO 是硬需求：内容站要靠搜索引擎带流量，服务端直接输出完整 HTML 最省事。
所以最后是 HTML + Tailwind + 原生 JavaScript：改完刷新就能看效果，不用等打包；页面里需要交互的地方，原生写也够用。
代价也说清楚：交互一旦复杂到某个程度，原生 JavaScript 会变得难维护 —— 这一点我认，到这个阶段就该换方案，而不是硬撑。
三、后端：为什么是 FastAPI
后端选型的重点是"改起来快"和"少写胶水代码"。FastAPI 在这两点上比较合手：
类型标注就是校验：用 Pydantic 定义请求/响应模型，参数校验和错误提示不用自己写；
自带接口文档：写完接口就有可交互的文档页，联调时省掉很多来回对齐；
Python 生态：数据处理、脚本、自动化都顺手 —— 一个人做全栈时这点很重要。
也对比过别的：Node 生态大，但我这边 Python 更熟；Java / Go 稳，对个人站来说是重型装备；PHP 部署简单，但类型和工具链的体验我不太想回头。
四、数据库：为什么是 MySQL
内容型站点的数据结构天然是关系型的：文章属于某个分组、分组有层级、标签和内容多对多。MySQL 的匹配度很高：
关系、事务、约束都齐：刚好对应"内容 + 分组 + 标签"这类结构；
生态最成熟：遇到问题基本都能搜到答案，工具链也全；
和服务器默认环境兼容：部署时少一步折腾。
也考虑过：SQLite 单文件、零配置，本地开发很舒服，但作为线上主库，多连接和远程管理的体验一般；MongoDB 灵活，可这里的数据结构并不需要这种灵活 —— 用了反而少一层约束。
五、部署：够用就好
一台服务器 + Nginx 反向代理 + HTTPS。Nginx 同时承担静态资源和接口转发，页面、附件、接口都走同一个入口，配置一次基本不用动。
部署走脚本而不是手动传文件：少出低级错误，也方便回滚。
六、这套组合的边界
说清楚它不适合什么，比列优点更有用：
页面交互很重：比如复杂后台、实时协作 —— 建议直接上框架；
需要横向扩容、高并发：这套单机配置不够，得往前加缓存和队列；
多人协作、要统一规范：前端构建链和类型系统值得补上。
结论
选型最实用的判断标准不是"哪个最好"，而是"哪一组能让当下这个约束下的项目，持续做下去"。
这套组合没什么亮点，但它让一个人能长期维护 —— 对这个规模的项目，这就是最重要的指标。
感受/反思
选型这件事给我的教训是：不要拿"流不流行"当标准，要拿"我的约束是什么"当标准。同一套技术放在不同的人、不同的项目上，结论可能完全相反。
还有一点：把"不适合什么"写下来，比列优点更有用 —— 它能提醒你什么时候该换方案，而不是等到硬撑不下去才发现。
相关推荐
专题：全栈开发：从 0 到上线 —— 会把这里提到的每一块逐个展开。后续还会单独写部署脚本怎么写、Nginx 配置怎么做。