Python+Flask+爬虫+ECharts：起点小说榜单数据分析平台实战

“Python加Flask做爬虫数据分析平台”听起来像是烂大街的教程标题但我把这套东西完整跑通之后发现水比想象中深起点小说的榜单页有反爬、有动态渲染、字段编码还容易踩坑SQLAlchemy存爬虫数据时如果不规划好模型后面查数据能把你气死ECharts图表看着漂亮数据口径对不上一样白搭。这篇文章我按自己实际开发“基于Flask的起点小说数据分析与可视化平台”的过程来写从爬虫抓取、ORM存储、Flask接口到ECharts可视化大屏全链路讲清楚。不管是拿来做毕业设计、练手项目还是想摸清“爬虫Web开发数据展示”这套完整打法都能直接照着抄。1. 项目概述与整体方案设计1.1 这个平台到底要解决什么问题起点中文网的榜单数据月票榜、推荐票榜、收藏榜本身就是一种公开的、高价值的“市场信号”哪类小说正在流行、哪些作者霸榜、一本书的字数和成绩之间是什么关系。把这些数据定期抓下来再通过可视化展示你可以回答很多拍脑袋答不上来的问题比如玄幻、都市、科幻这几个大类在月票榜上到底谁占比更高前十名小说的字数分布有没有规律是不是字数越多的越容易上榜同一作者的连载新书表现如何和他上一本书相比是涨还是跌我的平台设计成三条核心链路爬虫采集 → 数据入库 → 页面展示。爬虫负责从起点页面抽数据SQLAlchemy负责把数据规规矩矩写进数据库Flask提供查询接口前端ECharts把接口返回的数据画成图表。整个流程没有引入太重的东西每一层都能单独验证、单独改这对新手调试非常友好。1.2 技术选型的取舍逻辑先说为什么选Flask而不是Django。这个项目核心是一个“轻量数据展示平台”不是业务复杂的后台管理系统。Flask的灵活性更强我可以只用一个蓝图加几个路由就把接口串起来Django的admin、ORM、迁移体系反而显得重。当然如果你后续想扩展用户系统、后台管理Django会更省事但就这个项目而言Flask是性价比最高的选择。爬虫这边我用了Requests BeautifulSoup不用Scrapy。原因很直接榜单页结构稳定、字段不多、量级也不大Scrapy的并发调度、中间件、Item Pipeline在这里属于杀鸡用牛刀。Requests直接拿HTMLBeautifulSoup解析20行代码就能搞定一个页面的采集。等你想抓全书详情、上百个分类页、需要断点续爬的时候再迁到Scrapy不迟。存储层我选了MySQL配合SQLAlchemy。SQLAlchemy的价值在于你在Python里写的模型类就是数据库表结构的定义增删改查不写一行原生SQL后续想换SQLite做本地测试只要改一行连接字符串。这对手动拼SQL容易出错的初学者特别友好。可视化这里用ECharts而不是Plotly或者Matplotlib。ECharts是纯前端渲染图表交互性强、支持缩放和tooltip配合Flask返回的JSON数据做数据大屏比后端渲染方案顺手太多。2. 爬虫模块把起点小说榜单数据“请”回来2.1 地址分析定位目标数据源起点小说的榜单页我当时抓的是月票榜URL结构长这样https://www.qidian.com/rank/yuepiao/这个页面里能看到完整的前100名小说书名、作者、分类、简介、月票数。还有一个很关键的细节——它是服务端渲染的HTML源码里直接带着这些数据不需要像抖音、淘宝那样处理JS逆向或接口签名。这就是我选它当靶场的原因让你把注意力放在爬虫主流程上而不是和反爬死磕。如果你要抓推荐票榜、收藏榜把URL里的yuepiao换成tuijian、shoucang就行。我建议把榜单类型参数化这样一套爬虫代码能复用多个榜单。def build_url(rank_type: str, page: int 1) - str: return fhttps://www.qidian.com/rank/{rank_type}/?page{page}2.2 请求构造与反爬规避起点的反爬不算强但裸用默认UA直接请求大概率会被重定向到验证页。我实测下来加一个像样的请求头就行注意两点User-Agent要完整模拟真实浏览器Referer要带起点域名。import requests HEADERS { User-Agent: ( Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 ), Referer: https://www.qidian.com/, Accept-Language: zh-CN,zh;q0.9, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, } def fetch_page(url: str) - str: resp requests.get(url, headersHEADERS, timeout10) resp.raise_for_status() resp.encoding utf-8 return resp.text注意resp.encoding utf-8这行。起点页面的编码是UTF-8但有时候requests会根据响应头猜编码猜错就会出现满屏乱码。强制指定能规避这个坑。还有一点不要在爬虫里加Cookie。模拟登录态的Cookie一旦失效你拿到的是登录跳转页面解析逻辑全崩。爬公开榜单用不着登录加了反而是隐患。2.3 数据解析与字段规范化拿到HTML之后用BeautifulSoup做解析。月票榜的书目区块藏在li标签里每个li包含书名、作者、分类、简介和月票数。不同榜单页的DOM结构可能不同我的经验是先用浏览器的开发者工具直接拷贝selector确认结构之后再用BeautifulSoup的find和select去匹配。from bs4 import BeautifulSoup def parse_rank_page(html: str) - list[dict]: soup BeautifulSoup(html, html.parser) books [] for item in soup.select(.rank-list li): title_tag item.select_one(.book-mid-info h2 a) author_tag item.select_one(.author .name) category_tag item.select_one(.author .type) ticket_tag item.select_one(.book-mid-info .total) if not title_tag: continue # 月票数类似 1.2万需要自己转成整数 ticket_text ticket_tag.get_text(stripTrue) if ticket_tag else 0 books.append({ title: title_tag.get_text(stripTrue), author: author_tag.get_text(stripTrue) if author_tag else , category: category_tag.get_text(stripTrue) if category_tag else , monthly_ticket: convert_to_int(ticket_text), }) return books这里最容易被忽视的是单位换算。页面上显示的月票数是“1.2万”这种缩略文本直接存字符串的话后面没法做数值排序和聚合统计。我写了个convert_to_int来处理def convert_to_int(text: str) - int: text text.replace(万, ) if 万 in text: return int(float(text) * 10000) return int(text.replace(,, ))顺带提醒一句如果你要长期跟踪榜单变化必须在每条数据上打采集时间戳。这样你才能知道这一批数据是哪个时间点的快照后续才能做环比分析比如“这本书上周排第几、这周排第几”。2.4 爬虫运行的稳定性细节榜单页一次请求能拿到全部100名不需要翻页。但如果我们把采集频率定得太高很容易被临时限制。我的做法是控制采集频率每次请求之间至少sleep 2到3秒而且设置一个随机抖动避免固定间隔被识别成机器行为。import time import random def crawl_with_politeness(rank_type: str) - list[dict]: url build_url(rank_type) html fetch_page(url) data parse_rank_page(html) time.sleep(random.uniform(2, 4)) return data另外建议把每次采集结果同时落一份JSON快照到本地比如按日期命名文件。这样即使数据库表改了结构历史数据依然能从原始快照里恢复也算是给自己留了后悔药。3. 数据存储层用SQLAlchemy把爬虫数据管起来3.1 数据库与ORM模型设计爬虫把数据抓回来之后如果只存在列表里重启进程就全没了。所以必须入库。我用SQLAlchemy的ORM模式建了一张novel_rank表字段设计上遵循“该拆的拆、该冗余的冗余”原则id自增主键用来唯一标记每条记录。title书名要为索引因为后面要按书名做查询。author作者名普通字段。category分类用于聚合统计。monthly_ticket月票数转成整数存储。rank_date采集日期用于跟踪历史变化。from sqlalchemy import create_engine, Column, Integer, String, Date from sqlalchemy.orm import declarative_base, sessionmaker Base declarative_base() class NovelRank(Base): __tablename__ novel_rank id Column(Integer, primary_keyTrue, autoincrementTrue) title Column(String(100), nullableFalse, indexTrue) author Column(String(50), default) category Column(String(20), default) monthly_ticket Column(Integer, default0) rank_date Column(Date, defaultNone, indexTrue)这里的String(100)不是随便定的。书名最长也就几十个字100绰绰有余分类字段我用20因为起点的分类名不会超过这个长度。把字段长度控制在合理范围既节省存储也能避免MySQL在联合索引上的长度限制问题。3.2 会话管理与批量写入ORM模型建好之后写库操作的关键点是会话的管理。我建议把会话生命周期封装成一个上下文管理器避免每次写数据都手写session.close()忘记关闭会导致连接池被占满。from contextlib import contextmanager engine create_engine(mysqlpymysql://user:passwordlocalhost/qidian_db?charsetutf8mb4) contextmanager def session_scope(): session sessionmaker(bindengine)() try: yield session session.commit() except Exception: session.rollback() raise finally: session.close()批量入库时不要一条条session.add()数据量大之后性能会很差。用bulk_save_objects或add_all一次性提交。def save_rank_data(books: list[dict], target_date: date): with session_scope() as session: records [ NovelRank( titlebook[title], authorbook[author], categorybook[category], monthly_ticketbook[monthly_ticket], rank_datetarget_date, ) for book in books ] session.bulk_save_objects(records)bulk_save_objects不走ORM的完整事件体系所以如果你的模型里有onupdate钩子或者复杂的校验逻辑它不会触发。但在这种纯插入场景里它能省掉大量Python层面的开销写入速度快一倍以上。3.3 数据清洗与类型转换爬虫过来的数据脏的比你想象的多。分类字段偶尔带换行书名首尾有空格月票数出现“万”单位……这些在入库前就必须清干净。我的洗数据三板斧strip()去掉首尾空白和换行。统一分类名比如“玄幻”和“ 玄幻 ”合并成同一个。数值类型做兜底try...except挂掉就填0绝不让一条脏数据拖垮整批写入。def clean_book(book: dict) - dict: return { title: book[title].strip(), author: book[author].strip(), category: book[category].strip() or 未知, monthly_ticket: safe_to_int(book[monthly_ticket]), }洗数据的另一个目的是为后续聚合查询铺路。如果不统一分类名“科幻”和“科幻 ”会统计成两个分类图表上多出莫名其妙的柱子排查到半夜才发现是空格在捣乱。4. Flask后端API接口与业务逻辑4.1 项目结构与Blueprint拆分Flask项目最忌讳把所有路由堆在一个文件里。这个项目我按功能拆成两个蓝图main_bp负责渲染页面api_bp负责返回JSON数据。目录结构如下qidian_analysis/ ├── app.py ├── models.py ├── db.py ├── blueprints/ │ ├── __init__.py │ ├── main.py │ └── api.py ├── templates/ │ └── index.html └── static/ └── echarts.min.jsapp.py只做三件事初始化Flask实例、注册蓝图、创建数据库表。from flask import Flask from db import init_db from blueprints.main import main_bp from blueprints.api import api_bp app Flask(__name__) app.register_blueprint(main_bp) app.register_blueprint(api_bp, url_prefix/api) init_db() if __name__ __main__: app.run(debugTrue, port5000)把蓝图职责切割清楚的好处是页面路由和接口路由互不干扰前端调试接口时可以直接访问/api/xxx看JSON不用去猜数据到底是怎么渲染出来的。4.2 查询接口与参数化统计平台最核心的接口是分类统计它回答“月票榜前100本书里各分类占了多少”。用SQLAlchemy的group_by配合func.sum就能拿到聚合值from sqlalchemy import func from flask import jsonify, request from models import NovelRank, session_scope api_bp.route(/category_stats) def category_stats(): with session_scope() as session: rows ( session.query( NovelRank.category, func.sum(NovelRank.monthly_ticket).label(total_ticket) ) .group_by(NovelRank.category) .order_by(func.sum(NovelRank.monthly_ticket).desc()) .all() ) return jsonify({ categories: [r.category for r in rows], values: [r.total_ticket for r in rows], })注意这里我在session_scope上下文里做了查询提交之后还能继续访问rows吗可以因为查询已经执行结果已经物化到列表里了。但有坑如果你在会话关闭之后才访问rows的懒加载属性就会报DetachedInstanceError。所以我直接return jsonify之前把数据全取出来不拖泥带水。再做排行榜接口按月份票数降序取前10api_bp.route(/top_books) def top_books(): limit request.args.get(limit, 10, typeint) with session_scope() as session: rows ( session.query(NovelRank) .order_by(NovelRank.monthly_ticket.desc()) .limit(limit) .all() ) return jsonify([ { title: r.title, author: r.author, category: r.category, monthly_ticket: r.monthly_ticket, } for r in rows ])接口参数化是个好习惯比如limit通过URL参数控制而不是写死10条。这样前端想展示Top5还是Top20不用改后端代码。4.3 模板渲染与接口返回页面入口main_bp只做一件事渲染index.html模板。数据全部由前端通过fetch请求接口拿到这种“前后端分离”的模式是这个项目最舒服的地方main_bp.route(/) def index(): return render_template(index.html)为什么不直接在Flask里把数据渲染进模板因为ECharts需要的数据格式是JS对象如果服务端渲染你得把Python的dict序列化成JSON塞进模板的script标签转义、引号、类型一堆问题。用fetch接口拿数据前端拿到的是干净JSON直接喂给ECharts逻辑清晰得多。Flask的jsonify默认会把中文转成Unicode转义序列\uXXXX浏览器能正常解析但人看着难受。如果想返回可读的中文加上app.config[JSON_AS_ASCII] False5. 可视化大屏ECharts带你一眼看清榜单趋势5.1 前端技术栈与选型前端我只有一个页面左侧放分类占比饼图中间放月票榜Top10柱状图右侧放一本小说连续两周的月票变化折线图。不用Vue、不用React原生HTML加ECharts的CDN文件就够了。ECharts的优势在现代前端可视化里非常明显官方文档齐全社区案例多中文支持好动画流畅。你的需求如果是“把数据快速画成能看的图”选ECharts基本不会错。如果你的项目后续要做大屏拼接、多图表联动ECharts同样扛得住。在页面里引入ECharts我用的是本地static/echarts.min.js不是CDN。原因很简单CDN依赖外网部署到内网环境或者服务器宕机时图表就白了。把JS文件下载下来放在自己的静态目录里一条相对路径搞定script src{{ url_for(static, filenameecharts.min.js) }}/script5.2 核心图表的配置思路分类占比用饼图最直观。ECharts的配置相对繁琐我的经验是先写死一个option对象跑通再换真实数据。这样能快速定位是配置问题还是数据问题。const chart echarts.init(document.getElementById(categoryChart)); fetch(/api/category_stats) .then(res res.json()) .then(data { const option { tooltip: { trigger: item }, legend: { bottom: 0 }, series: [{ name: 分类占比, type: pie, radius: 60%, data: data.categories.map((name, i) ({ name: name, value: data.values[i] })) }] }; chart.setOption(option); });这里有个细节ECharts饼图的data需要[{name: xxx, value: 123}]这样的对象数组而接口返回的是两个平铺数组categories和values。用map把它们组合成ECharts需要的格式别直接塞。Top10柱状图则负责展示头部小说我用横向条形图这样书名能完整显示不会截断const barChart echarts.init(document.getElementById(topChart)); fetch(/api/top_books?limit10) .then(res res.json()) .then(data { barChart.setOption({ grid: { left: 120 }, xAxis: { type: value, name: 月票数 }, yAxis: { type: category, data: data.map(b b.title) }, series: [{ type: bar, data: data.map(b b.monthly_ticket), itemStyle: { color: #e6a23c } }] }); });横向条形图的y轴是分类轴x轴是数值轴这和普通的柱状图是反过来的第一次写容易搞反。5.3 页面布局与数据刷新机制大屏布局我用的是CSS Grid三栏等宽顶部一个标题栏。这块不用什么高深技术关键是每个图表容器必须有明确的高度否则ECharts会算出一个0高度的canvas图表白屏.layout { display: grid; grid-template-columns: 1fr 1fr 1fr; gap: 16px; padding: 16px; } .chart-box { height: 480px; background: #fff; border-radius: 8px; }页面加载时自动请求所有接口。如果需要定期刷新数据我建议用setInterval配合location.reload()或者重新fetch。简单做就整页刷新script setTimeout(() location.reload(), 5 * 60 * 1000); /script但更优雅的方式是只刷新需要更新的图表数据不整页刷新。这里要注意ECharts实例一旦setOption过再次setOption会合并新配置而不是从头渲染。如果数据变化了但配置没变图表不会更新。强制清空可以用chart.clear()再setOption稳妥起见我每次刷新前先clear()。6. 常见问题与排查实录6.1 爬虫被拦截怎么办初版爬虫我直接用默认Python UA去请求结果拿回来的是一段验证提示。后来加了完整浏览器UA和Referer就正常了。但这只是最基础的反爬手段。如果某一天你发现请求返回的页面里没有榜单数据优先排查三个方向graph LR A[请求异常] -- B{状态码判断} B --|200 但为空| C[检查页面结构是否改版] B --|302| D[检查Cookie和UA] B --|403| E[降低频率或换IP]一个非常容易踩的坑是代码里用了requests.Session然后在某个地方误设置了一个失效的Cookie导致后续请求全部带错状态。我的建议是不要手动管理Cookie让Session自动处理除非你明确知道自己在干什么。6.2 中文乱码与VARCHAR长度问题乱码这个事我在项目里至少碰了三次每次都来自不同环节第一次是requests把GBK编码的页面当成了ISO-8859-1解决方法是手动指定resp.encoding utf-8。第二次是MySQL表用了默认的utf8字符集存emoji起点书名标题里偶尔有直接报错解决方法是建库时指定utf8mb4。第三次是Flask返回的中文在浏览器里显示成\uXXXX上面说过设置app.config[JSON_AS_ASCII] False就好。String(100)这个长度也要防着点。书名理论上不会超长但如果你改了爬虫去抓简介字段长度不够SQLAlchemy在插入时会直接抛数据截断异常。所以字段长度宁多勿少尤其是你后期想扩展字段的时候。6.3 SQLAlchemy查询性能问题这个平台数据量小查询性能不是瓶颈但如果你一天抓一次、抓了三个月表里也就几千条记录完全不用担心。真正的问题出在连接管理上。如果每个请求都新建一个engine数据库连接池会疯狂建连慢且不稳定。正确做法是engine全局单例只在进程启动时创建一次engine create_engine( mysqlpymysql://user:passwordlocalhost/qidian_db?charsetutf8mb4, pool_size10, pool_recycle3600, echoFalse, )pool_recycle要特别注意MySQL默认wait_timeout是8小时连接池里的连接如果长期不用会被MySQL服务端断开。下次从池里取出来就是一个死连接。设置pool_recycle3600让连接池每小时回收一次能有效避免MySQL server has gone away这个经典报错。6.4 ECharts白屏与数据格式不匹配白屏90%是容器高度问题剩10%是JS报错。我建议打开浏览器控制台看有没有红色的报错信息。最常见的报错是data[i] is undefined这通常说明接口返回的数据和你预期的结构不一样。接口返回的字段名如果改了前端map映射就会拿到undefined图表自然没法渲染。调试技巧在fetch拿到数据之后先console.log(data)确认结构再把数据硬编码进option里一步步缩小问题范围。这比对着空白的图表瞎猜效率高得多。7. 项目扩展与后续想法平台跑通之后我给它加了一个新东西按周对比同一本书的月票变化。这个需求很简单因为我已经设计了rank_date字段只要在接口里加一个where条件按书名过滤、按日期排序折线图就出来了。这一步的代码量不超过20行但平台的价值一下就从“静态榜单快照”升级成了“趋势追踪工具”。如果你想继续往深里做可以考虑这几个方向多榜单数据合并把月票榜、推荐票榜、收藏榜存进同一张表用rank_type字段区分前端做一个下拉切换。引入Scrapy框架把Requests脚本改造成Scrapy爬虫用Item Pipeline做数据清洗用CronJob定时调度适合做大范围数据采集。结合Pandas做分析虽然项目叫数据分析但单纯用SQL聚合其实不够“数据分析”。把SQLAlchemy查出来的结果交给Pandas算相关性、画箱线图、做趋势预测会更有分析深度。部署上线本地跑通之后可以用Gunicorn加Nginx部署在云服务器上。生产环境里记得把debugTrue关掉否则错误信息会直接暴露给访问者这个安全习惯要养成。回到这个项目本身我的体会是一个看起来简单的“爬虫Flask可视化”项目真正走一遍之后能把数据采集、存储建模、接口设计、前端展示这四件事的底层逻辑串起来。这四件事看起来独立实际环环相扣爬虫字段设计得不好数据库表就要多改数据库表结构不规范查询接口就要多绕弯接口字段设计得不清爽前端图表就得做各种兼容处理。所以我建议你动手做这个平台的时候不要急着爬数据先把整个链路的字段设计走一遍——想清楚最后要展示什么图表、图表需要什么维度的数据、数据从哪里来。这一层想清楚了后面每写一行代码都会很顺。最后分享一个我踩过几次坑之后养成的习惯每爬一次数据就留一份JSON快照。数据库能回溯但SQL表结构一改旧数据可能就被干掉了。留快照是最后的兜底成本几乎为零但真到要用那天就值回票价了。