1. 为什么我选择 WorkBuddy Flask SQLite 这套组合1.1 从零建站的真实需求拆解很多人一提到建站第一反应就是 WordPress或者干脆上 Shopify 这类托管方案。我一开始也是这么想的但实际折腾下来发现如果你只是想做一个轻量的、自己能完全掌控的内容站点尤其是那种需要日更、需要自己写点逻辑、又不想被各种插件和主题绑架的场景WordPress 反而会变成负担。数据库要单独配、PHP 环境要调、插件冲突三天两头出问题光是维护这套东西就够喝一壶的。我的核心诉求其实很朴素一个能每天更新内容的站点后台逻辑我自己说了算数据存本地部署简单最好一台最低配的机器就能跑起来。基于这个诉求我把技术栈锁定在了Flask SQLite上。Flask 是 Python 的轻量级 Web 框架没有 Django 那么多约定俗成的东西你想怎么组织就怎么组织SQLite 更是一个文件就是一个数据库不需要单独起服务备份就是复制一个文件对于日更这种写入频率不高、读取为主的场景简直完美。那 WorkBuddy 在这里扮演什么角色它是我用来加速整个建站流程的辅助工具。你可以把它理解成一个能帮你把零散想法快速落地成可运行代码的搭档。从项目结构初始化到 Flask 路由的骨架生成再到 SQLite 建表语句的草拟它都能帮我省掉大量查文档和敲重复代码的时间。这套组合下来我从零到站点上线实际只花了不到两天后面就是每天花十几分钟更新内容。1.2 三种建站路线对比为什么自建站更适合日更场景在动手之前我把市面上主流的三种路线拉出来做了个对比这个对比直接决定了我的选型。对比维度Shopify 类托管WordPress 自托管Flask SQLite 自建上手速度极快注册即用中等需配环境较慢需写代码数据掌控平台方自己完全自己日更成本低但受限于平台规则中插件多了会卡低写入逻辑自己定定制自由度低中受主题插件限制极高长期维护平台负责自己负责升级易崩自己负责但依赖少适合人群纯电商小白内容运营者有基础编程能力者Shopify 这类方案适合纯电商、不想碰技术的人但它的数据在别人手里你想做个自定义的数据分析或者特殊的内容展示逻辑基本没戏。WordPress 灵活一些但它的灵活性建立在庞大的插件生态上插件一多站点就变重日更的时候后台响应会明显变慢。而 Flask SQLite 这套虽然前期要写点代码但一旦跑起来整个站点的行为完全由我控制日更就是往数据库里插一条记录的事快得飞起。提示如果你完全没有编程基础又急着上线WordPress 仍然是更稳妥的选择。但如果你愿意花几天学一下 Python 基础Flask SQLite 的长期收益会高得多。1.3 WorkBuddy 在流程中的定位与价值WorkBuddy 不是建站框架它更像是一个“流程加速器”。我在整个项目里用它做了三件事第一生成 Flask 项目的初始目录结构和基础路由代码第二根据我的描述生成 SQLite 的建表语句和常用的增删改查函数第三在我遇到报错时帮我快速定位问题并给出修改建议。举个具体的例子我一开始对 Flask 的蓝图Blueprint结构不太熟手动拆分模块的时候总是导入出错。我把需求描述给 WorkBuddy它直接给我生成了一套按功能划分的蓝图结构包括__init__.py里的注册逻辑、各个蓝图文件的路由定义我只需要把业务逻辑填进去就行。这省掉了我至少半天查文档和试错的时间。但要注意WorkBuddy 生成的东西不能无脑照搬。它给的代码有时候会假设一些不存在的依赖或者用了较新版本的语法而你的环境可能是旧版本。所以我的习惯是先生成再理解最后按自己的环境调整。这个习惯让我避开了很多“代码看起来对但就是跑不起来”的坑。2. 环境搭建与项目初始化实操2.1 Python 环境配置与虚拟环境隔离第一步永远是 Python 环境。我用的 Python 3.10这个版本在 Flask 和 SQLite 的兼容性上都很稳。安装过程不复杂去官网下载对应系统的安装包Windows 记得勾选“Add Python to PATH”macOS 和 Linux 一般自带或者用包管理器装就行。装完之后我强烈建议用虚拟环境隔离项目依赖。原因很简单你不可能只做一个项目不同项目依赖的库版本可能冲突全局安装迟早出事。创建虚拟环境的命令如下# 创建虚拟环境 python -m venv venv # 激活虚拟环境Windows venv\Scripts\activate # 激活虚拟环境macOS/Linux source venv/bin/activate激活之后命令行前面会出现(venv)标识说明你已经在隔离环境里了。接下来安装 Flaskpip install flask这里有个细节Flask 本身不包含数据库驱动SQLite 是 Python 标准库自带的所以不需要额外安装sqlite3模块直接import sqlite3就能用。这一点比 MySQL 省事太多不用装驱动、不用配连接池。注意如果你在 Windows 上遇到python命令找不到的情况试试py命令这是 Windows 的 Python 启动器。另外虚拟环境不要提交到 Git在.gitignore里加上venv/就行。2.2 用 WorkBuddy 生成项目骨架环境好了之后我让 WorkBuddy 帮我生成项目骨架。我给它的描述是“一个 Flask 项目包含首页、文章列表页、文章详情页用 SQLite 存文章数据需要蓝图结构模板用 Jinja2。”它生成的目录结构大致是这样的myblog/ ├── app/ │ ├── __init__.py │ ├── routes/ │ │ ├── __init__.py │ │ ├── main.py │ │ └── article.py │ ├── models/ │ │ ├── __init__.py │ │ └── db.py │ ├── templates/ │ │ ├── base.html │ │ ├── index.html │ │ ├── article_list.html │ │ └── article_detail.html │ └── static/ │ └── style.css ├── instance/ │ └── blog.db ├── config.py └── run.py这个结构清晰地把路由、数据模型、模板分开了。instance文件夹放数据库文件这是 Flask 的惯例因为这个文件夹不会被纳入版本控制适合放本地数据。config.py放配置项比如数据库路径、密钥等。run.py是启动入口。我拿到这个骨架后做了一件事逐个文件读一遍确认每个文件的职责。这一步不能省因为 WorkBuddy 生成的代码是通用模板你需要把它变成你自己的。比如config.py里它给了一个默认的SECRET_KEY我改成了自己生成的一串随机字符这个密钥用于会话加密不能泄露。2.3 SQLite 数据库文件的位置与初始化SQLite 的数据库就是一个文件位置很关键。我把它放在instance/blog.db然后在config.py里这样配置import os BASE_DIR os.path.dirname(os.path.abspath(__file__)) class Config: SECRET_KEY 你生成的一串随机字符 DATABASE os.path.join(BASE_DIR, instance, blog.db)然后在app/models/db.py里写获取数据库连接的函数import sqlite3 from flask import current_app, g def get_db(): if db not in g: g.db sqlite3.connect( current_app.config[DATABASE], detect_typessqlite3.PARSE_DECLTYPES ) g.db.row_factory sqlite3.Row return g.db def close_db(eNone): db g.pop(db, None) if db is not None: db.close()这里用了 Flask 的g对象它是在一次请求周期内共享的。row_factory sqlite3.Row这一行很重要它让查询结果可以像字典一样用列名访问而不是只能用索引。detect_types参数让 SQLite 能自动把时间戳字段转成 Python 的datetime对象省去手动转换的麻烦。初始化数据库的脚本我单独写了一个init_db.pyimport sqlite3 from config import Config def init_db(): conn sqlite3.connect(Config.DATABASE) with open(schema.sql, r, encodingutf-8) as f: conn.executescript(f.read()) conn.commit() conn.close() if __name__ __main__: init_db()schema.sql里放建表语句这个我让 WorkBuddy 根据我的字段需求生成然后自己调整。文章表的结构大概是这样CREATE TABLE IF NOT EXISTS article ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, content TEXT NOT NULL, summary TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );AUTOINCREMENT保证 id 单调递增DEFAULT CURRENT_TIMESTAMP让插入时自动填时间省去手动传时间戳。summary字段用于列表页展示摘要避免每次都把全文查出来。3. 核心功能开发与日更流程落地3.1 文章发布与展示的完整链路日更的核心就是“发布”和“展示”两个动作。发布是往数据库写展示是从数据库读。我先说发布。发布功能我一开始想做个后台管理页面但后来发现对于日更场景直接在本地跑一个脚本更快。我写了一个publish.py运行的时候从命令行参数或者交互式输入里拿标题和内容然后插入数据库import sqlite3 from datetime import datetime from config import Config def publish_article(title, content, summary): conn sqlite3.connect(Config.DATABASE) cursor conn.cursor() cursor.execute( INSERT INTO article (title, content, summary, created_at, updated_at) VALUES (?, ?, ?, ?, ?), (title, content, summary, datetime.now(), datetime.now()) ) conn.commit() conn.close() print(f文章《{title}》发布成功) if __name__ __main__: title input(标题) content input(内容) summary input(摘要可留空) publish_article(title, content, summary)这里用了参数化查询?占位符这是防止 SQL 注入的基本操作绝对不能把用户输入直接拼接到 SQL 字符串里。datetime.now()手动传入而不是依赖数据库默认值是因为我想在 Python 层面控制时间格式方便后续做时区处理。展示部分就是 Flask 路由加模板渲染。文章列表页的路由from flask import Blueprint, render_template from app.models.db import get_db bp Blueprint(article, __name__) bp.route(/articles) def article_list(): db get_db() articles db.execute( SELECT id, title, summary, created_at FROM article ORDER BY created_at DESC ).fetchall() return render_template(article_list.html, articlesarticles) bp.route(/article/int:id) def article_detail(id): db get_db() article db.execute( SELECT * FROM article WHERE id ?, (id,) ).fetchone() if article is None: abort(404) return render_template(article_detail.html, articlearticle)列表页只查需要的字段不查content这样数据量大了之后列表页依然很快。详情页用fetchone()拿单条拿不到就返回 404。模板里用 Jinja2 的循环和变量替换这部分 WorkBuddy 生成的模板基本能用我主要调整了样式和布局。3.2 用 DB Browser for SQLite 做数据核对虽然我可以用命令行查数据库但日更的时候经常需要快速核对数据比如确认某篇文章有没有写进去、时间对不对。这时候DB Browser for SQLite就派上用场了。它是一个图形化的 SQLite 客户端打开数据库文件就能看到所有表和数据还能直接执行 SQL。我的习惯是每天发布完文章后用 DB Browser 打开blog.db看一眼article表的最新几条记录确认标题、时间、摘要都正确。这个动作花不了十秒钟但能避免“以为发出去了其实没发成功”的尴尬。提示DB Browser for SQLite 在 Windows、macOS、Linux 上都有官网直接下载安装包就行。打开数据库文件的时候记得先关掉正在运行的 Flask 服务虽然 SQLite 支持并发读但写入的时候可能会锁文件。另外DB Browser 还能用来做数据导出。比如我想把文章数据导出成 CSV 做备份直接用它自带的导出功能就行不用写代码。这个工具对于不熟悉命令行的朋友特别友好强烈建议装一个。3.3 日更节奏下的自动化小技巧日更最怕的就是流程太繁琐繁琐就会拖延拖延就会断更。所以我把发布流程尽量简化。除了上面说的publish.py脚本我还加了一个小功能从 Markdown 文件批量导入。因为我平时写草稿习惯用 Markdown写完之后直接跑一个脚本把文件内容读出来插进数据库连复制粘贴都省了。import sqlite3 import os from datetime import datetime from config import Config def import_from_markdown(filepath): with open(filepath, r, encodingutf-8) as f: content f.read() filename os.path.basename(filepath) title os.path.splitext(filename)[0] summary content[:100].replace(\n, ) conn sqlite3.connect(Config.DATABASE) cursor conn.cursor() cursor.execute( INSERT INTO article (title, content, summary, created_at, updated_at) VALUES (?, ?, ?, ?, ?), (title, content, summary, datetime.now(), datetime.now()) ) conn.commit() conn.close() print(f已导入{title}) if __name__ __main__: import_from_markdown(drafts/today.md)这个脚本把文件名当标题把内容前 100 个字符当摘要一键导入。我每天写完草稿保存成drafts/日期.md然后跑一下脚本文章就进库了。整个过程不到一分钟。还有一个技巧是给文章加一个“草稿”状态字段。有时候文章没写完但想先存着就可以先插入一条statusdraft的记录列表页查询的时候加个WHERE statuspublished过滤掉草稿。等写完了再更新状态。这个字段我后来加上了确实方便。4. 部署上线与常见问题排查4.1 从本地到服务器的部署路径本地跑通之后下一步就是部署到服务器上让站点能被外部访问。我用的是一台最低配的云服务器系统是 Ubuntu。部署 Flask 应用不能直接用flask run那个是开发服务器性能和稳定性都不够。生产环境我用的是Gunicorn Nginx的组合。Gunicorn 是 Python 的 WSGI 服务器负责跑 Flask 应用Nginx 作为反向代理负责处理静态文件、转发请求给 Gunicorn。安装很简单pip install gunicorn sudo apt install nginx启动 Gunicorn 的命令gunicorn -w 2 -b 127.0.0.1:8000 run:app-w 2表示两个 worker 进程对于低配机器足够了。run:app表示从run.py里导入app对象。然后配置 Nginx把 80 端口的请求转发到 8000 端口server { listen 80; server_name your_domain.com; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /static/ { alias /path/to/your/app/static/; } }静态文件交给 Nginx 直接处理不经过 Flask这样能减轻应用服务器的压力。配置完之后sudo nginx -s reload重载配置。注意SQLite 数据库文件在部署后要注意权限问题。Gunicorn 运行的用户必须对instance/blog.db有读写权限否则会报“unable to open database file”。我一开始就踩了这个坑后来把数据库文件的所有者改成运行 Gunicorn 的用户就好了。4.2 常见报错与排查速查表建站过程中我遇到了不少报错这里整理成一张速查表方便你遇到类似问题时快速定位。报错信息可能原因解决方法ModuleNotFoundError: No module named flask虚拟环境没激活或没装 Flask激活虚拟环境后pip install flasksqlite3.OperationalError: unable to open database file数据库路径错误或权限不足检查config.py里的路径确认文件权限jinja2.exceptions.TemplateNotFound模板文件不在templates目录确认模板路径和文件名大小写sqlite3.IntegrityError: NOT NULL constraint failed插入时必填字段为空检查插入语句是否漏了字段Address already in use端口被占用换端口或杀掉占用进程502 Bad GatewayGunicorn 没启动或崩溃检查 Gunicorn 日志确认应用能正常导入页面样式丢失Nginx 静态文件路径配错检查location /static/的alias路径这张表里的每一条都是我实际遇到过的。其中502 Bad Gateway最让人头疼因为 Nginx 只告诉你网关错误具体原因要看 Gunicorn 的日志。我的习惯是先用gunicorn run:app直接在前台跑一下看有没有报错确认应用本身没问题再放到后台。4.3 数据备份与迁移的实操经验SQLite 最大的优势就是备份简单复制文件就行。但复制的时候要注意如果数据库正在被写入直接复制可能会得到一个损坏的文件。正确的做法是先停掉应用或者用 SQLite 自带的备份命令sqlite3 blog.db .backup backup.db这个命令会在数据库运行时创建一个一致性快照不会因为并发写入导致备份文件损坏。我设置了一个定时任务每天凌晨跑一次备份备份文件按日期命名保留最近 30 天。迁移就更简单了把blog.db文件拷到新服务器上配好环境启动应用就行。不需要导出 SQL、不需要重建表结构一个文件搞定。这也是我当初选 SQLite 的重要原因之一。提示如果你的站点数据量增长到几万篇文章SQLite 的读取性能依然没问题但写入可能会开始变慢。这时候可以考虑加索引比如在created_at字段上建索引加速列表页的排序查询。建索引的语句是CREATE INDEX idx_created_at ON article(created_at DESC);。5. 我踩过的坑和几条实在建议5.1 关于 WorkBuddy 生成代码的使用心得WorkBuddy 生成的代码质量整体不错但有几个地方需要特别注意。第一它有时候会用一些较新的 Python 语法比如海象运算符:或者 f-string 的嵌套如果你的 Python 版本比较旧就会报语法错误。我的做法是生成之后先扫一眼看到不熟悉的语法就查一下版本要求。第二它生成的 SQL 语句有时候没有加IF NOT EXISTS重复执行会报错。建表语句我一般会手动加上IF NOT EXISTS这样初始化脚本可以反复跑不会因为表已存在而中断。第三它生成的 Flask 路由有时候缺少错误处理。比如查询单条记录的时候没有判断None直接拿结果去渲染模板数据不存在就会报错。我养成了一个习惯凡是fetchone()的地方后面必跟一个if xxx is None的判断。这个习惯帮我避免了很多 500 错误。5.2 日更站点的内容管理策略日更最难的不是技术是坚持。技术上的顺畅能降低坚持的难度但内容本身的规划也很重要。我的策略是提前攒一批草稿状态设为draft每天从草稿里挑一篇发布。这样即使某天特别忙也不会断更。另外我给文章加了一个tags字段用逗号分隔存多个标签。列表页可以按标签筛选详情页展示相关文章。这个功能不复杂但能提升站点的可浏览性。实现方式就是在查询的时候加一个WHERE tags LIKE %xxx%的条件虽然不够优雅但对于小规模数据完全够用。还有一点文章的updated_at字段我一开始没怎么用后来发现有时候会修改已发布的文章这时候更新updated_at能让读者知道内容有更新。所以每次更新文章内容的时候记得把updated_at也一起更新。5.3 性能与安全上的几个关键注意点性能方面SQLite 在读取为主的场景下表现很好但有几个地方要注意。第一每次请求都创建新的数据库连接是有开销的我用 Flask 的g对象做了请求级别的连接复用请求结束自动关闭。第二列表页一定要分页不能一次性把所有文章查出来。我用的LIMIT和OFFSET做分页每页 20 条。安全方面除了前面说的参数化查询防注入还有几点。第一SECRET_KEY绝对不能硬编码在代码里提交到公开仓库我是通过环境变量读取的。第二用户输入的内容在渲染到模板之前Jinja2 默认会转义 HTML所以不用担心 XSS但如果你用了|safe过滤器就要确保内容是你自己可控的。第三生产环境一定要关掉 Flask 的调试模式debugTrue会暴露源代码和堆栈信息非常危险。最后说一个我个人的体会这套技术栈最大的价值在于“可控”。从数据库文件到应用代码每一层我都能看懂、能改、能迁移。不像用托管平台出了问题只能等客服想加个功能要看平台支不支持。如果你也想做一个自己能完全掌控的日更站点Flask SQLite 这条路值得走一遍。 Flask + SQLite 自建日更站：WorkBuddy 加速开发与部署实战
1. 为什么我选择 WorkBuddy Flask SQLite 这套组合1.1 从零建站的真实需求拆解很多人一提到建站第一反应就是 WordPress或者干脆上 Shopify 这类托管方案。我一开始也是这么想的但实际折腾下来发现如果你只是想做一个轻量的、自己能完全掌控的内容站点尤其是那种需要日更、需要自己写点逻辑、又不想被各种插件和主题绑架的场景WordPress 反而会变成负担。数据库要单独配、PHP 环境要调、插件冲突三天两头出问题光是维护这套东西就够喝一壶的。我的核心诉求其实很朴素一个能每天更新内容的站点后台逻辑我自己说了算数据存本地部署简单最好一台最低配的机器就能跑起来。基于这个诉求我把技术栈锁定在了Flask SQLite上。Flask 是 Python 的轻量级 Web 框架没有 Django 那么多约定俗成的东西你想怎么组织就怎么组织SQLite 更是一个文件就是一个数据库不需要单独起服务备份就是复制一个文件对于日更这种写入频率不高、读取为主的场景简直完美。那 WorkBuddy 在这里扮演什么角色它是我用来加速整个建站流程的辅助工具。你可以把它理解成一个能帮你把零散想法快速落地成可运行代码的搭档。从项目结构初始化到 Flask 路由的骨架生成再到 SQLite 建表语句的草拟它都能帮我省掉大量查文档和敲重复代码的时间。这套组合下来我从零到站点上线实际只花了不到两天后面就是每天花十几分钟更新内容。1.2 三种建站路线对比为什么自建站更适合日更场景在动手之前我把市面上主流的三种路线拉出来做了个对比这个对比直接决定了我的选型。对比维度Shopify 类托管WordPress 自托管Flask SQLite 自建上手速度极快注册即用中等需配环境较慢需写代码数据掌控平台方自己完全自己日更成本低但受限于平台规则中插件多了会卡低写入逻辑自己定定制自由度低中受主题插件限制极高长期维护平台负责自己负责升级易崩自己负责但依赖少适合人群纯电商小白内容运营者有基础编程能力者Shopify 这类方案适合纯电商、不想碰技术的人但它的数据在别人手里你想做个自定义的数据分析或者特殊的内容展示逻辑基本没戏。WordPress 灵活一些但它的灵活性建立在庞大的插件生态上插件一多站点就变重日更的时候后台响应会明显变慢。而 Flask SQLite 这套虽然前期要写点代码但一旦跑起来整个站点的行为完全由我控制日更就是往数据库里插一条记录的事快得飞起。提示如果你完全没有编程基础又急着上线WordPress 仍然是更稳妥的选择。但如果你愿意花几天学一下 Python 基础Flask SQLite 的长期收益会高得多。1.3 WorkBuddy 在流程中的定位与价值WorkBuddy 不是建站框架它更像是一个“流程加速器”。我在整个项目里用它做了三件事第一生成 Flask 项目的初始目录结构和基础路由代码第二根据我的描述生成 SQLite 的建表语句和常用的增删改查函数第三在我遇到报错时帮我快速定位问题并给出修改建议。举个具体的例子我一开始对 Flask 的蓝图Blueprint结构不太熟手动拆分模块的时候总是导入出错。我把需求描述给 WorkBuddy它直接给我生成了一套按功能划分的蓝图结构包括__init__.py里的注册逻辑、各个蓝图文件的路由定义我只需要把业务逻辑填进去就行。这省掉了我至少半天查文档和试错的时间。但要注意WorkBuddy 生成的东西不能无脑照搬。它给的代码有时候会假设一些不存在的依赖或者用了较新版本的语法而你的环境可能是旧版本。所以我的习惯是先生成再理解最后按自己的环境调整。这个习惯让我避开了很多“代码看起来对但就是跑不起来”的坑。2. 环境搭建与项目初始化实操2.1 Python 环境配置与虚拟环境隔离第一步永远是 Python 环境。我用的 Python 3.10这个版本在 Flask 和 SQLite 的兼容性上都很稳。安装过程不复杂去官网下载对应系统的安装包Windows 记得勾选“Add Python to PATH”macOS 和 Linux 一般自带或者用包管理器装就行。装完之后我强烈建议用虚拟环境隔离项目依赖。原因很简单你不可能只做一个项目不同项目依赖的库版本可能冲突全局安装迟早出事。创建虚拟环境的命令如下# 创建虚拟环境 python -m venv venv # 激活虚拟环境Windows venv\Scripts\activate # 激活虚拟环境macOS/Linux source venv/bin/activate激活之后命令行前面会出现(venv)标识说明你已经在隔离环境里了。接下来安装 Flaskpip install flask这里有个细节Flask 本身不包含数据库驱动SQLite 是 Python 标准库自带的所以不需要额外安装sqlite3模块直接import sqlite3就能用。这一点比 MySQL 省事太多不用装驱动、不用配连接池。注意如果你在 Windows 上遇到python命令找不到的情况试试py命令这是 Windows 的 Python 启动器。另外虚拟环境不要提交到 Git在.gitignore里加上venv/就行。2.2 用 WorkBuddy 生成项目骨架环境好了之后我让 WorkBuddy 帮我生成项目骨架。我给它的描述是“一个 Flask 项目包含首页、文章列表页、文章详情页用 SQLite 存文章数据需要蓝图结构模板用 Jinja2。”它生成的目录结构大致是这样的myblog/ ├── app/ │ ├── __init__.py │ ├── routes/ │ │ ├── __init__.py │ │ ├── main.py │ │ └── article.py │ ├── models/ │ │ ├── __init__.py │ │ └── db.py │ ├── templates/ │ │ ├── base.html │ │ ├── index.html │ │ ├── article_list.html │ │ └── article_detail.html │ └── static/ │ └── style.css ├── instance/ │ └── blog.db ├── config.py └── run.py这个结构清晰地把路由、数据模型、模板分开了。instance文件夹放数据库文件这是 Flask 的惯例因为这个文件夹不会被纳入版本控制适合放本地数据。config.py放配置项比如数据库路径、密钥等。run.py是启动入口。我拿到这个骨架后做了一件事逐个文件读一遍确认每个文件的职责。这一步不能省因为 WorkBuddy 生成的代码是通用模板你需要把它变成你自己的。比如config.py里它给了一个默认的SECRET_KEY我改成了自己生成的一串随机字符这个密钥用于会话加密不能泄露。2.3 SQLite 数据库文件的位置与初始化SQLite 的数据库就是一个文件位置很关键。我把它放在instance/blog.db然后在config.py里这样配置import os BASE_DIR os.path.dirname(os.path.abspath(__file__)) class Config: SECRET_KEY 你生成的一串随机字符 DATABASE os.path.join(BASE_DIR, instance, blog.db)然后在app/models/db.py里写获取数据库连接的函数import sqlite3 from flask import current_app, g def get_db(): if db not in g: g.db sqlite3.connect( current_app.config[DATABASE], detect_typessqlite3.PARSE_DECLTYPES ) g.db.row_factory sqlite3.Row return g.db def close_db(eNone): db g.pop(db, None) if db is not None: db.close()这里用了 Flask 的g对象它是在一次请求周期内共享的。row_factory sqlite3.Row这一行很重要它让查询结果可以像字典一样用列名访问而不是只能用索引。detect_types参数让 SQLite 能自动把时间戳字段转成 Python 的datetime对象省去手动转换的麻烦。初始化数据库的脚本我单独写了一个init_db.pyimport sqlite3 from config import Config def init_db(): conn sqlite3.connect(Config.DATABASE) with open(schema.sql, r, encodingutf-8) as f: conn.executescript(f.read()) conn.commit() conn.close() if __name__ __main__: init_db()schema.sql里放建表语句这个我让 WorkBuddy 根据我的字段需求生成然后自己调整。文章表的结构大概是这样CREATE TABLE IF NOT EXISTS article ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, content TEXT NOT NULL, summary TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );AUTOINCREMENT保证 id 单调递增DEFAULT CURRENT_TIMESTAMP让插入时自动填时间省去手动传时间戳。summary字段用于列表页展示摘要避免每次都把全文查出来。3. 核心功能开发与日更流程落地3.1 文章发布与展示的完整链路日更的核心就是“发布”和“展示”两个动作。发布是往数据库写展示是从数据库读。我先说发布。发布功能我一开始想做个后台管理页面但后来发现对于日更场景直接在本地跑一个脚本更快。我写了一个publish.py运行的时候从命令行参数或者交互式输入里拿标题和内容然后插入数据库import sqlite3 from datetime import datetime from config import Config def publish_article(title, content, summary): conn sqlite3.connect(Config.DATABASE) cursor conn.cursor() cursor.execute( INSERT INTO article (title, content, summary, created_at, updated_at) VALUES (?, ?, ?, ?, ?), (title, content, summary, datetime.now(), datetime.now()) ) conn.commit() conn.close() print(f文章《{title}》发布成功) if __name__ __main__: title input(标题) content input(内容) summary input(摘要可留空) publish_article(title, content, summary)这里用了参数化查询?占位符这是防止 SQL 注入的基本操作绝对不能把用户输入直接拼接到 SQL 字符串里。datetime.now()手动传入而不是依赖数据库默认值是因为我想在 Python 层面控制时间格式方便后续做时区处理。展示部分就是 Flask 路由加模板渲染。文章列表页的路由from flask import Blueprint, render_template from app.models.db import get_db bp Blueprint(article, __name__) bp.route(/articles) def article_list(): db get_db() articles db.execute( SELECT id, title, summary, created_at FROM article ORDER BY created_at DESC ).fetchall() return render_template(article_list.html, articlesarticles) bp.route(/article/int:id) def article_detail(id): db get_db() article db.execute( SELECT * FROM article WHERE id ?, (id,) ).fetchone() if article is None: abort(404) return render_template(article_detail.html, articlearticle)列表页只查需要的字段不查content这样数据量大了之后列表页依然很快。详情页用fetchone()拿单条拿不到就返回 404。模板里用 Jinja2 的循环和变量替换这部分 WorkBuddy 生成的模板基本能用我主要调整了样式和布局。3.2 用 DB Browser for SQLite 做数据核对虽然我可以用命令行查数据库但日更的时候经常需要快速核对数据比如确认某篇文章有没有写进去、时间对不对。这时候DB Browser for SQLite就派上用场了。它是一个图形化的 SQLite 客户端打开数据库文件就能看到所有表和数据还能直接执行 SQL。我的习惯是每天发布完文章后用 DB Browser 打开blog.db看一眼article表的最新几条记录确认标题、时间、摘要都正确。这个动作花不了十秒钟但能避免“以为发出去了其实没发成功”的尴尬。提示DB Browser for SQLite 在 Windows、macOS、Linux 上都有官网直接下载安装包就行。打开数据库文件的时候记得先关掉正在运行的 Flask 服务虽然 SQLite 支持并发读但写入的时候可能会锁文件。另外DB Browser 还能用来做数据导出。比如我想把文章数据导出成 CSV 做备份直接用它自带的导出功能就行不用写代码。这个工具对于不熟悉命令行的朋友特别友好强烈建议装一个。3.3 日更节奏下的自动化小技巧日更最怕的就是流程太繁琐繁琐就会拖延拖延就会断更。所以我把发布流程尽量简化。除了上面说的publish.py脚本我还加了一个小功能从 Markdown 文件批量导入。因为我平时写草稿习惯用 Markdown写完之后直接跑一个脚本把文件内容读出来插进数据库连复制粘贴都省了。import sqlite3 import os from datetime import datetime from config import Config def import_from_markdown(filepath): with open(filepath, r, encodingutf-8) as f: content f.read() filename os.path.basename(filepath) title os.path.splitext(filename)[0] summary content[:100].replace(\n, ) conn sqlite3.connect(Config.DATABASE) cursor conn.cursor() cursor.execute( INSERT INTO article (title, content, summary, created_at, updated_at) VALUES (?, ?, ?, ?, ?), (title, content, summary, datetime.now(), datetime.now()) ) conn.commit() conn.close() print(f已导入{title}) if __name__ __main__: import_from_markdown(drafts/today.md)这个脚本把文件名当标题把内容前 100 个字符当摘要一键导入。我每天写完草稿保存成drafts/日期.md然后跑一下脚本文章就进库了。整个过程不到一分钟。还有一个技巧是给文章加一个“草稿”状态字段。有时候文章没写完但想先存着就可以先插入一条statusdraft的记录列表页查询的时候加个WHERE statuspublished过滤掉草稿。等写完了再更新状态。这个字段我后来加上了确实方便。4. 部署上线与常见问题排查4.1 从本地到服务器的部署路径本地跑通之后下一步就是部署到服务器上让站点能被外部访问。我用的是一台最低配的云服务器系统是 Ubuntu。部署 Flask 应用不能直接用flask run那个是开发服务器性能和稳定性都不够。生产环境我用的是Gunicorn Nginx的组合。Gunicorn 是 Python 的 WSGI 服务器负责跑 Flask 应用Nginx 作为反向代理负责处理静态文件、转发请求给 Gunicorn。安装很简单pip install gunicorn sudo apt install nginx启动 Gunicorn 的命令gunicorn -w 2 -b 127.0.0.1:8000 run:app-w 2表示两个 worker 进程对于低配机器足够了。run:app表示从run.py里导入app对象。然后配置 Nginx把 80 端口的请求转发到 8000 端口server { listen 80; server_name your_domain.com; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /static/ { alias /path/to/your/app/static/; } }静态文件交给 Nginx 直接处理不经过 Flask这样能减轻应用服务器的压力。配置完之后sudo nginx -s reload重载配置。注意SQLite 数据库文件在部署后要注意权限问题。Gunicorn 运行的用户必须对instance/blog.db有读写权限否则会报“unable to open database file”。我一开始就踩了这个坑后来把数据库文件的所有者改成运行 Gunicorn 的用户就好了。4.2 常见报错与排查速查表建站过程中我遇到了不少报错这里整理成一张速查表方便你遇到类似问题时快速定位。报错信息可能原因解决方法ModuleNotFoundError: No module named flask虚拟环境没激活或没装 Flask激活虚拟环境后pip install flasksqlite3.OperationalError: unable to open database file数据库路径错误或权限不足检查config.py里的路径确认文件权限jinja2.exceptions.TemplateNotFound模板文件不在templates目录确认模板路径和文件名大小写sqlite3.IntegrityError: NOT NULL constraint failed插入时必填字段为空检查插入语句是否漏了字段Address already in use端口被占用换端口或杀掉占用进程502 Bad GatewayGunicorn 没启动或崩溃检查 Gunicorn 日志确认应用能正常导入页面样式丢失Nginx 静态文件路径配错检查location /static/的alias路径这张表里的每一条都是我实际遇到过的。其中502 Bad Gateway最让人头疼因为 Nginx 只告诉你网关错误具体原因要看 Gunicorn 的日志。我的习惯是先用gunicorn run:app直接在前台跑一下看有没有报错确认应用本身没问题再放到后台。4.3 数据备份与迁移的实操经验SQLite 最大的优势就是备份简单复制文件就行。但复制的时候要注意如果数据库正在被写入直接复制可能会得到一个损坏的文件。正确的做法是先停掉应用或者用 SQLite 自带的备份命令sqlite3 blog.db .backup backup.db这个命令会在数据库运行时创建一个一致性快照不会因为并发写入导致备份文件损坏。我设置了一个定时任务每天凌晨跑一次备份备份文件按日期命名保留最近 30 天。迁移就更简单了把blog.db文件拷到新服务器上配好环境启动应用就行。不需要导出 SQL、不需要重建表结构一个文件搞定。这也是我当初选 SQLite 的重要原因之一。提示如果你的站点数据量增长到几万篇文章SQLite 的读取性能依然没问题但写入可能会开始变慢。这时候可以考虑加索引比如在created_at字段上建索引加速列表页的排序查询。建索引的语句是CREATE INDEX idx_created_at ON article(created_at DESC);。5. 我踩过的坑和几条实在建议5.1 关于 WorkBuddy 生成代码的使用心得WorkBuddy 生成的代码质量整体不错但有几个地方需要特别注意。第一它有时候会用一些较新的 Python 语法比如海象运算符:或者 f-string 的嵌套如果你的 Python 版本比较旧就会报语法错误。我的做法是生成之后先扫一眼看到不熟悉的语法就查一下版本要求。第二它生成的 SQL 语句有时候没有加IF NOT EXISTS重复执行会报错。建表语句我一般会手动加上IF NOT EXISTS这样初始化脚本可以反复跑不会因为表已存在而中断。第三它生成的 Flask 路由有时候缺少错误处理。比如查询单条记录的时候没有判断None直接拿结果去渲染模板数据不存在就会报错。我养成了一个习惯凡是fetchone()的地方后面必跟一个if xxx is None的判断。这个习惯帮我避免了很多 500 错误。5.2 日更站点的内容管理策略日更最难的不是技术是坚持。技术上的顺畅能降低坚持的难度但内容本身的规划也很重要。我的策略是提前攒一批草稿状态设为draft每天从草稿里挑一篇发布。这样即使某天特别忙也不会断更。另外我给文章加了一个tags字段用逗号分隔存多个标签。列表页可以按标签筛选详情页展示相关文章。这个功能不复杂但能提升站点的可浏览性。实现方式就是在查询的时候加一个WHERE tags LIKE %xxx%的条件虽然不够优雅但对于小规模数据完全够用。还有一点文章的updated_at字段我一开始没怎么用后来发现有时候会修改已发布的文章这时候更新updated_at能让读者知道内容有更新。所以每次更新文章内容的时候记得把updated_at也一起更新。5.3 性能与安全上的几个关键注意点性能方面SQLite 在读取为主的场景下表现很好但有几个地方要注意。第一每次请求都创建新的数据库连接是有开销的我用 Flask 的g对象做了请求级别的连接复用请求结束自动关闭。第二列表页一定要分页不能一次性把所有文章查出来。我用的LIMIT和OFFSET做分页每页 20 条。安全方面除了前面说的参数化查询防注入还有几点。第一SECRET_KEY绝对不能硬编码在代码里提交到公开仓库我是通过环境变量读取的。第二用户输入的内容在渲染到模板之前Jinja2 默认会转义 HTML所以不用担心 XSS但如果你用了|safe过滤器就要确保内容是你自己可控的。第三生产环境一定要关掉 Flask 的调试模式debugTrue会暴露源代码和堆栈信息非常危险。最后说一个我个人的体会这套技术栈最大的价值在于“可控”。从数据库文件到应用代码每一层我都能看懂、能改、能迁移。不像用托管平台出了问题只能等客服想加个功能要看平台支不支持。如果你也想做一个自己能完全掌控的日更站点Flask SQLite 这条路值得走一遍。