从零搭建数据展示站：Flask+SQLite+WorkBuddy实战复盘

1. 从零建站这件事为什么我选了 WorkBuddy 加 Flask 这套组合去年年底我接手了一个挺有意思的私活帮一个做农产品批发的朋友搭一套价格数据展示站。需求说起来不复杂把每天从几个渠道抓到的价格数据存下来做一个能看趋势、能查历史、能按品类筛选的网页最好还能每天自动更新。预算不多时间也紧我前后试了三套方案最后落地用的是 WorkBuddy 配合 Flask 加 SQLite 这套组合从零到上线大概花了四天之后日更跑了三个多月没出过大问题。这篇文章就是把这套流程完整复盘一遍。我会讲清楚为什么在 WordPress、Shopify 和自建站之间我选了自建为什么后端用 Flask 而不是 Django 或者 FastAPI为什么数据库用 SQLite 而不是 MySQL以及 WorkBuddy 在整个链路里到底扮演什么角色。适合谁看如果你有一点 Python 基础想自己动手搭一个轻量级的数据展示站或者工具站又不想被各种建站平台的模板和月费绑死那这篇应该能帮你少走不少弯路。如果你是完全零基础也没关系我会把 Python 安装、环境配置、数据库可视化工具这些基础环节都带上照着做基本能跑通。先说结论性的选型逻辑。WordPress 建站教程网上一抓一大把生态确实成熟插件多主题多但它本质是内容管理系统做数据展示要装一堆插件性能和维护成本会随着数据量上涨而变高。Shopify 更适合电商卖货做数据可视化属于杀鸡用牛刀而且月费不便宜。自建站的好处是每一行代码你都能控制数据怎么存、页面怎么渲染、接口怎么设计全在自己手里。对于这种数据为主、展示为辅的场景自建是最合适的。那为什么是 Flask 而不是 DjangoDjango 功能全自带 admin 后台和 ORM但它的重量级对于一个小型数据站来说有点浪费学习曲线也陡。Flask 是微框架核心精简需要什么装什么路由和模板系统足够用配合 SQLite 几乎零配置就能跑起来。SQLite 更不用多说单文件数据库不需要单独起服务备份就是复制一个文件对于日更量级的数据完全够用。WorkBuddy 在这里的作用是帮我处理建站过程中的重复性工作和日常运维比如生成页面骨架、跑数据更新脚本、做定时任务它更像一个工作台把零散的操作串成流程。2. 环境准备Python、SQLite 和可视化工具一次配齐2.1 Python 安装与环境隔离的正确姿势Python 安装教程网上很多但很多人装完就踩坑问题基本出在两个地方一是版本选错二是没做环境隔离。我建议直接上 Python 3.10 或 3.11这两个版本对 Flask 和各类库的兼容性最稳。3.12 虽然新但有些第三方库还没跟上新手容易卡在依赖安装上。Windows 用户去官网下载安装包时记得勾选Add Python to PATH这一步漏了后面命令行里敲 python 会提示找不到命令。Mac 用户如果用 Homebrew一条brew install python3.11就搞定。装完之后第一件事不是急着 pip install而是建虚拟环境。我见过太多人把所有包装在全局环境里结果项目 A 和项目 B 的依赖版本打架排查半天。虚拟环境的逻辑很简单就是给每个项目一个独立的包目录互不干扰。操作如下# 进入项目目录 cd workbuddy-site # 创建虚拟环境 python -m venv venv # 激活Windows venv\Scripts\activate # 激活Mac/Linux source venv/bin/activate激活后命令行前面会出现(venv)标识这时候再装包就只影响当前项目。VSCode Python 环境配置也是同样的道理在 VSCode 里按 CtrlShiftP输入Python: Select Interpreter选中你刚建的 venv 里的 python 就行。这一步做完后面装 Flask 和 SQLite 相关库就不会污染系统环境。提示虚拟环境目录不要提交到代码仓库在 .gitignore 里加上 venv/ 这一行否则仓库会变得又大又乱。2.2 SQLite 的安装与 DB Browser 可视化SQLite 最大的好处是它通常不需要单独安装Python 标准库自带 sqlite3 模块直接 import 就能用。但如果你想要一个图形化界面来查看和编辑数据就得装一个可视化工具。我用的是 DB Browser for SQLite免费开源跨平台Windows、Mac、Linux 都有。下载安装后打开直接指向你的 .db 文件就能看到所有表和数据改数据、跑 SQL、导出 CSV 都很方便。为什么强调可视化工具因为纯命令行操作数据库调试的时候效率太低。比如你想确认某条数据有没有写进去命令行要敲一串 select可视化工具点两下就看到了。特别是做农产品价格数据可视化这种场景数据表字段多用 DB Browser 看结构一目了然。安装完之后建议做一件事把数据库文件放在项目目录下的 instance 文件夹里Flask 默认会去那里找路径清晰不容易乱。Android Studio 里也有 SQLite 的可视化工具如果你做移动端开发可能用得上但咱们这个 Web 项目用 DB Browser 就够了。另外提一句SQLite 数据库文件能否加密这个问题经常有人问答案是标准 SQLite 不直接支持加密需要用到 SQLCipher 这类扩展。对于内部使用的数据站我的建议是别折腾加密把服务器访问权限管好更实际。2.3 WorkBuddy 的安装与基础配置WorkBuddy 安装教程这块不同平台略有差异。Linux 和 Ubuntu 用户一般通过包管理器或者官方脚本安装Windows 和 Mac 有对应的安装包。装完之后第一件事是配置工作目录和自定义指令。WorkBuddy 的核心价值在于它能把你重复执行的操作定义成 skill比如拉取数据并写入数据库、生成当日页面、检查站点状态这些定义一次之后每天调用就行。WorkBuddy 自定义指令推荐从最简单的开始别一上来就搞复杂流程。我的做法是先手动把整个建站和更新流程跑一遍把每一步的命令记下来然后再把这些命令封装成 WorkBuddy 的 skill。这样封装出来的流程是经过验证的不会出现指令写好了但跑不通的情况。WorkBuddy 工作台里可以管理这些 skill 的执行记录哪天数据没更新翻一下执行日志就知道卡在哪一步。注意WorkBuddy 和 CodeBuddy 经常被放在一起比较简单说 CodeBuddy 偏代码生成和辅助编程WorkBuddy 偏工作流编排和任务执行。建站阶段两者可以配合用日常运维主要靠 WorkBuddy。3. 项目整体设计与技术选型拆解3.1 为什么是 Flask 而不是其他框架Flask 框架的核心设计哲学是微它只提供路由、请求响应、模板渲染这些最基础的能力数据库、表单验证、用户认证统统交给扩展。这种设计对于小型项目特别友好因为你不需要为用不到的功能买单。我这个农产品价格站核心功能就三个展示价格列表、按品类筛选、看趋势图。用 Flask 大概两百行代码就能搞定换成 Django 光配置文件和目录结构就得先铺一堆。Flask 如何绑定到网页元素这个问题本质是模板渲染和前端交互。Flask 用 Jinja2 做模板引擎后端把数据传给模板模板里用{{ }}和{% %}语法把数据填到 HTML 里。如果要动态交互比如点击品类筛选不刷新页面那就配合一点 JavaScriptFlask 提供 JSON 接口前端 fetch 拿数据再渲染。这套组合灵活度很高你想简单就服务端渲染想复杂就前后端分离不会被框架绑死。Flask 查看从客户端获取的变量数据类型也是个常见需求。比如前端传过来的价格是字符串还是数字直接决定你入库时要不要转换。Flask 里用request.args.get(price)拿到的一律是字符串需要自己用float()或int()转。调试的时候我会在视图函数里加一行print(type(price), price)确认类型没问题再往下走。这种小习惯能省掉很多数据存进去变成乱码的排查时间。3.2 SQLite 的定位与数据表设计SQLite 数据库在这个项目里承担的是持久化存储的角色。它的优势前面说了单文件、零配置、备份简单。但也要清楚它的边界并发写入能力弱不适合高并发场景。日更数据站每天写入量就几百条读取量也不大SQLite 完全扛得住。如果哪天数据量涨到百万级、并发上百那就该考虑换 PostgreSQL 了但那是后话。数据表设计我用了三张表品类表、价格记录表、抓取日志表。品类表存农产品名称和分类价格记录表存每天的价格、日期、品类 ID抓取日志表记录每次抓取的时间、条数、状态。这样设计的好处是数据职责清晰查历史价格用价格表排查抓取问题看日志表。SQLite update 语句在修正数据时很有用比如某天抓取的价格有误直接 update 改掉就行不用删了重插。-- 价格记录表结构示例 CREATE TABLE price_record ( id INTEGER PRIMARY KEY AUTOINCREMENT, category_id INTEGER NOT NULL, price REAL NOT NULL, record_date TEXT NOT NULL, created_at TEXT DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (category_id) REFERENCES category(id) );字段类型选择上价格用 REAL 而不是 TEXT方便后面做统计和排序。日期用 TEXT 存 ISO 格式SQLite 没有专门的日期类型TEXT 存 2024-01-15 这种格式排序和比较都没问题。这些细节看着小但直接影响后面查询语句好不好写。3.3 WorkBuddy 在建站流程中的角色定位WorkBuddy 在这套方案里不是替代 Flask 或 SQLite而是把整个流程串起来的胶水。建站阶段我用它来管理代码生成和文件组织运维阶段我用它来跑每日数据更新和站点健康检查。举个具体例子每天凌晨我要做四件事跑爬虫抓数据、清洗后写入 SQLite、重新生成静态页面、检查站点能否访问。这四步手动做要十几分钟封装成 WorkBuddy skill 之后一条指令自动跑完出问题会记录日志。WorkBuddy skill 的设计原则是单一职责一个 skill 只做一件事。抓取是一个 skill入库是一个 skill生成页面是一个 skill检查是一个 skill。这样哪个环节出问题一目了然也方便单独重跑。如果把它们揉成一个大 skill中间某步失败就得从头再来浪费时间。这个经验是我踩过坑之后总结的一开始图省事写了个大流程结果爬虫偶尔超时导致整个流程重跑数据还重复写入了。4. 核心实操从数据库到页面的完整链路4.1 数据抓取与清洗入库数据抓取这块我用的是 Python 爬虫requests 加 BeautifulSoup 的组合。目标站点结构不复杂列表页拿到详情链接详情页解析出品类和价格。抓取的时候要注意两点一是加请求头模拟浏览器二是控制频率别把人家服务器打挂。我设的是每次请求间隔 1 秒一天抓几十个品类也就一分钟的事。清洗环节是重点。抓下来的价格经常带单位、带空格、带元/斤这种后缀直接入库后面统计会出错。我的做法是用正则把数字部分提取出来统一转成 float。品类名称也要做映射不同渠道叫法可能不一样比如土豆和马铃薯得统一到一个标准名。这一步用字典做映射表维护起来方便。import re def clean_price(raw): # 提取数字部分支持小数 match re.search(r\d\.?\d*, raw) if match: return float(match.group()) return None入库用 sqlite3 模块注意用参数化查询防止 SQL 注入虽然数据是自己抓的但好习惯要养成。批量插入用 executemany 比一条条 insert 快很多几百条数据差距不明显上万条就很可观了。4.2 Flask 路由与页面渲染Flask 开发的核心是路由设计。我设计了三个主要路由首页展示最新价格列表/category/id展示某品类历史/api/prices提供 JSON 接口给前端图表用。首页路由查最新一天的数据按品类分组展示。品类页查该品类所有历史记录按日期倒序。from flask import Flask, render_template, request import sqlite3 app Flask(__name__) def get_db(): conn sqlite3.connect(instance/prices.db) conn.row_factory sqlite3.Row return conn app.route(/) def index(): conn get_db() rows conn.execute( SELECT c.name, p.price, p.record_date FROM price_record p JOIN category c ON p.category_id c.id WHERE p.record_date (SELECT MAX(record_date) FROM price_record) ORDER BY c.name ).fetchall() conn.close() return render_template(index.html, pricesrows)row_factory sqlite3.Row这行很关键它让查询结果可以像字典一样用列名访问模板里写{{ row[name] }}比{{ row[0] }}可读性好太多。模板用 Jinja2继承一个 base.html公共部分抽出来各页面只写差异部分。这样改导航栏、改页脚只用改一个文件。4.3 数据可视化与前端交互农产品价格数据可视化是这个站的核心卖点。我用的是 Chart.js轻量、上手快、文档全。后端提供/api/prices?category1days30这样的接口返回 JSON 数组前端 fetch 拿到后喂给 Chart.js 画折线图。为什么不用 Dash FlaskDash 适合做数据分析看板但它的交互模式偏 Python 驱动对于这种简单展示站有点重而且定制样式不如原生前端灵活。前端交互上品类筛选用下拉框change 事件触发 fetch 重新拉数据更新图表。日期范围用两个 input typedate默认最近 30 天。这些交互都不复杂但体验提升明显。页面加载速度方面图表数据做了缓存同一品类同一天的数据不重复查库。提示Chart.js 的 x 轴日期格式要统一后端返回 YYYY-MM-DD前端配置里指定对应格式否则会出现日期错乱。4.4 WorkBuddy 日更流程编排日更流程是整个项目跑起来之后最省心的部分。我把前面说的四步封装成 WorkBuddy skill每天早上 6 点定时触发。执行顺序是先跑抓取 skill成功后再跑入库 skill然后生成页面最后健康检查。每一步的返回状态都记录到日志失败会发通知。WorkBuddy 从入门到精通这个说法有点夸张实际上常用的功能就那几个任务定义、定时触发、日志查看、失败重试。把这几个用熟日常运维基本不用操心。我特别推荐用它的失败重试机制网络抓取偶尔超时很正常设置重试 3 次、间隔 5 分钟大部分临时故障都能自愈不用人工介入。5. 部署上线与常见问题排查5.1 Flask 部署的几种方式对比Flask 部署这块开发阶段用flask run就够了但上线必须用生产级服务器。常见方案有三种Gunicorn 加 Nginx、uWSGI 加 Nginx、Waitress 单独跑。我选的是 Gunicorn 加 NginxLinux 环境下最成熟。Gunicorn 负责跑 Flask 应用Nginx 负责反向代理和静态文件。# Gunicorn 启动示例 gunicorn -w 4 -b 127.0.0.1:8000 app:app-w 4是开 4 个 worker 进程一般设成 CPU 核心数的 2 倍加 1。Nginx 配置里把 80 端口的请求转发到 8000静态文件直接由 Nginx 返回减轻 Flask 压力。这套配置跑一个小型数据站绰绰有余。部署方式适用场景优点缺点flask run本地开发简单性能差不能上线GunicornNginxLinux 生产稳定成熟配置稍复杂WaitressWindows 生产跨平台性能一般5.2 常见问题速查与排查思路跑了三个多月遇到的问题基本集中在几类。我整理成表格方便对照排查。问题现象可能原因排查方法解决方式页面 500 错误数据库连接失败看 Flask 日志检查 db 文件路径和权限数据不更新定时任务没触发查 WorkBuddy 日志检查定时配置和 skill 状态图表空白接口返回格式错浏览器 Network 面板确认 JSON 字段名一致中文乱码编码不统一检查文件编码统一用 UTF-8写入变慢数据量增大看表行数加索引或归档旧数据中文乱码这个问题我踩过原因是数据库连接时没指定编码后来在连接字符串里加上?charsetutf8就好了。写入变慢是数据到十万行之后出现的给 record_date 字段加了索引查询速度立刻回来。索引这东西不是越多越好写频繁的表加太多索引会拖慢插入按查询需求加就行。5.3 几个让我少走弯路的实操心得第一个心得是数据库文件一定要定期备份。SQLite 备份就是复制文件我写了个 skill 每天把 db 文件复制到备份目录按日期命名保留最近 30 天。有次误操作删了数据直接从备份恢复五分钟搞定。第二个心得是日志要记全。抓取日志、执行日志、错误日志分开记出问题的时候能快速定位是哪一环。我一开始图省事只记错误结果有次数据少了几条但没报错查了半天才发现是抓取时某页解析失败被静默跳过了。第三个心得是别过度设计。这个站一开始我想加用户系统、加权限管理、加数据导出后来砍掉了只保留核心功能。功能越少出问题的概率越低维护成本也越低。等真有需求了再加也不迟。6. 关于自建站与平台建站的选择再说几句实在话Shopify、WordPress、自建站什么区别这个问题我被问过很多次。我的看法是看你的核心诉求。如果你要卖货Shopify 开箱即用支付物流都现成省心。如果你要做内容站WordPress 生态成熟插件丰富不懂代码也能玩转。但如果你要做的是数据驱动的工具站数据结构和展示逻辑都是定制的那自建站是唯一解平台建站要么做不到要么做起来很别扭。自建站的门槛其实没想象中高。Python 入门到能写 Flask 应用认真学两周足够。SQLite 数据库操作更简单增删改查就那几条语句。WorkBuddy 这类工具又把重复劳动自动化了日常维护成本很低。真正花时间的是需求梳理和细节打磨比如数据清洗规则、页面交互体验、异常处理逻辑这些才是决定站点好不好用的关键。免费 Python 源码大全这类资源网上很多参考可以但别直接抄。每个项目的数据结构和业务逻辑都不一样抄来的代码往往要改得面目全非不如自己从头写一遍理解得透彻。我写这个站的时候也参考了不少开源项目但核心代码都是按自己需求重新组织的。最后说个实际体会。这套方案跑下来最大的收获不是省了多少钱而是整个链路完全可控。数据怎么来的、怎么存的、怎么展示的每一环都清楚。出了问题能自己排查想加功能能自己动手。这种掌控感是平台建站给不了的。如果你也在纠结建站方案不妨先想清楚自己的核心需求是什么再决定走哪条路。数据站、工具站这类场景Flask 加 SQLite 加 WorkBuddy 这套组合我个人实测下来很稳值得一试。