小说功能复盘
更新: 2026/8/25 字数: 0 字 时长: 0 分钟
1. 起因
最开始做小说功能，其实没有想太复杂。 一开始只是打算把自己想看的书，给单独做一个页面，然后更新什么的，就不用去别人网站天天看进度。 所以第一步非常简单： 随便找了一个小说网站，然后开始分析它的数据结构。 刚开始以为小说网站可能比较复杂，但是实际拆开以后发现，大部分小说网站其实核心结构非常固定。 基本可以总结为三板斧：
- 小说列表页
- 小说详情页
- 章节正文页
2. 小说网站结构分析
2.1. 小说列表页
第一步就是获取所有小说信息。 一般就是网站首页或者排行榜页面。 需要获取的小说的一般信息
这里主要的问题就是： 很多网站的小说数量非常多。是需要不断翻页,一开始写的循环，一直获取，结果实际运行发现太久了，就改了下200本开始同步一次
2.2. 小说详情页
拿到小说列表以后，就进入第二步。 访问具体一本小说详情。 详情页主要负责获取：
- 小说完整信息
- 全部章节目录
2.3. 章节正文页
最后一步就是获取真正的小说内容。 这一部分数据量也是最大的地方。
- 所以后面存储问题也主要出现在这里。
3. 不同小说网站解析
把三个步骤跑通以后，由于发现他不支持多线程，会被对方反爬。接下来就只能再研究不同小说网站的结构。
目前主要遇到了两种情况。
3.1. 第一种：返回静态页面
这种网站比较传统。 请求以后直接返回 HTML。 这种主要使用：
- requests
- BeautifulSoup 处理：
- HTML标签清理
- 广告删除
- 空白处理
- 特殊字符过滤
例如有些正文里面会混入（这个懒）：
请收藏本站
最新网址
广告内容需要额外清洗。
3.2. 第二种：接口返回JSON
这种相对简单。 有些网站它本身前端和后端分离而且看接口返回值居然也没有字段加密。 这种就简单多了（这种一般可以开俩线程）：
4. 反爬问题
研究过程中也遇到了小说网站的反爬。 目前遇到最多的是： IP限制。
但是比较有意思的是： 一般不会永久封禁。 等待一段时间以后，又可以继续访问。
理论上解决方式：
- IP代理池
- User-Agent随机
- 请求频率控制
- Cookie维护
但是因为我的目的主要是学习一下 所以没有深入研究。 简单了解了一下逻辑。
5. 爬取字段设计
不同网站返回的数据结构不一样。 所以需要统一字段。
不同网站可能存在相同ID，于是用了来源前缀 + 原始ID 并且使用：书名 + 来源ID作为联合判断。 避免重复数据。
6. 多爬虫代码优化
最开始： 每一个网站都是单独写。 后来发现： 三个爬虫里面很多逻辑其实一样。
所以后面进行了代码优化。 抽出来一套 MongoDB DAO。
这样不同网站只负责： 解析数据。 数据库操作统一处理。
7. 最大的坑：存储空间
整个小说系统里面，最大的问题其实不是爬虫。 而是存储。 刚开始设计非常简单： 章节正文直接放MongoDB。
刚开始觉得还行，然后就24小时跑着，没两天就爆满了，然后又去看来各个厂商的云硬盘，存储桶（都得加钱） 最后买个了便宜的cos用于测试学习，就只爬了几本写进去txt文件，每次看都得消耗流量，虽然不多，但是怂。而且后续迁移服务器成本变高了。
8. 阅读系统设计
前端阅读部分主要实现：
- 阅读历史
- 收藏
- 书架
- 阅读进度
这些数据目前采用本地保存
- 减少服务器压力
- 查询速度快
- 实现简单
9. 过程中使用的一些优化
整个过程里面也实践了一些之前没有深入使用的技术。
9.1. Python管道优化
主要用于： 爬取流程优化。 减少中间重复处理。
9.2. 前后端分页
主要是优化数据库以及索引，因为后续还希望加历史记录之类的，那就需要用的MySQL的用户系统了，目前主要避免一次加载大量数据。
9.3. 多线程同步接口
章节同步时： 一个请求一个章节速度太慢。 所以增加线程池，来选择性跑某个网站
10. 整个项目总结
这个小说功能其实从最开始一个简单想法。 慢慢扩展成了一套完整的数据流程。
整体链路：
小说网站
↓
数据采集
↓
数据清洗
↓
MongoDB存储基础元数据
↓
COS文件存储正文（相对云硬盘算是便宜的）
↓
后端接口
↓
Vue阅读页面
↓
用户阅读中间耗时10天不断改版：
- 网站结构分析
- 爬虫开发
- 多来源适配
- 数据库设计
- 存储优化
- 接口调整
- 前端阅读实现及移动端优化
写代码只是其中一部分。 更多的问题其实在，主要架构的设计，存储的结构剩下的无非的怎么去实现 数据怎么来。 数据怎么存。 数据怎么管理。 数据怎么舒服地使用。