1. 为什么我选择 WorkBuddy Flask SQLite 这套组合先说结论这套组合不是拍脑袋选的是我在试过 WordPress、Shopify 和纯静态源码建站之后针对“个人内容站 日更 完全掌控数据”这个具体场景反复权衡下来的结果。WorkBuddy 负责把建站和日常运维的重复劳动自动化Flask 负责把站点逻辑写得足够轻、足够可控SQLite 负责把数据落在自己手里三者拼在一起形成一条从写稿到发布再到数据沉淀的完整链路。很多人一提到建站第一反应是 WordPress。WordPress 确实成熟插件生态庞大主题一抓一大把但它的问题也很明显为了一个日更的小站你要维护 PHP 运行环境、数据库、一堆插件插件之间还经常打架安全更新一停就容易出问题。Shopify 更适合电商月费加上交易抽成对纯内容站来说是杀鸡用牛刀。纯静态源码建站倒是轻但日更意味着你每天都要手动改文件、重新构建、重新部署时间一长根本坚持不下来。我真正想要的是内容用 Markdown 写写完丢进一个目录站点自动读取、自动渲染、自动更新数据文章、标签、访问记录存在一个单文件数据库里随时能备份、能迁移、能用工具打开看整个站点逻辑不超过几百行 Python出问题我自己能改。Flask SQLite 正好满足后两条而 WorkBuddy 补上了第一条——把“写完之后的一系列动作”变成可配置的自动化流程。这里要解释一下 WorkBuddy 的定位。它不是一个传统意义上的建站工具更像是一个“工作流编排 指令执行”的工作台。你可以把它理解成一个能听懂自然语言指令、并且能调用本地脚本和服务的调度中枢。我给它配置了自定义指令比如“发布新文章”“重建站点索引”“备份数据库”它就能按我预设的流程去执行对应的 Python 脚本。CodeBuddy 更偏向代码补全和对话式编程辅助WorkBuddy 则偏向任务编排和自动化执行两者定位不同我这里是拿 WorkBuddy 当运维调度用的。提示选型时不要被“哪个工具最火”带偏先想清楚你的核心诉求是“省事”“可控”还是“可扩展”。日更个人站可控和省事优先级最高所以 Flask SQLite 这种轻量自托管方案比重型 CMS 更合适。从影响范围看这套方案适合几类人一是想练手 Flask 全栈、又不想只写玩具项目的开发者二是做农产品价格、行业数据这类垂直内容、需要自己掌控数据的人三是厌倦了 CMS 插件地狱、想回归源码的独立站长。它不适合需要复杂电商功能、多用户权限体系或者高并发访问的场景那些场景该上专业方案就上专业方案别硬扛。2. 环境搭建Python、Flask、SQLite 与 WorkBuddy 的落地配置2.1 Python 环境与依赖安装的实操细节第一步永远是 Python 环境。我建议直接用 3.10 或 3.11太老的版本有些语法和库不支持太新的版本偶尔会遇到第三方库还没适配。Windows 用户去官网下载安装包时务必勾选“Add Python to PATH”这一步漏了后面在命令行里敲 python 会提示找不到命令是新手最常见的坑。macOS 用户可以用系统自带的 python3但更推荐用 pyenv 管理版本避免污染系统环境。装完之后验证一下python --version pip --version如果两条都能正常输出版本号说明基础环境没问题。接下来建虚拟环境这一步很多人嫌麻烦跳过结果全局包装了一堆项目之间版本冲突。养成习惯python -m venv venv # Windows venv\Scripts\activate # macOS / Linux source venv/bin/activate激活后命令行前面会出现 (venv) 标识。然后安装 Flaskpip install flaskFlask 本身非常轻核心依赖很少装起来很快。如果你后面要做数据可视化可以再加pip install pandas要做爬虫补充数据加pip install requests beautifulsoup4。但初期别一次装太多用到再加保持环境干净。VSCode 里配置 Python 环境时按 CtrlShiftP 打开命令面板输入“Python: Select Interpreter”选中你刚建的 venv 里的 python。这样编辑器里的补全、调试、终端都会用这个环境不会出现“编辑器里能跑、命令行里报错”的割裂情况。2.2 SQLite 的安装、可视化与数据库文件管理SQLite 最大的好处是零配置——它不是一个需要单独启动的服务而是一个库Python 标准库自带 sqlite3 模块你甚至不用额外安装任何东西就能用。但为了日常查看和调试数据我强烈建议装一个可视化工具DB Browser for SQLite 是我用得最顺手的免费、跨平台、打开即用。装好 DB Browser 之后你可以直接打开项目里的 .db 文件像看 Excel 一样看表结构和数据还能直接执行 SQL 语句。调试阶段这个太重要了比如你发现文章列表少了一篇打开数据库一看原来是某条记录的 status 字段写成了 draft 而不是 published一眼就能定位。数据库文件我放在项目根目录的data/文件夹下命名成site.db。这里有个经验不要把 .db 文件提交到 Git 仓库因为它是二进制文件每次改动都会产生巨大的 diff而且容易冲突。正确做法是在.gitignore里加上*.db数据库单独做备份。# .gitignore venv/ __pycache__/ *.db data/注意SQLite 默认不支持并发写入多个进程同时写会锁库。个人日更站访问量不大单进程 Flask 完全够用。如果以后要做多进程部署要么换 PostgreSQL要么把写操作集中到一个进程里别让多个 worker 同时写。2.3 WorkBuddy 的安装与自定义指令配置思路WorkBuddy 的安装按官方文档走就行Windows、Linux、Ubuntu 都有对应版本。装完之后核心是配置自定义指令。我的思路是把日常重复动作抽象成几条指令每条指令背后绑定一个 shell 脚本或 Python 脚本。比如我配置了这几条发布文章扫描content/目录下新增的 Markdown 文件解析 front matter写入 SQLite然后触发站点重建。备份数据把site.db复制到backups/目录文件名带上日期。重建索引重新生成文章列表页和标签页的缓存。WorkBuddy 的价值在于你不需要记住这些脚本的路径和参数直接用自然语言触发就行。它把“运维”这件事从“敲命令”变成了“说一句话”。对于日更这种高频动作省下的认知负担非常可观。配置指令时有个技巧把脚本路径写成绝对路径别用相对路径。因为 WorkBuddy 执行脚本时的工作目录不一定是你项目根目录相对路径很容易找不到文件。这个坑我踩过排查了半天才发现是路径问题。3. 站点核心逻辑Flask 路由、模板与 SQLite 数据层设计3.1 数据库表结构设计与字段取舍表结构不用一上来就设计得很复杂够用就行后面可以加字段。我的核心表就三张articles、tags、article_tags。CREATE TABLE articles ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, slug TEXT UNIQUE NOT NULL, content TEXT NOT NULL, summary TEXT, status TEXT DEFAULT published, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE tags ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT UNIQUE NOT NULL ); CREATE TABLE article_tags ( article_id INTEGER, tag_id INTEGER, PRIMARY KEY (article_id, tag_id), FOREIGN KEY (article_id) REFERENCES articles(id), FOREIGN KEY (tag_id) REFERENCES tags(id) );为什么用 slug 而不是直接用 id 做 URL因为 slug 对搜索引擎和用户都更友好/article/flask-sqlite-guide比/article/12可读性强太多。slug 从标题生成生成规则是把空格换成连字符、去掉特殊字符、转小写如果重复就加数字后缀。status 字段我留了 published 和 draft 两个值写稿阶段先存 draft确认没问题再改成 published。这个字段看似简单但配合 WorkBuddy 的发布指令能实现“写完先存草稿、检查后再上线”的流程避免手滑把半成品发出去。3.2 Flask 路由与模板渲染的关键写法Flask 的路由非常直观一个函数对应一个 URL。首页列出文章详情页展示单篇标签页按标签筛选from flask import Flask, render_template, abort import sqlite3 app Flask(__name__) DB_PATH data/site.db def get_db(): conn sqlite3.connect(DB_PATH) conn.row_factory sqlite3.Row return conn app.route(/) def index(): conn get_db() articles conn.execute( SELECT * FROM articles WHERE statuspublished ORDER BY created_at DESC ).fetchall() conn.close() return render_template(index.html, articlesarticles) app.route(/article/slug) def article_detail(slug): conn get_db() article conn.execute( SELECT * FROM articles WHERE slug? AND statuspublished, (slug,) ).fetchone() conn.close() if article is None: abort(404) return render_template(article.html, articlearticle)这里有个细节conn.row_factory sqlite3.Row这行很关键。默认情况下 sqlite3 返回的是元组你只能用下标访问字段row[0]、row[1]可读性极差。设置成 Row 之后就能用row[title]这样按字段名访问模板里写起来清爽很多。这个设置我建议每个项目都加上属于一次性配置、长期受益。模板用 Jinja2Flask 自带。文章内容如果是 Markdown渲染前要用 markdown 库转成 HTMLimport markdown html_content markdown.markdown(article[content], extensions[fenced_code, tables])fenced_code支持代码块tables支持表格这两个扩展基本是内容站的标配。不加的话你写的代码块和表格在页面上会变成一堆乱码般的纯文本。3.3 从 Markdown 到数据库内容入库的完整流程我的写作流程是在content/目录下新建一个.md文件文件开头用 front matter 写元信息--- title: Flask 与 SQLite 的配合要点 tags: flask, sqlite, python summary: 记录我在实际项目中踩过的坑 --- 正文内容从这里开始……然后 WorkBuddy 的“发布文章”指令会调用一个 Python 脚本扫描content/下所有 .md 文件解析 front matter检查 slug 是否已存在不存在就插入存在就更新。解析 front matter 我用的是python-frontmatter库一行代码就能把元信息和正文分开import frontmatter post frontmatter.load(content/example.md) print(post[title]) # 元信息 print(post.content) # 正文入库时要注意事务处理。如果文章插入成功但标签插入失败数据库就会处于不一致状态。正确做法是把整个入库过程包在一个事务里conn get_db() try: cur conn.execute( INSERT INTO articles (title, slug, content, summary) VALUES (?,?,?,?), (title, slug, content, summary) ) article_id cur.lastrowid for tag_name in tags: conn.execute(INSERT OR IGNORE INTO tags (name) VALUES (?), (tag_name,)) tag_id conn.execute(SELECT id FROM tags WHERE name?, (tag_name,)).fetchone()[id] conn.execute(INSERT OR IGNORE INTO article_tags (article_id, tag_id) VALUES (?,?), (article_id, tag_id)) conn.commit() except Exception as e: conn.rollback() raise e finally: conn.close()INSERT OR IGNORE保证标签不会重复插入rollback保证出错时不留脏数据。这套写法看起来啰嗦但它是数据一致性的底线别图省事省掉。4. 日更实操从写稿到上线的完整链路与自动化4.1 每日发布流程的拆解与时间分配日更最难的不是技术是坚持。所以流程必须足够短、足够顺短到你没有借口拖延。我现在的日更链路是这样的早上花 20 分钟想选题、列提纲写在草稿文件里。中午或晚上花 40 分钟把正文写完front matter 填好。触发 WorkBuddy 的“发布文章”指令脚本自动入库、重建索引。本地flask run预览一遍检查排版和链接。确认无误后触发部署脚本同步到线上。整个链路里真正需要我动脑的是第 1、2 步第 3 到 5 步都是自动化的。这就是 WorkBuddy 的价值所在——它把“技术操作”从日更流程里剥离出去了我只需要专注在内容本身。时间分配上我有个体会不要把写稿和发布挤在一起。写稿是创作状态发布是运维状态两种状态切换需要成本。我习惯写完先存草稿隔一会儿再统一发布这样发布时心态更从容也更容易发现稿子里的问题。4.2 WorkBuddy 自定义指令的脚本实现“发布文章”这条指令背后的脚本核心逻辑就是前面说的扫描、解析、入库。但有几个工程细节值得展开。第一是增量处理。不要每次都全量扫描所有 .md 文件重新入库那样文章一多就慢。我的做法是记录每个文件的修改时间只处理比数据库里 updated_at 更新的文件。简单实现可以用文件哈希import hashlib def file_hash(path): with open(path, rb) as f: return hashlib.md5(f.read()).hexdigest()数据库里加一个 content_hash 字段入库前比对哈希一样就跳过。这样日更时只处理当天新增的那一篇速度飞快。第二是 slug 冲突处理。两篇文章标题一样时slug 会撞车。我的处理是检测到冲突就在后面加-2、-3base_slug slugify(title) slug base_slug counter 2 while conn.execute(SELECT 1 FROM articles WHERE slug?, (slug,)).fetchone(): slug f{base_slug}-{counter} counter 1第三是发布后的缓存刷新。如果站点用了页面缓存发布后要清掉相关缓存否则用户看到的还是旧内容。我初期没做这一步结果自己预览时看到的是新文章线上用户看到的还是旧的排查了好一阵才反应过来是缓存问题。4.3 本地预览与线上部署的衔接本地预览用flask run就够了默认跑在 5000 端口。调试模式打开app.run(debugTrue)改代码自动重载省去反复重启的麻烦。但调试模式千万别用在线上它会暴露源码和堆栈信息是安全隐患。线上部署我用的是最朴素的方案一台小服务器装 Python 环境用 gunicorn 跑 Flask 应用前面挂个 Nginx 做反向代理和静态文件服务。gunicorn 的启动命令gunicorn -w 2 -b 127.0.0.1:8000 app:app-w 2是两个 worker 进程。前面提过 SQLite 并发写的问题两个 worker 读没问题写操作我通过 WorkBuddy 集中触发不会出现多进程同时写的情况。Nginx 配置里把/static/目录直接指向静态文件不经过 Flask减轻应用压力。部署脚本我写成了一个 shell 文件WorkBuddy 触发后自动执行拉取最新代码、重启 gunicorn、清理缓存。整个部署过程不到 10 秒日更时几乎无感。提示部署脚本里一定要加失败回滚逻辑。比如重启 gunicorn 后检测进程是否真的起来了没起来就回滚到上一个版本。我吃过一次亏部署脚本执行到一半失败站点直接 502半夜爬起来手动恢复。5. 踩坑记录与常见问题速查5.1 数据库相关的典型问题问题一数据库被锁database is locked。这个报错几乎每个用 SQLite 的人都会遇到。原因通常是某个连接没有及时关闭或者多个进程同时写。排查方法是检查代码里每个sqlite3.connect是否都有对应的close推荐用上下文管理器with sqlite3.connect(DB_PATH) as conn: conn.execute(...)with 语句会在退出时自动提交或回滚并关闭连接比手动 close 可靠。问题二中文乱码。SQLite 默认用 UTF-8一般不会乱码。如果出现乱码多半是连接时没指定编码或者文件本身不是 UTF-8。确保 Python 文件开头有# -*- coding: utf-8 -*-连接时不用额外指定sqlite3 默认就是 UTF-8。问题三数据库文件能不能加密。SQLite 原生不支持加密需要用到 SQLCipher 这类扩展。个人内容站一般没必要但如果数据敏感可以考虑。我的做法是数据库文件权限设成只有自己能读写配合服务器本身的访问控制。5.2 Flask 开发中的高频报错问题模板找不到TemplateNotFound。九成是目录结构不对。Flask 默认在项目根目录的templates/文件夹找模板在static/找静态文件。如果你把模板放在别的地方要在创建 app 时指定template_folder参数。问题静态文件 404。检查url_for(static, filename...)里的路径是否和实际文件对应。Flask 的 static 路由是自动注册的但文件名大小写敏感Linux 服务器上Style.css和style.css是两个文件Windows 上不区分本地能跑线上 404这个坑很隐蔽。问题获取客户端传来的变量类型不对。Flask 里request.args.get()拿到的永远是字符串哪怕用户传的是数字。要转成整数得手动int(request.args.get(page, 1))而且要处理转换失败的情况否则用户传个?pageabc就直接 500 了。5.3 WorkBuddy 使用中的注意事项WorkBuddy 的指令执行是异步的触发后不会立刻返回结果。初期我总以为指令没生效反复触发结果同一个脚本跑了好几遍。正确做法是看日志确认执行状态或者让脚本在结束时输出明确的成功标识。另外WorkBuddy 的指令配置里环境变量要显式声明。它执行脚本时的环境和你终端里的环境不一定一致比如 PATH 里可能没有你 venv 的 python。我的做法是在脚本开头写死 python 的绝对路径或者用source venv/bin/activate python script.py这种方式确保环境正确。问题现象可能原因排查方向database is locked连接未关闭或多进程写检查 close、用 with 语句TemplateNotFound模板目录结构不对确认 templates 目录位置静态文件 404文件名大小写不一致对比本地与线上文件名指令重复执行异步执行被误判为未生效查看日志确认状态部署后 502gunicorn 未启动成功检查进程和端口占用5.4 我踩过的几个印象深刻的坑第一个坑是时间戳时区问题。SQLite 的CURRENT_TIMESTAMP用的是 UTC 时间我本地看着文章发布时间比实际早了 8 小时一度以为是代码写错了。后来在展示时统一做了时区转换才解决。如果你也遇到时间对不上先确认是不是 UTC 和本地时间的差异。第二个坑是 Markdown 里的 HTML 被转义。Jinja2 默认会转义所有变量{{ article.content | safe }}里的 safe 过滤器不能忘否则你精心写的 HTML 标签会原样显示成文本。但 safe 有 XSS 风险只对你自己写的内容用用户提交的内容千万别加 safe。第三个坑是数据库备份没做自动化。有次误操作删了一篇文章想恢复发现没有备份只能重写。从那以后我把备份指令设成了每天定时触发WorkBuddy 自动把数据库复制到 backups 目录保留最近 30 天。这个习惯救过我好几次。6. 内容扩展与后续可玩的方向站点跑起来之后能扩展的方向其实很多。我最近在做的一个是把农产品价格数据接进来用 Flask 做一个简单的数据可视化页面。思路是用爬虫定期抓取价格数据存进 SQLite然后用 pandas 做聚合前端用轻量的图表库渲染。这块和内容站是同一套技术栈复用度很高。另一个方向是给 WorkBuddy 加更多自定义指令比如“生成周报”自动统计本周发布了几篇、哪些标签用得最多、访问量趋势如何。这些数据都在 SQLite 里写个查询脚本就能出结果WorkBuddy 负责定时触发和推送。还有人问过我要不要上 WordPress。我的看法是如果你只是想快速有个能写东西的地方WordPress 确实省事但如果你想顺便练技术、想完全掌控数据和逻辑、想按自己的节奏迭代Flask SQLite 这条路更值得走。它逼着你理解每一个环节理解之后你就有能力改它、扩展它而不是被工具牵着走。最后分享一个小技巧把每天的发布记录也存进数据库包括发布时间、字数、标签。坚持一段时间后回头看你会对自己的写作节奏有更清晰的认识哪些天写得多、哪些标签是主力一目了然。数据这东西攒着攒着就有价值了。