1. 为什么我选择 WorkBuddy Flask SQLite 这套组合1.1 从“想做个站”到“真的跑起来”之间差了什么很多人第一次冒出“自己建个站”的念头往往是因为看到了某个很酷的页面或者手里有一批想展示的数据。但真动手的时候问题就来了域名怎么弄、服务器买哪家、环境怎么配、数据库怎么连、前端后端怎么对接……每一步都能卡住人。我见过太多人卡在“环境配置”这一步就放弃了甚至连 Python 都没装明白。WorkBuddy 这个工具吸引我的地方是它把“建站”这件事从“搭环境、写配置、调依赖”的泥潭里拽了出来。它更像是一个工作台你告诉它你要做什么它帮你把项目骨架、依赖关系、甚至部分业务逻辑都理清楚。但工具再好底层的东西你得懂——不然出了问题你连从哪查都不知道。所以我选的是 WorkBuddy 做效率工具Flask 做 Web 框架SQLite 做数据存储。这套组合的好处是轻、快、可控。Flask 本身足够简单一个文件就能跑起来一个 Web 服务SQLite 不需要单独装数据库服务一个文件就是整个库WorkBuddy 则帮你把重复性的代码生成和项目管理工作接过去。这套方案适合谁适合有一点 Python 基础、想快速验证一个想法、不想在运维上花太多时间的人。如果你连 Python 都没装过也没关系后面我会把安装和配置的每一步都拆开讲。但如果你期望的是“一键生成一个淘宝”那这套方案不适合你——它更适合做中小型的信息展示、数据管理、内部工具类的站点。1.2 为什么不是 WordPress 或 Shopify这里得说清楚一个选型逻辑。WordPress 和 Shopify 都是非常成熟的建站方案但它们的定位和 Flask 自建站完全不同。WordPress 本质上是“内容管理系统”你装好之后得到的是一个已经成型的博客/企业站框架你要做的是“往里填内容”和“装插件”。Shopify 更垂直它是电商 SaaS你租的是它的服务数据在它那里你按月付费。而 Flask SQLite 自建站你得到的是一个“空白的画布”。你要自己定义数据表、自己写路由、自己设计页面。听起来更麻烦但换来的是完全的控制权和零平台依赖。你的数据在你自己的机器上你的代码你想怎么改就怎么改不需要看任何平台的脸色。对于“日更”这种需要频繁调整内容结构和展示逻辑的场景自建站的灵活性优势非常明显。WorkBuddy 在这中间扮演的角色是帮你把“画布”准备好把画笔和颜料摆好甚至帮你画好草稿线。但最终画成什么样还是你说了算。1.3 日更场景对技术栈的特殊要求“日更”这个词听起来简单但对技术栈的要求其实不低。每天都要更新内容意味着你的发布流程必须足够短——如果每次更新都要折腾半小时环境那肯定坚持不下去。所以技术栈必须满足几个条件启动快、改起来快、数据写入快、不容易崩。Flask 的轻量特性在这里很关键。一个典型的 Flask 应用启动只需要几百毫秒你改完代码保存服务自动重载刷新页面就能看到效果。SQLite 的写入速度对于日更级别的数据量来说绰绰有余单条插入通常在毫秒级。WorkBuddy 则可以在你每次新增内容类型时快速生成对应的模型、路由和模板骨架省去大量重复劳动。我实测下来从打开电脑到发布一篇新内容整个流程可以压缩到 3 分钟以内。这个效率是支撑“日更”这个习惯的技术基础。2. 环境搭建从零到跑通第一个页面2.1 Python 安装与虚拟环境配置不管你用 Windows、macOS 还是 Linux第一步都是把 Python 装好。我建议直接去 Python 官网下载 3.10 或以上的版本安装时务必勾选“Add Python to PATH”——这个选项在 Windows 上尤其重要不勾的话后面命令行里敲python会提示找不到命令。装完之后验证一下python --version如果显示的是 3.10 以上的版本号就说明装好了。接下来是虚拟环境。虚拟环境的作用是把你这个项目的依赖和系统里其他 Python 包隔离开避免版本冲突。操作很简单python -m venv venv这会在当前目录下创建一个叫venv的文件夹。然后激活它Windows:venv\Scripts\activatemacOS/Linux:source venv/bin/activate激活之后命令行前面会出现(venv)的标识。以后每次开发前都要先激活虚拟环境这是一个必须养成的习惯。注意虚拟环境文件夹不要提交到代码仓库也不要手动去改里面的文件。它就是一个隔离层坏了就删掉重建。2.2 Flask 与 SQLite 的依赖安装虚拟环境激活后安装 Flaskpip install flaskSQLite 不需要单独安装Python 标准库自带sqlite3模块。但如果你想要一个图形化的工具来查看和编辑数据库文件我强烈推荐DB Browser for SQLite。这个工具可以让你像用 Excel 一样查看表结构、浏览数据、执行 SQL 语句对于调试和日常维护非常方便。如果你还想用 ORM对象关系映射来操作数据库可以装 Flask-SQLAlchemypip install flask-sqlalchemyORM 的好处是你不用手写 SQL用 Python 类的方式就能定义表和查询。但代价是多了一层抽象出问题的时候排查起来会稍微麻烦一点。我的建议是初期用原生 SQL 先把逻辑跑通等业务复杂了再考虑上 ORM。2.3 WorkBuddy 的安装与初始化项目WorkBuddy 的安装方式取决于你用的版本。国际版和国内版的安装流程略有差异但核心逻辑是一样的下载安装包、运行安装程序、登录账号、创建项目。安装完成后你可以在 WorkBuddy 里新建一个项目选择 Flask 作为项目类型它会自动生成一个标准的 Flask 项目结构myproject/ ├── app.py ├── templates/ ├── static/ ├── requirements.txt └── instance/这个结构里app.py是主入口templates放 HTML 模板static放 CSS/JS/图片instance通常用来放数据库文件。WorkBuddy 还会帮你生成一个基础的requirements.txt里面列出了项目依赖。提示WorkBuddy 生成的项目结构是一个起点不是终点。你可以根据自己的需要调整目录比如把路由拆成多个文件、把模型单独放一个目录。但初期建议先保持简单一个app.py能跑通所有功能就够了。2.4 跑通第一个 Hello World 页面在app.py里写一个最简单的路由from flask import Flask app Flask(__name__) app.route(/) def index(): return Hello, WorkBuddy! if __name__ __main__: app.run(debugTrue)然后在命令行里运行python app.py你会看到类似这样的输出* Running on http://127.0.0.1:5000打开浏览器访问这个地址如果看到 “Hello, WorkBuddy!”说明环境已经跑通了。这一步看起来简单但它是后面所有功能的基础。如果这一步卡住了后面的都不用谈。3. 数据库设计用 SQLite 存什么、怎么存3.1 日更内容的数据表结构设计日更站点的核心数据就是“内容”。一条内容通常包含这些字段标题、正文、发布时间、更新时间、标签、状态草稿/已发布。用 SQLite 建表的话SQL 语句大概长这样CREATE TABLE IF NOT EXISTS posts ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, content TEXT NOT NULL, tags TEXT DEFAULT , status TEXT DEFAULT draft, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );这里有几个设计决策值得说明。id用INTEGER PRIMARY KEY AUTOINCREMENT是 SQLite 的标准自增主键写法。status字段用文本来存状态而不是用数字是为了可读性——你直接看数据库就能明白这条是草稿还是已发布。created_at和updated_at用TIMESTAMP类型并设置默认值这样插入数据时不需要手动传时间。如果你还要存标签的关联关系可以再加一张标签表和一张关联表。但初期建议先用逗号分隔的文本存标签简单直接查询的时候用LIKE就能模糊匹配。等标签数量多了再考虑拆表。3.2 用 DB Browser 管理数据库文件DB Browser for SQLite 的使用非常直观。打开软件后点击“打开数据库”选择你的.db文件就能看到所有的表。你可以直接在界面上执行 SQL、浏览数据、导出 CSV。对于日更场景我经常用它来快速检查某条内容是否写入成功或者手动修正一些数据。有一个细节要注意Flask 应用运行的时候数据库文件是被占用的。如果你在 DB Browser 里修改了数据Flask 那边不一定能立刻看到变化因为 SQLite 有缓存机制。反过来如果 Flask 正在写入DB Browser 可能会提示数据库被锁定。所以建议在修改数据库之前先把 Flask 服务停掉。3.3 数据库文件的存放位置与备份策略SQLite 数据库就是一个文件所以备份极其简单——复制文件就行。但要注意存放位置。我习惯把它放在项目的instance目录下然后在app.py里用绝对路径来引用import os BASE_DIR os.path.dirname(os.path.abspath(__file__)) DB_PATH os.path.join(BASE_DIR, instance, site.db)这样不管你在哪个目录下运行python app.py数据库路径都是正确的。备份的话我设置了一个简单的定时任务每天凌晨把.db文件复制到一个带日期的备份目录里。对于日更站点这个操作能救命——万一哪天误删了数据至少还有昨天的备份。注意SQLite 不支持多进程同时写入。如果你的 Flask 应用用了多进程模式比如 gunicorn 的多个 worker写入操作可能会冲突。对于日更这种低并发场景用单进程就够了。4. 核心功能实现从发布到展示的完整链路4.1 发布页面的表单设计与后端接收发布页面就是一个 HTML 表单包含标题输入框、正文文本域、标签输入框和提交按钮。用 Flask 的render_template渲染模板用request.form接收数据。关键代码如下from flask import Flask, render_template, request, redirect, url_for import sqlite3 app.route(/publish, methods[GET, POST]) def publish(): if request.method POST: title request.form[title] content request.form[content] tags request.form.get(tags, ) conn sqlite3.connect(DB_PATH) cursor conn.cursor() cursor.execute( INSERT INTO posts (title, content, tags, status) VALUES (?, ?, ?, ?), (title, content, tags, published) ) conn.commit() conn.close() return redirect(url_for(index)) return render_template(publish.html)这里用?占位符来传参数而不是直接拼接字符串是为了防止 SQL 注入。这是一个必须遵守的安全习惯不管你的站点是不是只有自己用。4.2 首页列表与详情页的路由拆分首页展示所有已发布内容的列表按时间倒序排列。详情页根据id展示单条内容。路由设计如下app.route(/) def index(): conn sqlite3.connect(DB_PATH) cursor conn.cursor() cursor.execute(SELECT id, title, tags, created_at FROM posts WHERE statuspublished ORDER BY created_at DESC) posts cursor.fetchall() conn.close() return render_template(index.html, postsposts) app.route(/post/int:post_id) def detail(post_id): conn sqlite3.connect(DB_PATH) cursor conn.cursor() cursor.execute(SELECT * FROM posts WHERE id?, (post_id,)) post cursor.fetchone() conn.close() return render_template(detail.html, postpost)列表页只查需要的字段不要SELECT *这样可以减少数据传输量。详情页才查全部字段。这是一个小优化但在数据量大了之后效果明显。4.3 用 WorkBuddy 生成模板骨架并微调WorkBuddy 可以根据你的数据表结构自动生成对应的 HTML 模板骨架。比如你告诉它“我有一个 posts 表字段是 title、content、tags、created_at”它就能生成一个包含这些字段的列表页和详情页模板。生成出来的模板通常比较朴素但结构是对的。你只需要在它的基础上调整 CSS 样式、加上导航栏、调整布局就行。我一般会保留 WorkBuddy 生成的模板结构只改static目录下的 CSS 文件。这样下次重新生成模板时样式不会丢。模板里用 Jinja2 语法来循环和判断{% for post in posts %} div classpost-item h2a href{{ url_for(detail, post_idpost[0]) }}{{ post[1] }}/a/h2 span classdate{{ post[3] }}/span /div {% endfor %}4.4 日更流程的自动化脚本日更的核心痛点是“每天都要手动操作一遍”。为了减少重复劳动我写了一个简单的 Python 脚本用命令行参数传入标题和内容自动写入数据库import sqlite3 import sys from datetime import datetime def add_post(title, content, tags): conn sqlite3.connect(instance/site.db) cursor conn.cursor() cursor.execute( INSERT INTO posts (title, content, tags, status, created_at) VALUES (?, ?, ?, ?, ?), (title, content, tags, published, datetime.now().strftime(%Y-%m-%d %H:%M:%S)) ) conn.commit() conn.close() print(f已发布: {title}) if __name__ __main__: add_post(sys.argv[1], sys.argv[2], sys.argv[3] if len(sys.argv) 3 else )用的时候直接python add_post.py 今日标题 今日正文内容 标签1,标签2这个脚本配合 WorkBuddy 的自定义指令功能可以进一步简化。比如在 WorkBuddy 里设置一个指令输入标题和内容后自动调用这个脚本并刷新页面。5. 部署与日常维护让站点稳定跑起来5.1 本地部署与局域网访问开发阶段用app.run(debugTrue)就够了但它默认只监听127.0.0.1也就是只有本机能访问。如果你想让局域网内的其他设备也能访问需要改成app.run(host0.0.0.0, port5000, debugTrue)这样同一网络下的手机、平板就能通过你的电脑 IP 访问了。但要注意debugTrue在生产环境下必须关掉因为它会暴露调试信息有安全风险。5.2 生产环境下的启动方式生产环境建议用 gunicorn 或 waitress 来启动 Flask 应用。gunicorn 在 Linux/macOS 上表现很好gunicorn -w 1 -b 0.0.0.0:5000 app:app注意这里-w 1表示只用一个 worker 进程这是为了避免 SQLite 的写入冲突。waitress 则是 Windows 上的好选择waitress-serve --listen0.0.0.0:5000 app:app这两个命令都会让应用在后台稳定运行不会因为终端关闭而停止。5.3 数据备份与迁移的实操方法备份就是复制.db文件。迁移的话把整个项目目录打包带走就行包括app.py、templates、static和instance目录。到了新机器上装好 Python 和依赖直接运行就能恢复。SQLite 的这种“文件即数据库”的特性让迁移变得极其简单。但有一个坑要注意不同操作系统下的路径分隔符不同。如果你在 Windows 上开发然后迁移到 Linux 上代码里的路径要用os.path.join来拼接不要硬编码反斜杠。5.4 常见故障排查速查表问题现象可能原因解决方法启动报错ModuleNotFoundError: No module named flask虚拟环境没激活或 Flask 没装激活虚拟环境后重新pip install flask页面显示Internal Server Error代码有异常查看终端报错信息定位到具体行数据库写入后查不到数据没有commit()在execute后加上conn.commit()数据库被锁定多个进程同时写入确保只有一个进程在写或改用 WAL 模式模板找不到templates目录位置不对确保templates在项目根目录下静态文件 404static目录位置不对或路径写错用url_for(static, filename...)生成路径提示SQLite 的 WAL 模式可以提升并发读的性能开启方式是在连接后执行PRAGMA journal_modeWAL;。对于日更站点这个优化不是必须的但开了也没坏处。6. 我踩过的坑和实测有效的经验6.1 数据库连接忘记关闭导致的问题最开始写代码的时候我经常忘记conn.close()。短时间看不出问题但跑久了之后数据库文件会被锁定新的写入操作全部失败。后来我养成了一个习惯用with语句来管理数据库连接with sqlite3.connect(DB_PATH) as conn: cursor conn.cursor() cursor.execute(...)with语句会在代码块结束时自动提交并关闭连接省心很多。但要注意with只保证提交不保证关闭。更稳妥的做法是配合contextlib.closing使用。6.2 中文内容在 SQLite 中的编码问题SQLite 默认使用 UTF-8 编码存中文没有问题。但如果你在 Windows 上用命令行工具查看数据库可能会看到乱码。这不是数据库的问题是终端编码的问题。用 DB Browser 查看就正常了。另外在 Python 里连接数据库时确保文件是以 UTF-8 打开的不要用gbk之类的编码。6.3 WorkBuddy 生成代码后的必要检查项WorkBuddy 生成的代码质量整体不错但有几个地方我每次都会检查数据库路径是否正确、路由函数名是否重复、模板变量名是否和视图函数传的一致。特别是变量名WorkBuddy 有时候会生成post_list但模板里写的是posts这种不一致会导致页面渲染失败。花两分钟检查一遍比出了错再回头找要快得多。6.4 日更习惯的维持技巧技术问题解决之后最大的挑战其实是“坚持每天更新”。我的经验是把发布流程缩短到 3 分钟以内。如果每次发布都要打开编辑器、改代码、重启服务那肯定坚持不下去。用前面说的命令行脚本配合 WorkBuddy 的快捷指令可以把发布变成“输入标题、输入内容、回车”三步。另外提前准备好一周的素材不要等到当天才想写什么。素材可以是读书笔记、工作复盘、看到的好文章摘录任何你觉得有价值的东西都可以。6.5 从单机到多端同步的扩展思路如果你在多台设备上工作想把 SQLite 数据库同步起来最简单的办法是用云盘同步instance目录。但要注意云盘同步和 SQLite 写入同时进行时可能会冲突。更稳妥的做法是写一个简单的同步脚本在每次发布后把.db文件上传到云盘在其他设备上手动下载覆盖。或者干脆把数据库放在一台常开的机器上其他设备通过局域网访问 Flask 服务。这个站点后续还可以扩展的方向很多加一个搜索功能、加 RSS 输出、加标签筛选、加评论模块。但我的建议是先把日更跑通一个月再考虑加功能。很多站点不是死于功能太少而是死于维护者坚持不下去。