Python3.9+Selenium小说爬虫运行499-500章触发RecursionError问题咨询

为什么触发阈值只有500章，远低于Python默认1000次递归上限 #

• 脚本当前的调用逻辑是CopyChapter抓完当前章节后，直接调用NextChapter；NextChapter完成下一章点击后，又反向回调CopyChapter，两个函数形成双向递归调用链，没有提前返回释放栈帧。
• 每抓取1章，会在Python调用栈上压入2层栈帧：一次是CopyChapter的入栈，一次是NextChapter的入栈。Python默认栈深度阈值约1000，计算下来499章就会占用499*2=998层栈，刚好顶到栈上限，完全匹配你观察到的“每抓499/500章就报错”的现象。
• 堆栈最末段显示的email模块解析报错，是栈内存被占满后，刚好在Selenium发起网络请求、解析HTTP响应头的环节触发的溢出异常，不是这块标准库代码本身的问题，不需要去修改相关逻辑。

修复方案 #

核心是彻底改掉递归调用的结构，换成栈深度固定的循环逻辑，从根源上解除章节总数的限制：

• 移除两个函数互相调用的递归代码，把流程改成while True无限循环：
  1. 初始启动时加载第一章的网页地址
  2. 每轮循环首先解析当前页面的章节内容，存入对应TXT文件
  3. 查找页面上的“Next Chapter”按钮，完成点击操作，等待页面加载跳转
  4. 对比跳转前后的页面URL，如果URL没有变化（即点了按钮也没跳走，说明到了小说完结/最新章节），退出循环关闭浏览器
• 顺手优化原脚本的几个可维护性问题：
  • 把原来遍历每个<p>标签就开关一次文件的IO操作，改成先把整章的文本收集到内存变量里，章节内容抓完后一次性写入文件，减少磁盘读写开销，也避免频繁文件操作导致的文件损坏。
  • 替换已经被Selenium废弃的旧API：driver.find_element_by_link_text("Next Chapter")改成最新的driver.find_element(By.LINK_TEXT, "Next Chapter")写法，适配最新版本的依赖包。
  • 给下一章按钮的查找加异常捕获：如果找不到下一章元素，直接判定抓取完成，不用单纯依赖URL判断完结状态，避免ISP网络波动导致的URL读取异常、误判完结的问题。

内容的提问来源于stack exchange，提问作者James