当博客开始需要“用户注册、发布审核、权限分级”时， 纯静态方案通常会遇到边界。这个阶段最有效的升级方式， 不是推倒重来，而是给静态前端补一个后端能力层。
这篇文章从工程角度总结一个可落地路径：以 Flask 为核心， 逐步把博客从“页面集合”演进为“具备审批流的内容系统”。
一、为什么要引入后端
静态站点强在渲染与分发，但业务状态无法仅靠 HTML 保存。 你需要一个能“记住用户、处理权限、维护流程”的服务端。 常见搭配是： Flask + SQLite（起步）或 Flask + MySQL/PostgreSQL（扩展）。
此时 Nginx 仍负责静态资源分发，同时作为反向代理， 把 API 请求转发到 Flask，前后端职责更清晰。
二、数据库模型设计（Data Schema）
审批流能不能稳定运行，核心在于数据结构是否“先想清楚”。
最小模型可以先有两张表：User 与 Post。
其中 role 决定权限边界，status 决定流程节点。
# models.py
class User(db.Model):
id = db.Column(db.Integer, primary_key=True)
username = db.Column(db.String(20), unique=True)
role = db.Column(db.String(10)) # 'admin' 或 'user'
status = db.Column(db.String(10)) # 'pending', 'active'
can_post_direct = db.Column(db.Boolean)
三、审批流（Workflow）怎么做
业务上可归纳为两个动作：拦截 与 放行。 建议先用“明确规则 + 少量状态”实现，不要一开始就设计过度复杂的流程引擎。
-
注册环节：
新用户默认设为
pending， 管理员审核后改为active。 -
投稿环节：
普通用户发文默认
is_approved=False， 只有审核通过才进入公开列表。 -
特权分配：
对长期稳定贡献者可启用
can_post_direct， 降低审核队列压力。
flask_login 管理 Session，
并使用 Bcrypt
对密码进行加盐哈希存储。
四、上线前建议
- 对所有管理接口做角色校验，不信任前端传参
- 写最基础的审计日志：谁在何时通过/驳回了什么
- 对关键状态变更增加回滚策略
- 先做“能跑通”版本，再做体验优化
五、总结
从静态博客到动态审批系统，本质是一次工程能力升级： 你开始处理状态、权限和流程，而不仅是页面样式。 这一步走稳，后续再接入评论、订阅、消息提醒都会顺很多。