我的博客技术选型：从开发者视角重新看这套系统

做这个博客之前，我并没有把它当成一个单纯的“文章展示页”，而是把它视为一个会持续演进的个人网站系统。它不仅要能发布文章，还需要支持账号体系、资料页、评论互动、通知提醒、消息会话、后台管理，以及后续功能扩展。

所以这次技术选型的核心问题不是“哪个框架更流行”，而是：

在个人项目、长期维护、可持续迭代的前提下，什么方案能让我以尽可能低的复杂度，获得足够高的控制力和演进空间？

基于这个目标，我最终选择了以 Flask 为核心、结合 SQLAlchemy 生态、服务端渲染模板、Gunicorn 和 Nginx 的方案。

一、先定义问题：我到底在构建什么

从结果上看，这个项目是一个博客；但从系统职责上看，它已经不只是博客。

当前这个站点至少包含以下几个部分：

• 内容系统：文章发布、分类、标签、摘要、推荐

• 账户系统：登录、注册、个人资料、隐私设置

• 互动系统：点赞、收藏、评分、评论、回复

• 通知系统：互动提醒、回复提醒

• 消息系统：用户与管理员之间的会话

• 后台系统：文章、消息、版本、友链、关于页管理

• 部署系统：生产运行、HTTPS、静态资源缓存控制

也就是说，这不是一个纯静态博客，而是一个中小型 Web 应用。

所以技术选型必须满足几个前提：

1. 足够轻量，避免为了小站点背上过重框架负担。

2. 足够灵活，允许我按自己的业务结构组织代码。

3. 足够稳定，适合长期维护，而不是只适合快速 demo。

4. 足够可扩展，后续增加模块时不需要推翻重来。

5. 部署足够简单，能稳定运行在常规 Linux 服务器上。

二、为什么我选择 Flask

1. Flask 更适合“按需构建”的项目

Flask 的优势从来不是“大而全”，而是边界清晰。

它只提供 Web 应用最基础的能力：

• 路由

• 请求与响应

• 模板渲染

• 扩展接入能力

它不强制你接受一整套固定的后台、ORM、权限、目录结构和业务模型。

这对个人网站非常重要。

因为这个项目并不是一个完全标准化的信息发布系统。它里面有很多“刚好不标准”的部分，比如：

• 资料页和设置页是分开的，但数据又互相关联

• 通知中心和消息中心需要拆开

• 联系页既是公开留言入口，也是登录用户的会话页

• 后台并不是一个纯 CMS，而是一个围绕站点业务定制的管理台

在这种情况下，Flask 的自由度反而是优势。

2. Flask 很适合服务端渲染场景

这个站目前仍然是典型的服务端渲染结构，页面核心由后端直接输出 HTML。这种模式对于博客、资料页、后台管理页这类场景依然非常高效。

它有几个现实优势：

• 页面首屏直接可用

• SEO 友好

• 模板复用成本低

• 表单处理简单直接

• 不需要一开始就拆成前后端分离

对一个内容型站点来说，这比过早引入复杂前端工程更合适。

3. Flask 允许项目逐步长大

很多人会觉得 Flask 适合“小项目”，但我更认同一种说法：

Flask 适合从小项目开始，并通过工程组织把它发展成中型项目。

只要项目结构设计得当，比如采用：

• 应用工厂模式 create_app()

• Blueprint 模块拆分

• 模型、路由、模板、静态资源分层

• 公共工具函数和过滤器抽离

那么 Flask 完全可以承载一个中等复杂度的个人网站系统。

三、为什么我选择 SQLAlchemy 体系

1. 数据结构已经不是一张 Post 表那么简单

当博客只停留在“发文章”这个阶段时，很多方案都能做。但一旦加入用户体系和互动逻辑，数据模型会迅速复杂起来。

这个项目里实际涉及的核心实体包括：

• User

• Post

• Comment

• CommentReply

• UserInteraction

• Notification

• Message

• MessageReply

• Link

• Version

• AboutContent

它们之间有多种关系：

• 用户与通知：一对多

• 文章与评论：一对多

• 评论与回复：一对多

• 消息与回复：一对多

• 用户与互动记录：多维状态关联

这意味着 ORM 不能只是“能查数据”，而要能清楚表达模型关系、状态流转和后续扩展能力。

SQLAlchemy 在这方面足够成熟。

2. SQLAlchemy 在抽象和控制之间平衡得比较好

我选择 SQLAlchemy 的原因，不是因为它语法最短，而是因为它在工程上比较均衡：

• 简单场景下，模型定义和常规查询足够高效

• 复杂场景下，仍然保留了足够强的表达能力

• 当需要优化时，不会把你锁死在 ORM 黑盒里

这对博客这种“前期简单、后期会慢慢复杂化”的项目很重要。

前期你只会写：

• 文章列表

• 文章详情

• 评论查询

后期很快就会变成：

• 未读消息统计

• 会话状态切换

• 通知筛选

• 关联查询和展示性能优化

如果 ORM 太弱，后面会很难受；如果 ORM 太封闭，也会很难受。SQLAlchemy 恰好在这中间找到了一个平衡点。

3. 数据库切换成本更低

当前这类项目前期使用 SQLite 很合理：

• 简单

• 无额外运维成本

• 对个人项目友好

但系统如果继续增长，未来迁移到 PostgreSQL 也不是不可能。SQLAlchemy 提供的数据库抽象层，让这件事的迁移成本相对可控。

也就是说，前期可以轻部署，后期仍保留升级空间。

四、从工程实现上看，这套方案解决了什么

1. 我能按业务边界组织代码

这套项目结构的价值，不在于“看起来整齐”，而在于它能支持后续演进。

当前模块拆分大致是：

• main：前台页面和公共页面

• auth：认证和资料流

• settings：账户设置

• notifications：通知中心

• interaction：点赞、评论、评分等 API

• admin：后台管理

• models：核心数据模型

这样的划分和业务边界是基本一致的。

好处很直接：

• 读代码时定位更快

• 新功能扩展时不容易互相污染

• 维护时更容易判断改动影响范围

2. 服务端模板可以快速形成完整页面闭环

这个项目中大量页面其实都很适合服务端直接组织：

• 文章详情页

• 友链页

• 关于页

• 后台编辑页

• 消息中心

Jinja 模板在这里的优势不是“炫”，而是稳定、直接、可维护。尤其是一些带表单、带状态、带列表的页面，用服务端渲染非常省心。

3. 后台管理可以完全按实际业务长出来

如果用强约束框架，后台通常会非常“标准化”。但这个项目的后台并不是标准 CMS，而是更偏“站点控制台”：

• 文章管理

• 会话管理

• 关于页编辑

• 版本管理

• 技能管理

• 友链管理

这些模块的交互形态并不完全一致。Flask 的好处是，我可以一个页面一个页面按真实需求去设计，而不是为了套用后台而适配后台。

五、这套方案的成本与问题

技术选型如果只写优点，文章就不真实了。从开发者视角看，这套方案也有很明确的代价。

1. Flask 的自由，本质上要求你自己有结构设计能力

Flask 不替你做决定，所以你必须自己决定：

• 模块怎么拆

• 路由怎么分

• 表单怎么流转

• 权限怎么组织

• 后台怎么规划

• 模型关系怎么定义

如果这些问题没有提前想清楚，项目会很容易越写越散。

所以 Flask 不是“简单”，而是“核心简单，工程组织要求更高”。

2. 没有 Django 那种开箱即用的后台能力

如果目标只是快速搭一个标准博客，Django 的开发效率可能会更高。因为它自带：

• Admin

• ORM

• 认证系统

• 表单体系

• 比较完整的项目结构约定

而 Flask 这边，很多东西都要自己搭。

这意味着：

• 前期自由度更高

• 但前期工程投入也更多

3. 同步模型不是面向极高并发的最佳解

Flask 当前的同步模型，对于个人网站完全够用。但如果以后系统演进到高并发 API、实时推送、大量 I/O 密集型任务，那它未必仍然是最佳选项。

不过这也是技术选型里很重要的一点：

先解决真实问题，而不是假想问题。

对这个项目来说，当前真正需要解决的是“可维护性、稳定性、可控性”，而不是提前为极端吞吐量做过度设计。

六、为什么我没有选择 Django 和 FastAPI

1. Django：强大，但对我当前目标来说偏重

Django 非常适合：

• 标准化后台

• 内容管理系统

• 团队协作

• 快速生成完整功能站点

但它的问题也很明显：

• 默认约束更多

• 自带体系更完整

• 自定义时有时需要绕着框架走

我当前更需要的是：

• 自己定义页面和后台关系

• 自己组织资料流、消息流、通知流

• 在系统逐步扩展时保留完全控制权

所以我更偏向 Flask。

2. FastAPI：现代，但和当前项目重点不完全匹配

FastAPI 更适合：

• API 优先

• 前后端分离

• 类型驱动接口开发

• 异步并发场景

而这个项目目前核心仍然是：

• 服务端渲染页面

• 内容管理

• 后台表单

• 用户交互流程

在这种前提下，FastAPI 的优势还不是第一优先级。如果以后这个项目会演进成“独立前端 + 独立后端 + 开放 API”的形态，那 FastAPI 会更值得考虑。

七、这套技术栈最适合什么阶段的个人网站

如果让我总结，这套方案特别适合下面这种阶段：

• 你的网站已经不只是静态博客

• 你需要用户系统和后台

• 你会继续长期维护它

• 你想完全掌控代码结构

• 你不想为了一个个人项目引入过重基础设施

它不一定是最快搭完的方案，但它很适合“慢慢做成一个自己的产品”。

八、未来我会继续优化哪些部分

如果继续往下迭代，我认为这套系统最值得继续加强的方向有：

1. 数据库迁移体系

当模型越来越多时，字段兼容和结构演进应该进一步规范化，减少临时补齐逻辑。

2. 部署与缓存控制

随着版本迭代增多，静态资源版本、缓存失效、部署脚本和环境变量管理会越来越重要。

3. 消息和通知链路

消息中心与通知中心已经形成基础分工，但后续还可以继续优化一致性和可读性。

4. 搜索与内容聚合

内容站最终还是要回到内容本身。搜索、推荐、标签聚合、相关文章组织都还有提升空间。

九、结语

从纯“搭博客”的角度看，Flask 不是唯一答案。但从“做一个可持续演进的个人网站系统”的角度看，它是一个非常合理的答案。

我选择这套技术栈，并不是因为它最流行，也不是因为它最省事，而是因为它在当前阶段给了我三件最重要的东西：

• 足够清晰的结构

• 足够高的控制权

• 足够长的演进空间

对个人开发者来说，这三点往往比“技术栈是不是最前沿”更重要。