1. 四件套的分工边界先把谁来干什么钉死再动手爬虫、MySQL、Flask、ECharts 这套组合在毕设里出现的频率高到几乎成了标配但真正把它跑通、并且答辩时能讲清楚每一层在做什么的人并不多。我见过太多项目是这样糊起来的爬虫抓完数据直接json.dump成一个文件Flask 里读文件返回ECharts 前端画图MySQL 装了个壳摆在那里一行数据都没有——答辩老师只要问一句你这个数据库起什么作用当场就卡住。所以这份内容不讲虚的就从零拆一遍怎么用爬虫把某类公开站点的结构化信息抓下来怎么用 MySQL 把数据存成为查询而生的形态怎么用 Flask 把库里的行变成图表要的 JSON怎么用 ECharts 把这些 JSON 变成一个能点、能筛、能联动的看板。适合正在做数据可视化方向毕设的同学也适合想快速搭一套采集—存储—服务—展示链路练手的人。先说清楚四个组件各自的职责这是后面所有设计决策的地基。爬虫层只负责一件事把公开可访问的结构化信息变成 Python 里的字典/列表顺带做字段级的清洗和类型转换它不碰数据库、不做统计。MySQL 层负责两件事把数据以可去重、可聚合的结构存下来以及承担所有GROUP BY、AVG、COUNT这类统计计算让 Flask 拿到的就是半成品结果。Flask 层是个薄薄的转换器接请求参数、查库、把结果包成 JSON它不做业务计算也不做数据清洗。ECharts 层只负责把 JSON 映射成视觉通道——哪个字段对应 X 轴、哪个对应 Y 轴、哪个对应颜色。这四层之间是单向数据流任何一层越界去做别层的事后面一定会付出代价。最常见的越界有两种。第一种是爬虫顺手算统计抓完数据在 Python 里用defaultdict把各城市数量算好然后把聚合结果存进库。这样做的直接后果是一旦你想换一个维度比如按学历分组、按发布时间按月分组就必须重跑爬虫而目标站点的数据可能已经变了。统计这件事一定要放在查询时做因为统计口径是会变的原始数据不会。第二种越界是前端做计算ECharts 拿到的是一堆原始明细在 JS 里用reduce算平均薪资。这在数据量小的时候没问题但前端算统计意味着每次切筛选条件都要把全量数据传到浏览器几千条之后就明显卡顿而且口径写在 JS 里更难维护。还有个容易被忽略的点这套架构的可视化到底可视化什么。标题里写的是网站数据可视化但千万别理解成把网站本身画出来。真正做的是从某个站点采集业务数据然后对这批数据做统计维度的呈现——地区分布、时间趋势、类目占比、价格区间直方图诸如此类。这个认知必须先立住否则你会花大量时间纠结我要爬哪个网站而不是我要回答什么问题。下面这张表是我建议你在开题前就填好的它决定了后面所有代码的形状层级唯一职责明确不做的事典型产出物爬虫抓取、字段抽取、类型清洗不做聚合统计、不写库结构化记录列表MySQL存储、去重、聚合计算不做文本清洗、不做格式转换聚合查询结果集Flask参数校验、查询、序列化不做统计、不做数据修正标准 JSONECharts视觉映射、交互联动不做统计计算、不做兜底清洗交互图表把这张表贴在显示器边上后面每写一段代码前问自己这是哪一层的事能省掉大量返工。2. 目标站点的选择与字段定标可视化能不能出效果在这一步就定了2.1 选站点别看有没有反爬要看字段密度够不够新手选目标站点的第一反应通常是哪个好爬抓哪个这个顺序是反的。真正决定项目成败的是字段密度这个站点上一条记录能不能同时提供至少四到五个可分类、可度量的字段。你需要的典型字段组合是一个类目字段 一个地区字段 一个时间字段 一到两个数值字段。类目字段决定饼图地区字段决定地图或条形图时间字段决定折线趋势数值字段决定柱状图的 Y 轴。缺了数值字段你只能画占比缺了时间字段你只能画静态快照答辩时讲不出趋势这个概念故事就少了一半。我一般建议从公开的、以列表形式展示的页面入手比如公开的图书信息页、公开的商品比价页、公开的招聘信息列表页、公开的影音条目页。这类页面的共同特征是一页展示十几到几十条记录每条记录有名称、分类、时间、若干数值或标签。这种列表 详情的结构最容易做字段抽取也最容易做出有说服力的图表。反过来那种整站都是图文混排、字段藏在正文段落里的站点抽取成本会高出一个量级不适合作为单人工期的毕设主体。在动手写代码之前先做一件很土但极其有用的事手动抄十条记录。打开目标页面挑十条把每条记录的五个字段抄进 Excel然后看两件事。第一这五个字段是不是每条都有值缺失率超过 30% 的字段直接放弃别指望在代码里补补出来的数据在答辩时经不起追问。第二这些字段的取值分布是不是够散——如果一个类目字段 95% 的值都是同一个那这个饼图会是一整个圆视觉效果为零。字段定标这一步花两小时能省掉后面两天的返工。2.2 robots 与采集频率把合规写进代码而不是写进文档采集公开数据这件事边界要自己划清楚只抓无需登录即可访问的公开页面遵守站点根目录下的 robots 声明控制请求频率不采集任何个人身份信息。这几条不要只写在论文的合规说明章节里要落到代码里因为代码里写了的才是真的。具体做法是把请求间隔、并发数、重试次数做成配置项默认值就给得保守一些——单线程、每次请求之间sleep一到两秒、失败最多重试两次。这个速度听起来慢但一个列表页几十条记录翻二十页也就几分钟完全够用。很多人一上来就开多线程、把间隔设成 0.1 秒前几十个请求都正常然后就收到 403接着开始怀疑人生花半天去研究请求头。实际上大概率不是请求头的问题是频率问题。提示把User-Agent、Referer、Accept-Language这几个头补齐成功率会有明显提升但这不是绕过只是让你的请求看起来像一个正常的浏览器访问。真正决定你能抓多久的是频率和总量不是请求头。另外一个实操细节抓下来的原始页面先落盘再解析。也就是请求成功之后把 HTML 存到本地raw/目录解析逻辑单独跑一遍读本地文件。这样做的好处是解析规则写错的时候你不用重新请求一遍站点改完直接拿本地文件重跑。这个习惯我在做任何采集类项目时都会保留它把网络问题和解析问题彻底隔离开了排错时间能砍掉一大半。3. 爬虫层的落地从请求构造到入库前的数据清洗3.1 请求与解析的最小骨架爬虫部分不需要写得多花哨一个抓列表页 → 抽字段 → 翻页 → 落地的线性流程就够了。下面这段是通用骨架把解析函数换成你自己站点的规则即可import time import random import requests from bs4 import BeautifulSoup HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36, Accept-Language: zh-CN,zh;q0.9, } def fetch(url, retry2): for i in range(retry 1): try: resp requests.get(url, headersHEADERS, timeout10) resp.raise_for_status() resp.encoding resp.apparent_encoding # 中文页面必须先定编码 return resp.text except requests.RequestException as e: print(f[warn] {url} 第{i1}次失败: {e}) time.sleep(2 * (i 1)) return None def parse_list(html): soup BeautifulSoup(html, html.parser) rows [] for item in soup.select(div.list-item): rows.append({ title: item.select_one(.title).get_text(stripTrue), cat: item.select_one(.cat).get_text(stripTrue), city: item.select_one(.city).get_text(stripTrue), date: item.select_one(.date).get_text(stripTrue), price: item.select_one(.price).get_text(stripTrue), }) return rows这里有两处是新手最容易翻车的。第一处是resp.encoding。requests对中文页面的编码推断经常不准尤其是响应头里没带charset的站点默认会按 ISO-8859-1 解码结果就是满屏乱码然后你会以为是数据库的问题一路查到字符集配置白折腾。正确做法是显式设置resp.encoding resp.apparent_encoding或者直接resp.content.decode(utf-8, errorsignore)。第二处是timeout。不设超时的请求在遇到慢响应时会一直挂着整个脚本看起来卡死实际是在等。设个 10 秒失败了重试比无限等待强得多。3.2 数值字段的解析这一段的坑比爬虫本身还多真正消耗时间的不是抓取是清洗。数值字段尤其麻烦因为页面上展示的往往是给人看的格式不是给程序算的格式。比如15k-25k、15-25K·13薪、面议、8000-12000/月、1.2万-1.8万这五种写法你要在代码里全部覆盖否则入库时int()会直接抛异常把整批数据打断。我的处理思路是写一个统一的解析函数返回(low, high)二元组解析不出来就返回(None, None)绝不抛异常。因为一条脏数据不应该让整批入库失败它应该变成 NULL然后在统计时被自然排除掉。下面这个函数覆盖了常见格式import re def parse_range(text): 把 15k-25k、1.2万-1.8万、8000-12000 统一解析成 (low, high)单位为元 if not text or 面议 in text: return None, None text text.replace(,, ).replace(, ).replace(¥, ).strip() m re.search(r(\d(?:\.\d)?)\s*([kK千万]?)\s*[-~至]\s*(\d(?:\.\d)?)\s*([kK千万]?), text) if not m: m1 re.search(r(\d(?:\.\d)?)\s*([kK千万]?), text) if not m1: return None, None v float(m1.group(1)) * {k: 1000, K: 1000, 万: 10000, 千: 1000}.get(m1.group(2), 1) return int(v), int(v) unit_map {k: 1000, K: 1000, 万: 10000, 千: 1000, : 1} low float(m.group(1)) * unit_map.get(m.group(2), 1) high float(m.group(3)) * unit_map.get(m.group(4) or m.group(2), 1) return int(low), int(high)注意m.group(4) or m.group(2)这个写法。因为15k-25000这种混写是存在的前半段带单位、后半段不带所以要回落到前半段的单位。这个细节不做处理就会出现最低 15000、最高 25这种离谱数据然后你的平均薪资图会画出一条诡异的曲线而你会盯着 SQL 查半天。日期字段同理。2024-03-05、2024/03/05、2024年3月5日、03-05、3小时前、昨天这些东西在页面上混着出现是常态。处理原则是能归一就归一成DATE归一不了就存 NULL绝不要存一个3小时前字符串进去然后用ORDER BY排序——字符串排序的结果是9小时前排在10小时前后面这种错误在图表上表现为时间轴乱序极其难查。提示给解析函数单独写一个小测试集把你手动抄的十条数据、加上你见过的所有畸形格式全塞进去跑一遍断言每条都返回合理值。这一步十分钟能省掉后面调图表的两小时。3.3 去重策略数据库的唯一键比 Python 的 set 靠谱翻页抓取必然遇到重复记录——置顶的、跨类目的、编辑推荐位重排的都会让同一条数据出现两次以上。在 Python 里用set去重看起来简单但有两个问题一是内存随数据量线性增长二是跨批次无法去重你今天抓一批、明天补抓一批两次之间的重复set管不了。正确做法是把去重交给数据库建表时定义一个业务唯一键比如title source publish_date三列组合的唯一索引入库时用INSERT IGNORE或ON DUPLICATE KEY UPDATE。这样无论你跑多少次爬虫库里始终是幂等的。这个设计的额外好处是爬虫可以随时中断、随时重跑不用担心跑一半挂了就得清库重来对调试极其友好。4. MySQL 表结构与入库策略让表为查询而生而不是为存储而生4.1 建表字段类型就是查询性能很多人建表是按页面上有什么就存什么来的全用VARCHAR(255)看起来省事实际是在给后面的查询埋雷。字段类型直接决定三件事能不能加索引、聚合计算快不快、数据会不会失真。数值字段存成字符串AVG()会先做隐式转换慢且可能出错日期字段存成字符串BETWEEN范围查询直接失效只能全表扫。我给这类可视化项目的标准建表方案大概长这样CREATE TABLE records ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, title VARCHAR(200) NOT NULL COMMENT 名称/标题, category VARCHAR(64) DEFAULT NULL COMMENT 类目用于饼图, city VARCHAR(32) DEFAULT NULL COMMENT 地区用于条形图/地图, salary_low INT DEFAULT NULL COMMENT 数值下界, salary_high INT DEFAULT NULL COMMENT 数值上界, edu VARCHAR(16) DEFAULT NULL COMMENT 标签类字段, publish_date DATE DEFAULT NULL COMMENT 日期用于折线趋势, source VARCHAR(32) NOT NULL DEFAULT default COMMENT 来源标识, crawl_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_biz (title, source, publish_date), KEY idx_city (city), KEY idx_date (publish_date), KEY idx_cat (category) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_general_ci;几个点值得单独说。第一utf8mb4不是可选项。只要你的数据里可能出现任何生僻字、符号、特殊字符utf8三字节就会在入库时报 Incorrect string value而这个错误往往在你抓了几千条之后才出现因为它只在遇到特定字符时触发非常阴间。建库建表连接三处都要utf8mb4缺一处都不行。第二索引不是越多越好。上面三个索引对应的是三类高频查询按城市分组、按日期范围筛、按类目分组。除此之外的字段不要随手加索引因为每条索引都会拖慢批量插入。爬虫入库是批量写索引多了写入速度会掉得很难看。第三salary_low和salary_high拆成两列存而不是存一个平均薪资。这是为了保留原始信息你想算平均值就(lowhigh)/2想算中位数、想按区间分桶做直方图都可以从这两列推出来。如果一开始就只存平均值后面想改口径就没数据了。4.2 批量入库executemany与事务边界单条INSERT循环插几千条速度会慢到让你怀疑人生因为每次都要走一遍网络往返和事务提交。正确姿势是攒批 executemanyimport pymysql def save_batch(conn, rows, batch_size200): sql (INSERT IGNORE INTO records (title, category, city, salary_low, salary_high, edu, publish_date, source) VALUES (%s,%s,%s,%s,%s,%s,%s,%s)) data [(r[title], r[category], r[city], r[salary_low], r[salary_high], r[edu], r[publish_date], r[source]) for r in rows] with conn.cursor() as cur: for i in range(0, len(data), batch_size): cur.executemany(sql, data[i:i batch_size]) conn.commit()这里INSERT IGNORE配合唯一索引重复数据会被静默跳过不会中断整批。注意游标的用法with conn.cursor() as cur保证游标关闭但conn.commit()放在循环外面让整批数据在一个事务里提交比每条提交快一个数量级。如果你的数据量到十万级还可以临时关掉自动提交、入库前SET unique_checks0不过毕设这个量级一般用不上。还有一个隐蔽的坑pymysql默认charset参数如果不显式指定连接字符集可能不是utf8mb4导致写入中文时正常、写入四字节字符时炸掉。连接时务必写全conn pymysql.connect( host127.0.0.1, port3306, userroot, passwordyour_pwd, databaseviz, charsetutf8mb4, cursorclasspymysql.cursors.DictCursor, autocommitFalse, )DictCursor这个设置很关键它让查询结果直接是字典而不是元组Flask 里jsonify(result)能一把过省掉手写字段映射的代码。5. Flask 接口层把数据库的行变成图表要的形5.1 接口设计一个图表一个接口别搞万能接口新手常见的做法是写一个/api/data接口接受各种参数前端传什么就返回什么。这个设计在有两三个图表时看起来省事但很快会变成一团乱麻每个图表的 SQL 不一样、返回结构不一样、参数校验逻辑全挤在一个函数里。我的做法是一个图表对应一个接口接口名直接体现业务含义。比如/api/city_dist返回地区分布/api/trend返回时间趋势/api/category_pie返回类目占比/api/salary_hist返回薪资直方图。好处是每个接口的返回结构可以针对对应图表定制前端拿到就能直接塞给 ECharts不需要二次加工。from flask import Flask, jsonify, request import pymysql app Flask(__name__) def get_conn(): return pymysql.connect(host127.0.0.1, userroot, passwordyour_pwd, databaseviz, charsetutf8mb4, cursorclasspymysql.cursors.DictCursor) app.route(/api/city_dist) def city_dist(): topn min(int(request.args.get(topn, 15)), 50) sql SELECT city AS name, COUNT(*) AS value, ROUND(AVG((salary_low salary_high) / 2), 1) AS avg_salary FROM records WHERE city IS NOT NULL AND salary_low IS NOT NULL GROUP BY city HAVING value 10 ORDER BY value DESC LIMIT %s conn get_conn() try: with conn.cursor() as cur: cur.execute(sql, (topn,)) rows cur.fetchall() finally: conn.close() return jsonify({code: 0, data: rows})这段代码里有几个决定性细节。WHERE里过滤了salary_low IS NOT NULL因为AVG()遇到 NULL 会跳过但如果整组都是 NULL结果就是 NULL前端拿到null画图会直接报错或者画出个零。HAVING value 10是过滤掉样本量太小的城市——一个只有 2 条记录的城市平均薪资可能特别高直接画上排行榜会让整个图失真答辩时被问这个城市为什么这么高会很尴尬。LIMIT %s用参数化占位符既防注入又方便前端传topn。finally: conn.close()不能省。每个请求开一个连接、用完就关这是最简单也最不容易出错的做法。如果你想用连接池那是优化阶段的事先保证不泄漏。5.2 返回结构对齐 ECharts能少一层前端加工就少一层ECharts 的饼图需要[{name, value}, ...]柱状图需要xAxis.data数组 series.data数组。这两者的结构不一样所以我倾向于让后端直接返回图表能用的形状。比如趋势图接口app.route(/api/trend) def trend(): sql SELECT DATE_FORMAT(publish_date, %%Y-%%m) AS month, COUNT(*) AS cnt FROM records WHERE publish_date DATE_SUB(CURDATE(), INTERVAL 12 MONTH) GROUP BY month ORDER BY month conn get_conn() try: with conn.cursor() as cur: cur.execute(sql) rows cur.fetchall() finally: conn.close() return jsonify({ code: 0, xAxis: [r[month] for r in rows], series: [r[cnt] for r in rows], })注意DATE_FORMAT里的%%Y-%%m。因为pymysql的execute会对 SQL 做参数化处理单个%会被当成占位符转义的前缀必须写成双百分号否则报 unsupported format character。这个错误我第一次遇到时查了很久因为报错信息完全没提日期格式只说了格式化字符的问题。还有GROUP BY month用别名这件事。MySQL 允许在GROUP BY里引用SELECT的别名这在其他数据库里不一定成立。方便是方便但如果你的查询以后要迁移记得改成重复写DATE_FORMAT(...)。5.3 跨域与调试flask-cors与静态资源托管开发阶段前端大概率是独立跑的比如 VSCode 的 Live Server 起在 5500 端口Flask 在 5000 端口浏览器会直接拦掉跨域请求。最快的解法是装flask-corsfrom flask_cors import CORS app Flask(__name__) CORS(app)但更省事的做法是让 Flask 直接把前端页面也托管了。把index.html和echarts.min.js放进项目的static/目录然后app.route(/) def index(): return app.send_static_file(index.html)这样就同源了跨域问题从根本上消失而且答辩演示时只需要python app.py一条命令不用同时开两个终端。演示环境越简单越好这是我从多次现场答辩翻车里总结出来的。6. ECharts 前端从静态 JSON 到能点的看板6.1 容器高度那个让无数人白屏的坑ECharts 初始化后一片空白控制台没有报错这是最高频的问题。九成情况下原因是图表容器的div没有明确高度。ECharts 在init时会读取容器的clientHeight如果容器高度是 0比如父元素没有高度、或者div里没有内容且没设height它就会按 0 高度渲染画布是存在的但你看不见。div idcityChart stylewidth:100%;height:420px;/div高度必须是确定值height: 100%只有在父级有确定高度时才生效。我一般直接给像素值避开所有继承链的问题。另一个相关的坑是窗口 resize 之后图表不变形需要加window.addEventListener(resize, () myChart.resize());不加这一行浏览器窗口一拉大图表还是原来的尺寸留一大片空白视觉效果很差。6.2 图表配置与数据对接一个典型的柱状图配置大概是这个形状const chart echarts.init(document.getElementById(cityChart)); fetch(/api/city_dist?topn15) .then(r r.json()) .then(res { const rows res.data; chart.setOption({ tooltip: { trigger: axis }, grid: { left: 60, right: 30, top: 40, bottom: 60 }, xAxis: { type: category, data: rows.map(r r.city), axisLabel: { rotate: 35, interval: 0 } }, yAxis: { type: value, name: 记录数 }, series: [{ type: bar, data: rows.map(r r.value), itemStyle: { borderRadius: [4, 4, 0, 0] }, label: { show: true, position: top } }] }); });axisLabel.rotate: 35和interval: 0是配套的。城市名一般三到四个字横排十五个必然会重叠旋转 35 度后基本能排开interval: 0表示强制显示所有标签默认是自动隐藏部分标签避免重叠但在类别不多的时候全显示信息更完整。grid的手动设置也值得说。默认边距下Y 轴名称容易被裁掉旋转后的 X 轴标签容易超出画布。我习惯把left给足 60 以上、bottom给到 60 以上图上就干净了。6.3 多图联动筛选器才是让项目像个系统的关键单一图表谁都能画让答辩老师觉得这是个完整系统的是图表之间的联动。做法很简单页面顶部放一组筛选控件类目下拉、日期范围、地区多选每次变更时把所有图表的接口重新请求一遍带上筛选参数。let filters { cat: , city: , month: }; function refreshAll() { const qs new URLSearchParams( Object.entries(filters).filter(([, v]) v ! ) ).toString(); [/api/city_dist, /api/trend, /api/category_pie].forEach(url { fetch(${url}?${qs}).then(r r.json()).then(bindChart); }); }后端对应地给每个 SQL 动态拼接WHERE条件注意仍然要用参数化where, params [11], [] if cat : request.args.get(cat): where.append(category %s); params.append(cat) if city : request.args.get(city): where.append(city %s); params.append(city) sql fSELECT ... FROM records WHERE { AND .join(where)} GROUP BY ... cur.execute(sql, params)where数组里只能是固定字符串用户输入一律走%s占位符。这条纪律必须守住因为筛选参数是直接暴露给前端的一旦拼接字符串就是注入漏洞。虽然毕设不一定会被攻击但代码被翻到时这一行会被单独拎出来问。7. 踩坑排查链路图表空白、数据错位与时间戳异常7.1 图表空白的四层排查法遇到图表不出来不要瞎改按这个顺序逐层验证每层都能用最少的动作定位问题第一层接口有没有数据。浏览器直接访问/api/city_dist看返回的 JSON。如果data是空数组问题在后端前端一行都不用看。空数组的原因通常是 SQL 的WHERE条件太严比如日期范围没数据或者HAVING value 10把所有组都过滤了。把HAVING临时去掉再试能立刻确认。第二层前端有没有拿到。打开 Network 面板看这个请求的状态码和响应体。如果状态码是 200 但响应体为空多半是 Flask 里jsonify之前抛了异常被吞掉了去看终端日志。如果状态码 500终端一定打了 traceback直接看最后一行。第三层数据格式对不对。ECharts 对数据格式很敏感series.data里如果混进了null或者字符串数字图可能整个不渲染但也不报错。在setOption之前console.log一下rows确认每个元素都有name和value。第四层容器和时机。确认容器有高度前述确认echarts.init在 DOM 加载之后执行脚本放在/body前或者用DOMContentLoaded。如果用了display:none的 tab 页切换切换时容器高度为 0初始化后必须手动resize()。这四层按顺序走基本五分钟内能定位。最忌讳的是改一下试试因为同时改多个地方即使碰巧好了你也不知道是哪一处修好的下次遇到还是不会。7.2 数据错位的三种典型形态聚合结果与图表预期不匹配。比如饼图加起来不是 100%因为GROUP BY之后有空值组被算了进去或者某些记录的category是 NULL。检查方法是在 SQL 里加WHERE category IS NOT NULL AND category 或者在图表配置里把null归到其他类目。后者更推荐因为丢掉数据会让总数对不上答辩时被问为什么总数比库里少不好解释。中文乱码。三个地方要同时是utf8mb4建库时的DEFAULT CHARSET、连接时的charset参数、以及 HTML 里的meta charsetutf-8。少一处就是乱码而且乱码的形态还不一样——数据库里是问号说明入库时就坏了浏览器里是问号说明响应头或 meta 有问题。用SELECT HEX(city) FROM records LIMIT 1能看出库里存的是不是正确字节这个排查手段很实用。时间轴乱序。折线图的 X 轴按字符串排序2024-3 会排在 2024-10 后面。根因是月份没补零。用DATE_FORMAT(publish_date, %Y-%m)保证固定宽度排序就正常了。如果数据里publish_date本身是字符串那更要在入库时就转成DATE类型别留到查询时补救。7.3 那些没人提前告诉你的实操细节第一先跑通最小闭环再做美化。所谓最小闭环是抓 20 条数据 → 入库 → 一个接口返回 → 一个图表画出来。这四步在半小时内跑通后面所有工作都是在这个骨架上加东西。如果反过来先做页面布局、再写爬虫、最后调接口中间任何一环卡住你都看不到成果很容易失去动力。第二造一批假数据用于前端调试。在前端开发的阶段接口可能还没写完这时候在 JS 里写一个const MOCK {...}直接喂给setOption把图表样式调好等接口通了把fetch换回来就行。这样前后端可以并行不会被互相阻塞。第三给每个 SQL 都加LIMIT兜底。哪怕你觉得分组之后不会有那么多行也加上LIMIT 200。因为一旦某个字段的取值特别散比如标题字段被误当成类目一个GROUP BY可能返回几千行浏览器渲染几千个柱子会直接卡死。这种卡死看起来像前端写错了实际是最外层没兜底。第四答辩演示用本地数据不要现场跑爬虫。现场网络不可控目标站点可能响应慢、可能返回异常页一旦演示时图表空着这个项目的印象分就废了。正确做法是提前把数据入库、把 MySQL 和 Flask 都跑起来演示时只展示查询—渲染这一段爬虫部分用录屏或者日志截图说明。这不是投机是工程常识——没人会在生产环境演示时现场拉数据。8. 从能跑到能讲答辩前该补的三块内容项目跑通只是及格线真正拉开差距的是你能不能解释清楚每个设计决策背后的理由。我见过不少项目功能都实现了但一问为什么用 MySQL 存而不是 JSON 文件答因为要求用数据库这种回答基本等于没做思考。第一块要补的是口径说明。你的每个图表统计的到底是什么必须能一句话说清。比如平均薪资这一项是(salary_low salary_high) / 2的算术平均还是去掉上下 5% 的截尾平均样本量小于 10 的组有没有排除salary_low为 NULL 的记录有没有参与计数这些细节写在图表的副标题或者 tooltip 里答辩时被追问就能直接指出来可信度完全不一样。第二块要补的是数据质量的数字。采集了多少条、去重后多少条、各字段的缺失率是多少、日期跨度多大。这几个数字能直接说明你对数据的掌控程度。比如共采集 4200 条去重后 3860 条其中薪资字段缺失 512 条13.3%日期字段缺失 87 条2.3%这样一句话比任何形容词都有说服力。第三块要补的是扩展方向的诚实表述。不要说未来将接入机器学习做预测这种空话说具体的、你确实想过的如果把采集频率提到每天一次时间趋势图就可以从月度粒度降到周度能看出更细的波动如果给城市字段加一个行政区划编码映射就可以换成地图热力图比条形图更直观。这类具体到实现路径的表述才叫真的想过。我个人在做这类项目时的体会是四条技术栈本身都不难难的是把它们的边界划清楚然后每一层都只做自己该做的事。爬虫只抓数据库只存和算Flask 只转换ECharts 只画。任何一个环节顺手多做了点最后都会变成排查问题时的那团乱麻。所以如果你现在正要动手别急着写代码花一个小时把字段清单和表结构定下来后面会顺得多。 
长河君 · 2026/10/23 1:24:51 · 阅读 1.2k 爬虫+MySQL+Flask+ECharts数据可视化看板分层实战
1. 四件套的分工边界先把谁来干什么钉死再动手爬虫、MySQL、Flask、ECharts 这套组合在毕设里出现的频率高到几乎成了标配但真正把它跑通、并且答辩时能讲清楚每一层在做什么的人并不多。我见过太多项目是这样糊起来的爬虫抓完数据直接json.dump成一个文件Flask 里读文件返回ECharts 前端画图MySQL 装了个壳摆在那里一行数据都没有——答辩老师只要问一句你这个数据库起什么作用当场就卡住。所以这份内容不讲虚的就从零拆一遍怎么用爬虫把某类公开站点的结构化信息抓下来怎么用 MySQL 把数据存成为查询而生的形态怎么用 Flask 把库里的行变成图表要的 JSON怎么用 ECharts 把这些 JSON 变成一个能点、能筛、能联动的看板。适合正在做数据可视化方向毕设的同学也适合想快速搭一套采集—存储—服务—展示链路练手的人。先说清楚四个组件各自的职责这是后面所有设计决策的地基。爬虫层只负责一件事把公开可访问的结构化信息变成 Python 里的字典/列表顺带做字段级的清洗和类型转换它不碰数据库、不做统计。MySQL 层负责两件事把数据以可去重、可聚合的结构存下来以及承担所有GROUP BY、AVG、COUNT这类统计计算让 Flask 拿到的就是半成品结果。Flask 层是个薄薄的转换器接请求参数、查库、把结果包成 JSON它不做业务计算也不做数据清洗。ECharts 层只负责把 JSON 映射成视觉通道——哪个字段对应 X 轴、哪个对应 Y 轴、哪个对应颜色。这四层之间是单向数据流任何一层越界去做别层的事后面一定会付出代价。最常见的越界有两种。第一种是爬虫顺手算统计抓完数据在 Python 里用defaultdict把各城市数量算好然后把聚合结果存进库。这样做的直接后果是一旦你想换一个维度比如按学历分组、按发布时间按月分组就必须重跑爬虫而目标站点的数据可能已经变了。统计这件事一定要放在查询时做因为统计口径是会变的原始数据不会。第二种越界是前端做计算ECharts 拿到的是一堆原始明细在 JS 里用reduce算平均薪资。这在数据量小的时候没问题但前端算统计意味着每次切筛选条件都要把全量数据传到浏览器几千条之后就明显卡顿而且口径写在 JS 里更难维护。还有个容易被忽略的点这套架构的可视化到底可视化什么。标题里写的是网站数据可视化但千万别理解成把网站本身画出来。真正做的是从某个站点采集业务数据然后对这批数据做统计维度的呈现——地区分布、时间趋势、类目占比、价格区间直方图诸如此类。这个认知必须先立住否则你会花大量时间纠结我要爬哪个网站而不是我要回答什么问题。下面这张表是我建议你在开题前就填好的它决定了后面所有代码的形状层级唯一职责明确不做的事典型产出物爬虫抓取、字段抽取、类型清洗不做聚合统计、不写库结构化记录列表MySQL存储、去重、聚合计算不做文本清洗、不做格式转换聚合查询结果集Flask参数校验、查询、序列化不做统计、不做数据修正标准 JSONECharts视觉映射、交互联动不做统计计算、不做兜底清洗交互图表把这张表贴在显示器边上后面每写一段代码前问自己这是哪一层的事能省掉大量返工。2. 目标站点的选择与字段定标可视化能不能出效果在这一步就定了2.1 选站点别看有没有反爬要看字段密度够不够新手选目标站点的第一反应通常是哪个好爬抓哪个这个顺序是反的。真正决定项目成败的是字段密度这个站点上一条记录能不能同时提供至少四到五个可分类、可度量的字段。你需要的典型字段组合是一个类目字段 一个地区字段 一个时间字段 一到两个数值字段。类目字段决定饼图地区字段决定地图或条形图时间字段决定折线趋势数值字段决定柱状图的 Y 轴。缺了数值字段你只能画占比缺了时间字段你只能画静态快照答辩时讲不出趋势这个概念故事就少了一半。我一般建议从公开的、以列表形式展示的页面入手比如公开的图书信息页、公开的商品比价页、公开的招聘信息列表页、公开的影音条目页。这类页面的共同特征是一页展示十几到几十条记录每条记录有名称、分类、时间、若干数值或标签。这种列表 详情的结构最容易做字段抽取也最容易做出有说服力的图表。反过来那种整站都是图文混排、字段藏在正文段落里的站点抽取成本会高出一个量级不适合作为单人工期的毕设主体。在动手写代码之前先做一件很土但极其有用的事手动抄十条记录。打开目标页面挑十条把每条记录的五个字段抄进 Excel然后看两件事。第一这五个字段是不是每条都有值缺失率超过 30% 的字段直接放弃别指望在代码里补补出来的数据在答辩时经不起追问。第二这些字段的取值分布是不是够散——如果一个类目字段 95% 的值都是同一个那这个饼图会是一整个圆视觉效果为零。字段定标这一步花两小时能省掉后面两天的返工。2.2 robots 与采集频率把合规写进代码而不是写进文档采集公开数据这件事边界要自己划清楚只抓无需登录即可访问的公开页面遵守站点根目录下的 robots 声明控制请求频率不采集任何个人身份信息。这几条不要只写在论文的合规说明章节里要落到代码里因为代码里写了的才是真的。具体做法是把请求间隔、并发数、重试次数做成配置项默认值就给得保守一些——单线程、每次请求之间sleep一到两秒、失败最多重试两次。这个速度听起来慢但一个列表页几十条记录翻二十页也就几分钟完全够用。很多人一上来就开多线程、把间隔设成 0.1 秒前几十个请求都正常然后就收到 403接着开始怀疑人生花半天去研究请求头。实际上大概率不是请求头的问题是频率问题。提示把User-Agent、Referer、Accept-Language这几个头补齐成功率会有明显提升但这不是绕过只是让你的请求看起来像一个正常的浏览器访问。真正决定你能抓多久的是频率和总量不是请求头。另外一个实操细节抓下来的原始页面先落盘再解析。也就是请求成功之后把 HTML 存到本地raw/目录解析逻辑单独跑一遍读本地文件。这样做的好处是解析规则写错的时候你不用重新请求一遍站点改完直接拿本地文件重跑。这个习惯我在做任何采集类项目时都会保留它把网络问题和解析问题彻底隔离开了排错时间能砍掉一大半。3. 爬虫层的落地从请求构造到入库前的数据清洗3.1 请求与解析的最小骨架爬虫部分不需要写得多花哨一个抓列表页 → 抽字段 → 翻页 → 落地的线性流程就够了。下面这段是通用骨架把解析函数换成你自己站点的规则即可import time import random import requests from bs4 import BeautifulSoup HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36, Accept-Language: zh-CN,zh;q0.9, } def fetch(url, retry2): for i in range(retry 1): try: resp requests.get(url, headersHEADERS, timeout10) resp.raise_for_status() resp.encoding resp.apparent_encoding # 中文页面必须先定编码 return resp.text except requests.RequestException as e: print(f[warn] {url} 第{i1}次失败: {e}) time.sleep(2 * (i 1)) return None def parse_list(html): soup BeautifulSoup(html, html.parser) rows [] for item in soup.select(div.list-item): rows.append({ title: item.select_one(.title).get_text(stripTrue), cat: item.select_one(.cat).get_text(stripTrue), city: item.select_one(.city).get_text(stripTrue), date: item.select_one(.date).get_text(stripTrue), price: item.select_one(.price).get_text(stripTrue), }) return rows这里有两处是新手最容易翻车的。第一处是resp.encoding。requests对中文页面的编码推断经常不准尤其是响应头里没带charset的站点默认会按 ISO-8859-1 解码结果就是满屏乱码然后你会以为是数据库的问题一路查到字符集配置白折腾。正确做法是显式设置resp.encoding resp.apparent_encoding或者直接resp.content.decode(utf-8, errorsignore)。第二处是timeout。不设超时的请求在遇到慢响应时会一直挂着整个脚本看起来卡死实际是在等。设个 10 秒失败了重试比无限等待强得多。3.2 数值字段的解析这一段的坑比爬虫本身还多真正消耗时间的不是抓取是清洗。数值字段尤其麻烦因为页面上展示的往往是给人看的格式不是给程序算的格式。比如15k-25k、15-25K·13薪、面议、8000-12000/月、1.2万-1.8万这五种写法你要在代码里全部覆盖否则入库时int()会直接抛异常把整批数据打断。我的处理思路是写一个统一的解析函数返回(low, high)二元组解析不出来就返回(None, None)绝不抛异常。因为一条脏数据不应该让整批入库失败它应该变成 NULL然后在统计时被自然排除掉。下面这个函数覆盖了常见格式import re def parse_range(text): 把 15k-25k、1.2万-1.8万、8000-12000 统一解析成 (low, high)单位为元 if not text or 面议 in text: return None, None text text.replace(,, ).replace(, ).replace(¥, ).strip() m re.search(r(\d(?:\.\d)?)\s*([kK千万]?)\s*[-~至]\s*(\d(?:\.\d)?)\s*([kK千万]?), text) if not m: m1 re.search(r(\d(?:\.\d)?)\s*([kK千万]?), text) if not m1: return None, None v float(m1.group(1)) * {k: 1000, K: 1000, 万: 10000, 千: 1000}.get(m1.group(2), 1) return int(v), int(v) unit_map {k: 1000, K: 1000, 万: 10000, 千: 1000, : 1} low float(m.group(1)) * unit_map.get(m.group(2), 1) high float(m.group(3)) * unit_map.get(m.group(4) or m.group(2), 1) return int(low), int(high)注意m.group(4) or m.group(2)这个写法。因为15k-25000这种混写是存在的前半段带单位、后半段不带所以要回落到前半段的单位。这个细节不做处理就会出现最低 15000、最高 25这种离谱数据然后你的平均薪资图会画出一条诡异的曲线而你会盯着 SQL 查半天。日期字段同理。2024-03-05、2024/03/05、2024年3月5日、03-05、3小时前、昨天这些东西在页面上混着出现是常态。处理原则是能归一就归一成DATE归一不了就存 NULL绝不要存一个3小时前字符串进去然后用ORDER BY排序——字符串排序的结果是9小时前排在10小时前后面这种错误在图表上表现为时间轴乱序极其难查。提示给解析函数单独写一个小测试集把你手动抄的十条数据、加上你见过的所有畸形格式全塞进去跑一遍断言每条都返回合理值。这一步十分钟能省掉后面调图表的两小时。3.3 去重策略数据库的唯一键比 Python 的 set 靠谱翻页抓取必然遇到重复记录——置顶的、跨类目的、编辑推荐位重排的都会让同一条数据出现两次以上。在 Python 里用set去重看起来简单但有两个问题一是内存随数据量线性增长二是跨批次无法去重你今天抓一批、明天补抓一批两次之间的重复set管不了。正确做法是把去重交给数据库建表时定义一个业务唯一键比如title source publish_date三列组合的唯一索引入库时用INSERT IGNORE或ON DUPLICATE KEY UPDATE。这样无论你跑多少次爬虫库里始终是幂等的。这个设计的额外好处是爬虫可以随时中断、随时重跑不用担心跑一半挂了就得清库重来对调试极其友好。4. MySQL 表结构与入库策略让表为查询而生而不是为存储而生4.1 建表字段类型就是查询性能很多人建表是按页面上有什么就存什么来的全用VARCHAR(255)看起来省事实际是在给后面的查询埋雷。字段类型直接决定三件事能不能加索引、聚合计算快不快、数据会不会失真。数值字段存成字符串AVG()会先做隐式转换慢且可能出错日期字段存成字符串BETWEEN范围查询直接失效只能全表扫。我给这类可视化项目的标准建表方案大概长这样CREATE TABLE records ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, title VARCHAR(200) NOT NULL COMMENT 名称/标题, category VARCHAR(64) DEFAULT NULL COMMENT 类目用于饼图, city VARCHAR(32) DEFAULT NULL COMMENT 地区用于条形图/地图, salary_low INT DEFAULT NULL COMMENT 数值下界, salary_high INT DEFAULT NULL COMMENT 数值上界, edu VARCHAR(16) DEFAULT NULL COMMENT 标签类字段, publish_date DATE DEFAULT NULL COMMENT 日期用于折线趋势, source VARCHAR(32) NOT NULL DEFAULT default COMMENT 来源标识, crawl_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_biz (title, source, publish_date), KEY idx_city (city), KEY idx_date (publish_date), KEY idx_cat (category) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_general_ci;几个点值得单独说。第一utf8mb4不是可选项。只要你的数据里可能出现任何生僻字、符号、特殊字符utf8三字节就会在入库时报 Incorrect string value而这个错误往往在你抓了几千条之后才出现因为它只在遇到特定字符时触发非常阴间。建库建表连接三处都要utf8mb4缺一处都不行。第二索引不是越多越好。上面三个索引对应的是三类高频查询按城市分组、按日期范围筛、按类目分组。除此之外的字段不要随手加索引因为每条索引都会拖慢批量插入。爬虫入库是批量写索引多了写入速度会掉得很难看。第三salary_low和salary_high拆成两列存而不是存一个平均薪资。这是为了保留原始信息你想算平均值就(lowhigh)/2想算中位数、想按区间分桶做直方图都可以从这两列推出来。如果一开始就只存平均值后面想改口径就没数据了。4.2 批量入库executemany与事务边界单条INSERT循环插几千条速度会慢到让你怀疑人生因为每次都要走一遍网络往返和事务提交。正确姿势是攒批 executemanyimport pymysql def save_batch(conn, rows, batch_size200): sql (INSERT IGNORE INTO records (title, category, city, salary_low, salary_high, edu, publish_date, source) VALUES (%s,%s,%s,%s,%s,%s,%s,%s)) data [(r[title], r[category], r[city], r[salary_low], r[salary_high], r[edu], r[publish_date], r[source]) for r in rows] with conn.cursor() as cur: for i in range(0, len(data), batch_size): cur.executemany(sql, data[i:i batch_size]) conn.commit()这里INSERT IGNORE配合唯一索引重复数据会被静默跳过不会中断整批。注意游标的用法with conn.cursor() as cur保证游标关闭但conn.commit()放在循环外面让整批数据在一个事务里提交比每条提交快一个数量级。如果你的数据量到十万级还可以临时关掉自动提交、入库前SET unique_checks0不过毕设这个量级一般用不上。还有一个隐蔽的坑pymysql默认charset参数如果不显式指定连接字符集可能不是utf8mb4导致写入中文时正常、写入四字节字符时炸掉。连接时务必写全conn pymysql.connect( host127.0.0.1, port3306, userroot, passwordyour_pwd, databaseviz, charsetutf8mb4, cursorclasspymysql.cursors.DictCursor, autocommitFalse, )DictCursor这个设置很关键它让查询结果直接是字典而不是元组Flask 里jsonify(result)能一把过省掉手写字段映射的代码。5. Flask 接口层把数据库的行变成图表要的形5.1 接口设计一个图表一个接口别搞万能接口新手常见的做法是写一个/api/data接口接受各种参数前端传什么就返回什么。这个设计在有两三个图表时看起来省事但很快会变成一团乱麻每个图表的 SQL 不一样、返回结构不一样、参数校验逻辑全挤在一个函数里。我的做法是一个图表对应一个接口接口名直接体现业务含义。比如/api/city_dist返回地区分布/api/trend返回时间趋势/api/category_pie返回类目占比/api/salary_hist返回薪资直方图。好处是每个接口的返回结构可以针对对应图表定制前端拿到就能直接塞给 ECharts不需要二次加工。from flask import Flask, jsonify, request import pymysql app Flask(__name__) def get_conn(): return pymysql.connect(host127.0.0.1, userroot, passwordyour_pwd, databaseviz, charsetutf8mb4, cursorclasspymysql.cursors.DictCursor) app.route(/api/city_dist) def city_dist(): topn min(int(request.args.get(topn, 15)), 50) sql SELECT city AS name, COUNT(*) AS value, ROUND(AVG((salary_low salary_high) / 2), 1) AS avg_salary FROM records WHERE city IS NOT NULL AND salary_low IS NOT NULL GROUP BY city HAVING value 10 ORDER BY value DESC LIMIT %s conn get_conn() try: with conn.cursor() as cur: cur.execute(sql, (topn,)) rows cur.fetchall() finally: conn.close() return jsonify({code: 0, data: rows})这段代码里有几个决定性细节。WHERE里过滤了salary_low IS NOT NULL因为AVG()遇到 NULL 会跳过但如果整组都是 NULL结果就是 NULL前端拿到null画图会直接报错或者画出个零。HAVING value 10是过滤掉样本量太小的城市——一个只有 2 条记录的城市平均薪资可能特别高直接画上排行榜会让整个图失真答辩时被问这个城市为什么这么高会很尴尬。LIMIT %s用参数化占位符既防注入又方便前端传topn。finally: conn.close()不能省。每个请求开一个连接、用完就关这是最简单也最不容易出错的做法。如果你想用连接池那是优化阶段的事先保证不泄漏。5.2 返回结构对齐 ECharts能少一层前端加工就少一层ECharts 的饼图需要[{name, value}, ...]柱状图需要xAxis.data数组 series.data数组。这两者的结构不一样所以我倾向于让后端直接返回图表能用的形状。比如趋势图接口app.route(/api/trend) def trend(): sql SELECT DATE_FORMAT(publish_date, %%Y-%%m) AS month, COUNT(*) AS cnt FROM records WHERE publish_date DATE_SUB(CURDATE(), INTERVAL 12 MONTH) GROUP BY month ORDER BY month conn get_conn() try: with conn.cursor() as cur: cur.execute(sql) rows cur.fetchall() finally: conn.close() return jsonify({ code: 0, xAxis: [r[month] for r in rows], series: [r[cnt] for r in rows], })注意DATE_FORMAT里的%%Y-%%m。因为pymysql的execute会对 SQL 做参数化处理单个%会被当成占位符转义的前缀必须写成双百分号否则报 unsupported format character。这个错误我第一次遇到时查了很久因为报错信息完全没提日期格式只说了格式化字符的问题。还有GROUP BY month用别名这件事。MySQL 允许在GROUP BY里引用SELECT的别名这在其他数据库里不一定成立。方便是方便但如果你的查询以后要迁移记得改成重复写DATE_FORMAT(...)。5.3 跨域与调试flask-cors与静态资源托管开发阶段前端大概率是独立跑的比如 VSCode 的 Live Server 起在 5500 端口Flask 在 5000 端口浏览器会直接拦掉跨域请求。最快的解法是装flask-corsfrom flask_cors import CORS app Flask(__name__) CORS(app)但更省事的做法是让 Flask 直接把前端页面也托管了。把index.html和echarts.min.js放进项目的static/目录然后app.route(/) def index(): return app.send_static_file(index.html)这样就同源了跨域问题从根本上消失而且答辩演示时只需要python app.py一条命令不用同时开两个终端。演示环境越简单越好这是我从多次现场答辩翻车里总结出来的。6. ECharts 前端从静态 JSON 到能点的看板6.1 容器高度那个让无数人白屏的坑ECharts 初始化后一片空白控制台没有报错这是最高频的问题。九成情况下原因是图表容器的div没有明确高度。ECharts 在init时会读取容器的clientHeight如果容器高度是 0比如父元素没有高度、或者div里没有内容且没设height它就会按 0 高度渲染画布是存在的但你看不见。div idcityChart stylewidth:100%;height:420px;/div高度必须是确定值height: 100%只有在父级有确定高度时才生效。我一般直接给像素值避开所有继承链的问题。另一个相关的坑是窗口 resize 之后图表不变形需要加window.addEventListener(resize, () myChart.resize());不加这一行浏览器窗口一拉大图表还是原来的尺寸留一大片空白视觉效果很差。6.2 图表配置与数据对接一个典型的柱状图配置大概是这个形状const chart echarts.init(document.getElementById(cityChart)); fetch(/api/city_dist?topn15) .then(r r.json()) .then(res { const rows res.data; chart.setOption({ tooltip: { trigger: axis }, grid: { left: 60, right: 30, top: 40, bottom: 60 }, xAxis: { type: category, data: rows.map(r r.city), axisLabel: { rotate: 35, interval: 0 } }, yAxis: { type: value, name: 记录数 }, series: [{ type: bar, data: rows.map(r r.value), itemStyle: { borderRadius: [4, 4, 0, 0] }, label: { show: true, position: top } }] }); });axisLabel.rotate: 35和interval: 0是配套的。城市名一般三到四个字横排十五个必然会重叠旋转 35 度后基本能排开interval: 0表示强制显示所有标签默认是自动隐藏部分标签避免重叠但在类别不多的时候全显示信息更完整。grid的手动设置也值得说。默认边距下Y 轴名称容易被裁掉旋转后的 X 轴标签容易超出画布。我习惯把left给足 60 以上、bottom给到 60 以上图上就干净了。6.3 多图联动筛选器才是让项目像个系统的关键单一图表谁都能画让答辩老师觉得这是个完整系统的是图表之间的联动。做法很简单页面顶部放一组筛选控件类目下拉、日期范围、地区多选每次变更时把所有图表的接口重新请求一遍带上筛选参数。let filters { cat: , city: , month: }; function refreshAll() { const qs new URLSearchParams( Object.entries(filters).filter(([, v]) v ! ) ).toString(); [/api/city_dist, /api/trend, /api/category_pie].forEach(url { fetch(${url}?${qs}).then(r r.json()).then(bindChart); }); }后端对应地给每个 SQL 动态拼接WHERE条件注意仍然要用参数化where, params [11], [] if cat : request.args.get(cat): where.append(category %s); params.append(cat) if city : request.args.get(city): where.append(city %s); params.append(city) sql fSELECT ... FROM records WHERE { AND .join(where)} GROUP BY ... cur.execute(sql, params)where数组里只能是固定字符串用户输入一律走%s占位符。这条纪律必须守住因为筛选参数是直接暴露给前端的一旦拼接字符串就是注入漏洞。虽然毕设不一定会被攻击但代码被翻到时这一行会被单独拎出来问。7. 踩坑排查链路图表空白、数据错位与时间戳异常7.1 图表空白的四层排查法遇到图表不出来不要瞎改按这个顺序逐层验证每层都能用最少的动作定位问题第一层接口有没有数据。浏览器直接访问/api/city_dist看返回的 JSON。如果data是空数组问题在后端前端一行都不用看。空数组的原因通常是 SQL 的WHERE条件太严比如日期范围没数据或者HAVING value 10把所有组都过滤了。把HAVING临时去掉再试能立刻确认。第二层前端有没有拿到。打开 Network 面板看这个请求的状态码和响应体。如果状态码是 200 但响应体为空多半是 Flask 里jsonify之前抛了异常被吞掉了去看终端日志。如果状态码 500终端一定打了 traceback直接看最后一行。第三层数据格式对不对。ECharts 对数据格式很敏感series.data里如果混进了null或者字符串数字图可能整个不渲染但也不报错。在setOption之前console.log一下rows确认每个元素都有name和value。第四层容器和时机。确认容器有高度前述确认echarts.init在 DOM 加载之后执行脚本放在/body前或者用DOMContentLoaded。如果用了display:none的 tab 页切换切换时容器高度为 0初始化后必须手动resize()。这四层按顺序走基本五分钟内能定位。最忌讳的是改一下试试因为同时改多个地方即使碰巧好了你也不知道是哪一处修好的下次遇到还是不会。7.2 数据错位的三种典型形态聚合结果与图表预期不匹配。比如饼图加起来不是 100%因为GROUP BY之后有空值组被算了进去或者某些记录的category是 NULL。检查方法是在 SQL 里加WHERE category IS NOT NULL AND category 或者在图表配置里把null归到其他类目。后者更推荐因为丢掉数据会让总数对不上答辩时被问为什么总数比库里少不好解释。中文乱码。三个地方要同时是utf8mb4建库时的DEFAULT CHARSET、连接时的charset参数、以及 HTML 里的meta charsetutf-8。少一处就是乱码而且乱码的形态还不一样——数据库里是问号说明入库时就坏了浏览器里是问号说明响应头或 meta 有问题。用SELECT HEX(city) FROM records LIMIT 1能看出库里存的是不是正确字节这个排查手段很实用。时间轴乱序。折线图的 X 轴按字符串排序2024-3 会排在 2024-10 后面。根因是月份没补零。用DATE_FORMAT(publish_date, %Y-%m)保证固定宽度排序就正常了。如果数据里publish_date本身是字符串那更要在入库时就转成DATE类型别留到查询时补救。7.3 那些没人提前告诉你的实操细节第一先跑通最小闭环再做美化。所谓最小闭环是抓 20 条数据 → 入库 → 一个接口返回 → 一个图表画出来。这四步在半小时内跑通后面所有工作都是在这个骨架上加东西。如果反过来先做页面布局、再写爬虫、最后调接口中间任何一环卡住你都看不到成果很容易失去动力。第二造一批假数据用于前端调试。在前端开发的阶段接口可能还没写完这时候在 JS 里写一个const MOCK {...}直接喂给setOption把图表样式调好等接口通了把fetch换回来就行。这样前后端可以并行不会被互相阻塞。第三给每个 SQL 都加LIMIT兜底。哪怕你觉得分组之后不会有那么多行也加上LIMIT 200。因为一旦某个字段的取值特别散比如标题字段被误当成类目一个GROUP BY可能返回几千行浏览器渲染几千个柱子会直接卡死。这种卡死看起来像前端写错了实际是最外层没兜底。第四答辩演示用本地数据不要现场跑爬虫。现场网络不可控目标站点可能响应慢、可能返回异常页一旦演示时图表空着这个项目的印象分就废了。正确做法是提前把数据入库、把 MySQL 和 Flask 都跑起来演示时只展示查询—渲染这一段爬虫部分用录屏或者日志截图说明。这不是投机是工程常识——没人会在生产环境演示时现场拉数据。8. 从能跑到能讲答辩前该补的三块内容项目跑通只是及格线真正拉开差距的是你能不能解释清楚每个设计决策背后的理由。我见过不少项目功能都实现了但一问为什么用 MySQL 存而不是 JSON 文件答因为要求用数据库这种回答基本等于没做思考。第一块要补的是口径说明。你的每个图表统计的到底是什么必须能一句话说清。比如平均薪资这一项是(salary_low salary_high) / 2的算术平均还是去掉上下 5% 的截尾平均样本量小于 10 的组有没有排除salary_low为 NULL 的记录有没有参与计数这些细节写在图表的副标题或者 tooltip 里答辩时被追问就能直接指出来可信度完全不一样。第二块要补的是数据质量的数字。采集了多少条、去重后多少条、各字段的缺失率是多少、日期跨度多大。这几个数字能直接说明你对数据的掌控程度。比如共采集 4200 条去重后 3860 条其中薪资字段缺失 512 条13.3%日期字段缺失 87 条2.3%这样一句话比任何形容词都有说服力。第三块要补的是扩展方向的诚实表述。不要说未来将接入机器学习做预测这种空话说具体的、你确实想过的如果把采集频率提到每天一次时间趋势图就可以从月度粒度降到周度能看出更细的波动如果给城市字段加一个行政区划编码映射就可以换成地图热力图比条形图更直观。这类具体到实现路径的表述才叫真的想过。我个人在做这类项目时的体会是四条技术栈本身都不难难的是把它们的边界划清楚然后每一层都只做自己该做的事。爬虫只抓数据库只存和算Flask 只转换ECharts 只画。任何一个环节顺手多做了点最后都会变成排查问题时的那团乱麻。所以如果你现在正要动手别急着写代码花一个小时把字段清单和表结构定下来后面会顺得多。