把一条 URL 或者一个文件丢进程序等它吐出一张干净规整的表格——这基本就是“提取”这件事的全部目标。但真正做过数据提取的人心里都清楚让人头疼的很少是提取逻辑本身而是过程里冒出来的“常见异常”。编码乱码、页面结构调整、接口突然 403、超时重试把任务拖成马拉松……这些异常本身不可怕可怕的是你不知道它为什么发生只能一遍一遍重跑甚至把脚本改成自己都看不懂的补丁。这篇文章不围绕某个特定框架展开而是把我在实际提取任务里遇到的高频异常按链路拆开讲请求、解析、清洗、存储、文件解析、监控。每一类都会说明它是什么、为什么会发生、怎么快速定位并给出可以直接照抄的排查套路。如果你正准备做数据采集、报表抽取或者正被某个百思不得其解的 Bug 困住这篇文章能省下你不少试错时间。1. 提取任务中的异常为什么如此顽固1.1 一条提取链路里藏着三层风险很多人遇到异常就急着改代码结果往往按下葫芦浮起瓢。根本原因在于提取任务从来不是“一步到位”的操作它是一条完整链路先发请求拿数据再做结构解析然后做字段清洗最后落库。每一层都有自己专属的异常家族而它们表现出的症状可能完全一样。举个例子一个爬虫抓取商品列表页页面上明明有 20 条商品数据但程序只提取到了 5 条。这可能不是选择器写错了而是页面用了懒加载后 15 条数据是滚动后才动态加载的。看起来是“解析层的异常”本质却是“渲染层”的问题。再比如你从某个接口拿到 JSON解析时报错表面看是 JSON 格式问题实际可能是服务端返回了压缩编码或响应头里根本没有声明字符集。所以我的第一建议永远是遇到异常先给异常分层。判断这个问题发生在“网络请求”“内容解析”“语义清洗”还是“数据存储”哪个阶段再决定从哪一层下手排查。这样可以避免你在错误的方向上反复折腾。1.2 先给异常分个类再动手修我习惯把提取任务中的异常分成五个大类连接层异常、解析层异常、语义层异常、存储层异常、环境依赖层异常。下面这张表是我在实际项目中总结出来的异常现象和排查方向基本都能对上号。异常类型典型现象可能原因优先排查方向连接层超时、连接重置、403/429限流、防火墙、代理失效、连接池复用请求频率、退避策略、响应码解析层选择器抓不到、JSON 解析失败、乱码页面结构变化、动态渲染、编码判断错误原始响应快照、渲染方式、字符集语义层字段缺失、类型转换失败、日期错乱数据格式不统一、空值处理不当数据样本统计、清洗模板存储层主键冲突、写入失败、乱码入库字符集设置、唯一约束、类型不匹配表结构、数据库字符集环境依赖本地正常、服务器报错依赖版本不一致、缺少底层库、时区差异运行环境对比、依赖锁文件这个分类不是学术定义而是为了快速定位。你不需要背下所有异常类型只需要在出现问题的时候能判断出它更贴近哪一层。定位到层之后再往下看具体原因就容易多了。2. 网络请求层的异常超时、限流与连接重置2.1 超时不是时间不够是链路里某个环节掉链子只要做提取任务就一定遇到过超时。但超时它分两种一种是 TCP 连接建立的超时叫 connect timeout另一种是连接建立后等待对方返回数据的超时叫 read timeout。很多人不理解这两者的区别我打个比方connect timeout 相当于你打电话拨号对方一直不接read timeout 相当于电话已经接通了但对方就是不说话。排查思路完全不一样。前者大概率是目标服务器不可达、DNS 解析失败、端口被墙后者往往是目标服务处理慢、请求参数不对导致服务端卡死或者你的并发太高把对方压垮了。在一个采集脚本里我通常这样设置超时连接超时 5 秒读取超时 10 秒。如果页面数据量特别大读取超时适当放宽到 20 秒。这里有一个原则超时时间别设太长更别全局统一。因为一旦某个 URL 卡住默认超时时间太长会让整个任务卡死很久甚至拖垮整个任务队列。最好在每个请求级别独立设置超时而不是依赖请求库的全局配置。import requests resp requests.get( url, timeout(5, 10) # 连接超时5秒读取超时10秒 )你可能会问超时之后再重试一次不就完了吗关键问题是重试也要讲究策略。如果服务器已经压力很大你立刻用相同参数再打一次只会加重对方负担自己也大概率继续超时。比较好的做法是退避重试后文会专门聊。2.2 连接重置与长连接陷阱如果说超时还有规律可循连接重置Connection Reset就是最让人摸不着头脑的一种。它典型的报错是“Connection reset by peer”或者“远程主机强迫关闭了一个现有的连接”。我排查过很多次这类问题最终发现大多数都指向同一个地方短时间大量请求触发了服务器的安全策略。服务端为了防爬会对异常流量直接断连。解决办法是从自身降低请求密度而不是想办法“伪装”成正常流量。不过还有一个容易被忽略的原因HTTP 连接复用。某些请求库默认会启用连接池复用一个 TCP 连接去发送多个请求。如果服务端已经关闭了这个连接而客户端不知道还继续拿这个“已死”的连接发请求就会触发连接重置。这种情况下最简单的验证方法是把连接池关掉或者每个请求重新建一个会话看问题是否消失。如果问题消失那就说明是长连接复用导致的。更稳妥的做法是为每个目标域名设计独立的连接策略。高并发采集时使用带连接池的 Session 能明显提升性能但要设置 max_connections 和 max_keepalive 参数避免连接无限堆积。另外要监控连接池的存活状态定期清理陈旧连接。2.3 响应码 403、429 背后的限流与鉴权提取任务里最“显眼”的异常是突然间全部请求都返回 403 Forbidden 或 429 Too Many Requests。403 通常是没有权限可能是少了某个请求头、Cookie 失效、Token 过期而 429 就是单纯告诉你你请求得太快了。先说 403。很多时候你本地用浏览器访问页面一切正常但脚本一请求就返回 403。这通常是因为服务端通过请求头特征识别的。浏览器会自动带上很多请求头而代码里的请求头往往很薄。最简单的排查方法是把浏览器开发者工具里看到的完整请求头复制过来替换掉脚本里的请求头再试一次。别只复制 User-Agent很多服务端也会校验 Referer、Origin、Accept-Language 等字段。再说 429。处理 429 的核心思路不是继续硬闯而是降低请求频率。我在写采集脚本时会给每个目标设置一个最小请求间隔。比如 1 秒一次如果发现返回 429就把间隔动态拉长到 2 秒、4 秒、8 秒呈指数级退避。import time import random delay 1 for attempt in range(5): resp fetch(url) if resp.status_code 429: sleep_time delay * (2 ** attempt) random.uniform(0, 1) time.sleep(sleep_time) continue break这里加入随机抖动Random Jitter非常关键。如果所有请求都在固定间隔 1 秒后重试那大量并发任务会形成固定节奏的请求波依然很容易被识别。加一个 0 到 1 秒的随机值会让请求节奏更接近真实访问。当然做任何提取任务都要遵守目标平台的访问规则尊重 robots 协议不对目标服务器造成明显压力。这是底线。2.4 重试逻辑应该怎么写才不算瞎重试大部分提取脚本都有重试逻辑但很多人的写法是“失败就重试重试还失败就再重试”。这种方式不仅浪费资源还会把偶发问题变成持续问题。我自己的重试策略遵循三个原则能重试的才重试、重试次数有限、退避要递增。什么样的异常可以重试连接超时、5xx 状态码、连接重置这类问题可以重试。而 403、401 这类鉴权异常重试多少次都一样不值得重试。参数错误、JSON 解析失败属于代码本身的问题也不该靠重试解决。连接层异常重试 3 次指数退避间隔从 1 秒开始5xx 状态码重试 2 次间隔从 2 秒开始429 状态码重试 5 次退避间隔按响应头 Retry-After 优先其次指数退避鉴权失败、参数错误不重试直接记录日志重试逻辑之外还必须设置一个“最大重试次数”的硬性上限。否则某个 URL 持续失败你的任务会在它身上无限消耗时间。我见过最夸张的一次是因为某个 URL 永远超时整个任务队列被它堵死后面的数据一条都没跑。后来我加了一个熔断机制同一 URL 连续失败超过 5 次就把它移入失败队列不再自动重试。3. 数据解析层的异常页面结构、动态内容与编码乱码3.1 选择器失效页面改版和动态渲染的两种玩法做网页提取选择器失效是最常见的解析异常。今天脚本还跑得好好的第二天突然抓不到数据了。很多人第一反应是“页面改版了”但实际上还有另一个隐蔽原因动态渲染。页面改版的情况好理解CSS 类名变了、DOM 结构调整了原来的选择器自然就失效了。这种问题的排查思路很简单把页面源码拉下来对比实际 DOM 结构和选择器找出差异。关键是别只看浏览器里看到的页面效果因为浏览器显示的可能是 JS 运行后的最终效果而脚本拿到的可能是原始 HTML。一定要对比脚本真正拿到的 HTML。动态渲染则是另一个世界。如果页面数据是 JavaScript 异步加载的脚本直接抓取到的 HTML 里压根没有目标数据。常见的动态渲染手段有三种Ajax 异步请求、懒加载、iframe 嵌入。Ajax 场景下你可以直接找数据接口省去解析 HTML 的麻烦懒加载场景下数据往往在某个滚动事件后才会请求你需要模拟滚动或用无头浏览器iframe 场景最坑数据在子页面里必须定位到 iframe 的 src 再发一次请求。我建议在解析层做一层“抽象”不要把所有选择器写死在业务逻辑里。定义一个配置化的字段映射表把每个字段的 CSS/XPath 选择器都放在配置里。这样页面结构变了改配置就能恢复不用重新发版。多花这点时间后面能省很多事。3.2 编码异常乱码的源头其实只有两种乱码是提取任务里存在感最强的异常没有之一。但只要弄明白编码错误是怎么产生的这个问题就一点不神秘。乱码的源头基本只有两类第一类是服务器返回的字节流编码和解析时使用的编码不一致第二类是服务器响应头里声明的字符集和实际内容不一致。第一类情况很好理解你用 UTF-8 解码 GBK 编码的数据得到的必然是一堆乱码。问题在于怎么识别实际编码。我的做法是优先查看响应头里的 Content-Type 字段比如Content-Type: text/html; charsetgbk这通常是最可靠的信息源。如果响应头没有声明编码再根据网页内容里meta charsetgbk去判断。如果两个都没有就只能靠启发式检测了。import requests import chardet resp requests.get(url) encoding resp.encoding or utf-8 # 如果响应头未声明 charset用 chardet 推断 if resp.encoding is None or resp.encoding ISO-8859-1: encoding chardet.detect(resp.content)[encoding] resp.encoding encoding text resp.text这里有一个很多人踩过的坑某些服务端在响应头里没声明编码时请求库会默认把编码识别为 ISO-8859-1进而导致解码错误。当你看到“锟斤拷”这种奇异字符时基本都是把 UTF-8 字节流按 GBK 或 Latin-1 解码导致的。排查时不要凭肉眼猜直接用工具检测原始字节流一次就能锁定。第二类情况更隐蔽。响应头声明了 charsetutf-8但页面实际内容是 GBK 编码这时即使你完全按响应头来解码依然会乱码。这种一般是服务端配置出错了需要以实际内容为准用前面提到的检测逻辑覆盖响应头的声明。3.3 JSON/XML 解析失败的真面目解析 JSON 和数据提取紧密相关尤其当目标数据是通过接口返回的时候。JSON 解析失败的报错信息往往很直接比如Expecting value、Expecting property name enclosed in double quotes。这些报错看着吓人原因归类后也就那么几种。非法字符是最常见的原因。比如返回内容里带了 UTF-8 BOM 头某些解析器就会直接报错。解决办法是先对文本做一次 BOM 清理再解析。其次是单引号替代双引号或者在字符串里出现了未转义的控制字符这些都会让标准 JSON 解析器崩溃。处理办法是在解析之前先对原始文本做一个预处理把常见的非法字符替换掉。看一个很典型的例子接口返回如下{name: 张三, age: 18}这本身不是合法的 JSON因为键和字符串都用了单引号。用 Python 的 json 模块解析会直接报错。但它的“来源”往往是某个框架的错误输出或日志文件。你可以先用正则或字符串替换把单引号换成双引号再尝试解析。如果出现嵌套引号替换逻辑就得写得更严谨或者直接放弃用 JSON 解析改用其他更宽容的解析方案。XML 解析失败的排查思路类似但多了两个坑命名空间和实体字符。命名空间会让 XPath 失效实体字符不处理好会被解析器视为非法。遇到 XML 解析问题时我习惯先确认根元素和命名空间声明再写路径表达式。4. 字段清洗与落库阶段的隐性异常4.1 None、空字符串、缺字段处理逻辑完全不同提取数据并不止于“拿到字段”还要把字段整理成能用的形态。这个阶段最常见的异常是代码在处理缺失值时直接报AttributeError或者KeyError。但更让人头疼的是数据“没有内容”的多种表现方式。同样是缺失有的字段是None有的是空字符串有的是字段键完全不存在有的则是一个 NoneType 字符串 null。如果你不加区分地统一处理就会把有值的数据误判为空或者把空数据当成合法值写入。我自己的处理原则是None表示未知需要根据业务决定是丢弃还是填默认值空字符串表示无内容通常可以直接替换为 0 或者空字段键不存在则意味着数据结构本身有问题需要检查解析层。定义一个统一的清洗入口而不是在业务代码里到处判断会让这类异常的排查容易得多。def clean_value(value, default): if value is None: return default if isinstance(value, str) and value.strip() in (, null, NaN): return default return value这样写的好处是所有字段统一走清洗函数后面出问题只需要维护这一处入口不需要去翻几十个业务字段的手工逻辑。4.2 类型转换和日期格式异常为何高发提取任务里类型转换异常的高发程度绝对排前三。它们的共同特征是数据样本规模小的时候看起来一切正常一跑全量任务就崩。最典型的例子是字符串转数字。表面上你提取到的是 1234看似能顺利转成 int。但真实数据里混着 1,234、1234.0、1234元、等 1234 元左右这种五花八门的格式。一旦碰上你的转换逻辑就会崩。处理思路是先做标准化移除货币符号、千分位逗号、中文单位再根据实际格式选择转换方式。日期格式更是重灾区。同一个字段里可能出现 2024-01-05、2024/1/5、2024年1月5日、Jan 5, 2024、时间戳甚至 Excel 序列号日期。每次遇到一种新格式就加一个分支代码会越来越臃肿。我建议用一个日期解析工具库统一处理并且在实际项目里先跑一遍样本数据统计日期格式的分布再决定处理策略。不是每个日期都需要精确解析有些场景下只需要提取年份就够了。4.3 存储异常不只在数据库还可能在字符集数据清洗完成后的落库阶段同样会冒出一堆异常。最经典的是主键或唯一约束冲突重复抓取时同一主键的数据第二次写入会直接报错。处理方案通常是“存在则更新不存在则插入”也就是 UPSERT 语义。不同数据库的写法不同但思路一致。还有一类很容易被忽视的异常是字符集。数据库表、连接字符串、字段本身的字符集如果和提取到的数据编码不一致就会出现数据能写入、但查出来是乱码的情况。注意这和前面讲到的响应解码乱码不是一回事。有时你的代码里看到的数据完全正常写入数据库后却变乱这基本就是数据库连接层字符集设置的锅。浮点精度问题也值得提一嘴。在提取金额、交易数据时别直接用浮点类型存储否则会出现 0.1 0.2 不等于 0.3 的精度损失。金额类字段建议用整数类型的分或者使用高精度数值类型来存。写存储逻辑前最好先检查一遍目标表的字段类型、字符集、约束规则。这些信息在运行时报错前就能看出来省得最后被一个主键冲突搞得满头大汗。5. 文件型提取的专项异常PDF、Excel、CSV5.1 PDF 提取扫描件不是文本是图片除了网页和接口文件型提取也是日常工作里绕不开的部分尤其是 PDF。PDF 提取的异常很有特点因为它表面上是一个文件里面却可能藏着两种完全不同的形式。文本型 PDF 提取相对简单直接用解析库就能拿到文字。但扫描版 PDF 就完全是另一回事了——页面上的每个字本质上都是图片里的像素解析库拿不到任何文字。如果硬用文本解析得到的要么是空字符串要么是一堆没有意义的符号。解决办法是引入 OCR 能力把页面渲染成图片再识别文字。实际操作中PDF 表格提取比纯文本提取更痛苦。哪怕文件本身是文本型的表格线、单元格合并、跨页断行都会把提取结果切割得七零八落。最常见的问题是同一表格单元格里的文本被解析成了多行导致多列数据错位。我的建议是优先使用支持表格结构解析的专用库如果解析结果依然不理想就把 PDF 页面转成图片走 OCR 表格识别虽然速度慢但准确率往往更高。5.2 Excel 提取合并单元格和类型混搭Excel 提取相对友好但也不是没有坑。最大的坑是合并单元格。如果一个单元格跨行合并那么合并区域里只有左上角那个单元格有值其他单元格读出来是空的。这在提取“每行一条记录”的场景里会导致大量空值。解决办法是读取时检测合并单元格信息把左上角的值填充到整个合并区域。这一步必须在数据解析阶段做不能留到清洗阶段。因为合并单元格是按坐标记录的清洗阶段拿到的数据已经丢掉了坐标信息没法再还原。Excel 里的数据类型混搭也很麻烦。有时候一列数字里混着几个文本格式的单元格或者日期列里既有日期对象又有字符串。用 pandas 读取的时候它可能会自动把整列推断成字符串导致后续计算处理异常。我建议读取 Excel 时显式指定列类型不要把类型推断完全交给工具。5.3 CSV 提取分隔符和 BOM 的战争CSV 看起来最“简单”但它在大规模数据提取场景下反而是异常率最高的文件格式之一。第一个坑是分隔符。很多 CSV 根本不是用逗号分隔的有制表符分隔的 TSV有分号分隔的欧洲格式。用默认分隔符读取整个表格会变成一列或者字段错位。判断方法很简单打开原始文件的头部几行统计每一行里不同分隔符出现的次数取最一致的。第二个坑是 BOM。用记事本或者某些工具保存的 UTF-8 CSV 会带 BOM 头即文件开头有三个不可见字节。读取后第一个字段名会变成\ufeff字段名看起来没毛病但字段匹配永远失败。处理方式是一开始读取文件时就指定正确的编码或者读取后显式去除 BOM。第三个坑是换行符。字段内部如果包含换行符而 CSV 又没有正确处理引号读取时会莫名其妙地多出几行。这也是 CSV 提取异常里最隐蔽的一种。处理 CSV 的一个实用习惯是拿到文件先别急着整体读取先抽样看头部和末尾的几行原始字节确认编码、分隔符、换行符再批量读取。这一步花不了 30 秒却能避开绝大多数 CSV 异常。6. 异常定位与监控建立自己的排查工具箱6.1 日志里该记什么比怎么记更重要很多人的脚本不是没有日志而是日志形同虚设。原因很简单等异常真正出现时日志里只有一句报错信息完全没有上下文根本无从排查。我调试提取任务时日志至少要包含这些字段当前处理的资源标识URL 或文件名、请求开始时间、结束时间、耗时、状态码、异常类型、重试次数、关键响应片段。[timestamp] [level] [task_id] url... status403 time_ms235 retry1 resp_snippethtml... errorForbiddentask_id 非常关键尤其是并发场景。没有任务标识多个任务同时跑的时候你根本分不清日志对应的是哪一条数据。加一个唯一标识符就能把异常日志和具体任务关联起来。6.2 固定现场响应快照和元数据排查异常时最怕的就是“现场被破坏”。比如服务端返回了一个非预期的 JSON你的脚本尝试解析失败后直接把响应内容丢掉只留下一个解析异常。等你想研究它为什么解析失败时原始数据已经没了。我的建议是为每次请求保留一份“现场快照”。不用存整个响应体那太占空间可以只保存响应头和响应体的前几百字节。这些内容通常足够你定位问题。如果异常类型和解析相关再把完整响应体落盘保存。现场保留得越多后面定位的路径就越短。有些服务端返回的错误信息非常隐蔽比如通过响应头返回一个 token 过期时间而你只看响应体就漏掉了关键信息。所以保存快照时响应头一定不能省。6.3 一套“六问排查法”解决大多数定位难题当提取异常出现时别急着网上搜报错信息先回答下面六个问题这个异常是今天刚出现还是一直存在是不是固定某一个或某一批资源才触发目标页面或接口的返回内容最近有没有变化换一个网络环境或运行环境还能复现吗同样的输入数据换一个解析方式结果会不同吗数据量小的时候正常数据量大的时候才异常吗这套问题看着简单但基本能筛掉一半以上“假异常”。比如问题 2 能帮你快速区分是数据本身的问题还是代码逻辑问题问题 4 能帮你确认是不是请求策略触发了限制问题 6 则能暴露并发、连接池这类只在压力下才出现的隐患。我遇到过最典型的场景是某几条数据一处理就报编码错误其他数据完全正常。用这六个问题排查一遍锁定原因在输入数据本身而不是代码逻辑。解决方案就变成了对输入做一层内容校验而不是去改通用的解析逻辑。6.4 异常分级的兜底策略最后聊一聊异常处理的整体策略。我把异常分成了三个等级可重试、可跳过、须停止。可重试的异常包括连接超时、服务端 5xx、由于网络抖动导致的数据读取失败。这类异常不代表逻辑有问题给它几次重试机会是合理的。可跳过的异常包括某一条数据字段缺失、部分页面解析不到目标内容、个别文件格式异常。这种异常如果阻断整个任务会直接浪费整批数据跳过并记录即可。须停止的异常包括请求凭证失效、账户被限制、数据库连接失败、代码逻辑错误。这种异常往往意味着整个任务继续跑下去毫无意义甚至可能造成更大的数据污染应该立即停止并通知负责人。这套分级策略稳定运行了很多次核心是一个判断原则这个异常继续重试或跳过是否会让整体结果更差如果不会就重试或跳过如果会就立刻停下来。个人经验里提取任务的异常不是一个一个独立解决的它们经常成群出现。刚解决完连接超时又冒出来编码问题刚把编码搞定又发现数据落库主键冲突。但只要你养成分层思考、保留现场、规范记录的习惯这些坑都会变成你工具箱里的一部分。每次解决一个异常其实就是在给下一个异常铺路。
把一条 URL 或者一个文件丢进程序等它吐出一张干净规整的表格——这基本就是“提取”这件事的全部目标。但真正做过数据提取的人心里都清楚让人头疼的很少是提取逻辑本身而是过程里冒出来的“常见异常”。编码乱码、页面结构调整、接口突然 403、超时重试把任务拖成马拉松……这些异常本身不可怕可怕的是你不知道它为什么发生只能一遍一遍重跑甚至把脚本改成自己都看不懂的补丁。这篇文章不围绕某个特定框架展开而是把我在实际提取任务里遇到的高频异常按链路拆开讲请求、解析、清洗、存储、文件解析、监控。每一类都会说明它是什么、为什么会发生、怎么快速定位并给出可以直接照抄的排查套路。如果你正准备做数据采集、报表抽取或者正被某个百思不得其解的 Bug 困住这篇文章能省下你不少试错时间。1. 提取任务中的异常为什么如此顽固1.1 一条提取链路里藏着三层风险很多人遇到异常就急着改代码结果往往按下葫芦浮起瓢。根本原因在于提取任务从来不是“一步到位”的操作它是一条完整链路先发请求拿数据再做结构解析然后做字段清洗最后落库。每一层都有自己专属的异常家族而它们表现出的症状可能完全一样。举个例子一个爬虫抓取商品列表页页面上明明有 20 条商品数据但程序只提取到了 5 条。这可能不是选择器写错了而是页面用了懒加载后 15 条数据是滚动后才动态加载的。看起来是“解析层的异常”本质却是“渲染层”的问题。再比如你从某个接口拿到 JSON解析时报错表面看是 JSON 格式问题实际可能是服务端返回了压缩编码或响应头里根本没有声明字符集。所以我的第一建议永远是遇到异常先给异常分层。判断这个问题发生在“网络请求”“内容解析”“语义清洗”还是“数据存储”哪个阶段再决定从哪一层下手排查。这样可以避免你在错误的方向上反复折腾。1.2 先给异常分个类再动手修我习惯把提取任务中的异常分成五个大类连接层异常、解析层异常、语义层异常、存储层异常、环境依赖层异常。下面这张表是我在实际项目中总结出来的异常现象和排查方向基本都能对上号。异常类型典型现象可能原因优先排查方向连接层超时、连接重置、403/429限流、防火墙、代理失效、连接池复用请求频率、退避策略、响应码解析层选择器抓不到、JSON 解析失败、乱码页面结构变化、动态渲染、编码判断错误原始响应快照、渲染方式、字符集语义层字段缺失、类型转换失败、日期错乱数据格式不统一、空值处理不当数据样本统计、清洗模板存储层主键冲突、写入失败、乱码入库字符集设置、唯一约束、类型不匹配表结构、数据库字符集环境依赖本地正常、服务器报错依赖版本不一致、缺少底层库、时区差异运行环境对比、依赖锁文件这个分类不是学术定义而是为了快速定位。你不需要背下所有异常类型只需要在出现问题的时候能判断出它更贴近哪一层。定位到层之后再往下看具体原因就容易多了。2. 网络请求层的异常超时、限流与连接重置2.1 超时不是时间不够是链路里某个环节掉链子只要做提取任务就一定遇到过超时。但超时它分两种一种是 TCP 连接建立的超时叫 connect timeout另一种是连接建立后等待对方返回数据的超时叫 read timeout。很多人不理解这两者的区别我打个比方connect timeout 相当于你打电话拨号对方一直不接read timeout 相当于电话已经接通了但对方就是不说话。排查思路完全不一样。前者大概率是目标服务器不可达、DNS 解析失败、端口被墙后者往往是目标服务处理慢、请求参数不对导致服务端卡死或者你的并发太高把对方压垮了。在一个采集脚本里我通常这样设置超时连接超时 5 秒读取超时 10 秒。如果页面数据量特别大读取超时适当放宽到 20 秒。这里有一个原则超时时间别设太长更别全局统一。因为一旦某个 URL 卡住默认超时时间太长会让整个任务卡死很久甚至拖垮整个任务队列。最好在每个请求级别独立设置超时而不是依赖请求库的全局配置。import requests resp requests.get( url, timeout(5, 10) # 连接超时5秒读取超时10秒 )你可能会问超时之后再重试一次不就完了吗关键问题是重试也要讲究策略。如果服务器已经压力很大你立刻用相同参数再打一次只会加重对方负担自己也大概率继续超时。比较好的做法是退避重试后文会专门聊。2.2 连接重置与长连接陷阱如果说超时还有规律可循连接重置Connection Reset就是最让人摸不着头脑的一种。它典型的报错是“Connection reset by peer”或者“远程主机强迫关闭了一个现有的连接”。我排查过很多次这类问题最终发现大多数都指向同一个地方短时间大量请求触发了服务器的安全策略。服务端为了防爬会对异常流量直接断连。解决办法是从自身降低请求密度而不是想办法“伪装”成正常流量。不过还有一个容易被忽略的原因HTTP 连接复用。某些请求库默认会启用连接池复用一个 TCP 连接去发送多个请求。如果服务端已经关闭了这个连接而客户端不知道还继续拿这个“已死”的连接发请求就会触发连接重置。这种情况下最简单的验证方法是把连接池关掉或者每个请求重新建一个会话看问题是否消失。如果问题消失那就说明是长连接复用导致的。更稳妥的做法是为每个目标域名设计独立的连接策略。高并发采集时使用带连接池的 Session 能明显提升性能但要设置 max_connections 和 max_keepalive 参数避免连接无限堆积。另外要监控连接池的存活状态定期清理陈旧连接。2.3 响应码 403、429 背后的限流与鉴权提取任务里最“显眼”的异常是突然间全部请求都返回 403 Forbidden 或 429 Too Many Requests。403 通常是没有权限可能是少了某个请求头、Cookie 失效、Token 过期而 429 就是单纯告诉你你请求得太快了。先说 403。很多时候你本地用浏览器访问页面一切正常但脚本一请求就返回 403。这通常是因为服务端通过请求头特征识别的。浏览器会自动带上很多请求头而代码里的请求头往往很薄。最简单的排查方法是把浏览器开发者工具里看到的完整请求头复制过来替换掉脚本里的请求头再试一次。别只复制 User-Agent很多服务端也会校验 Referer、Origin、Accept-Language 等字段。再说 429。处理 429 的核心思路不是继续硬闯而是降低请求频率。我在写采集脚本时会给每个目标设置一个最小请求间隔。比如 1 秒一次如果发现返回 429就把间隔动态拉长到 2 秒、4 秒、8 秒呈指数级退避。import time import random delay 1 for attempt in range(5): resp fetch(url) if resp.status_code 429: sleep_time delay * (2 ** attempt) random.uniform(0, 1) time.sleep(sleep_time) continue break这里加入随机抖动Random Jitter非常关键。如果所有请求都在固定间隔 1 秒后重试那大量并发任务会形成固定节奏的请求波依然很容易被识别。加一个 0 到 1 秒的随机值会让请求节奏更接近真实访问。当然做任何提取任务都要遵守目标平台的访问规则尊重 robots 协议不对目标服务器造成明显压力。这是底线。2.4 重试逻辑应该怎么写才不算瞎重试大部分提取脚本都有重试逻辑但很多人的写法是“失败就重试重试还失败就再重试”。这种方式不仅浪费资源还会把偶发问题变成持续问题。我自己的重试策略遵循三个原则能重试的才重试、重试次数有限、退避要递增。什么样的异常可以重试连接超时、5xx 状态码、连接重置这类问题可以重试。而 403、401 这类鉴权异常重试多少次都一样不值得重试。参数错误、JSON 解析失败属于代码本身的问题也不该靠重试解决。连接层异常重试 3 次指数退避间隔从 1 秒开始5xx 状态码重试 2 次间隔从 2 秒开始429 状态码重试 5 次退避间隔按响应头 Retry-After 优先其次指数退避鉴权失败、参数错误不重试直接记录日志重试逻辑之外还必须设置一个“最大重试次数”的硬性上限。否则某个 URL 持续失败你的任务会在它身上无限消耗时间。我见过最夸张的一次是因为某个 URL 永远超时整个任务队列被它堵死后面的数据一条都没跑。后来我加了一个熔断机制同一 URL 连续失败超过 5 次就把它移入失败队列不再自动重试。3. 数据解析层的异常页面结构、动态内容与编码乱码3.1 选择器失效页面改版和动态渲染的两种玩法做网页提取选择器失效是最常见的解析异常。今天脚本还跑得好好的第二天突然抓不到数据了。很多人第一反应是“页面改版了”但实际上还有另一个隐蔽原因动态渲染。页面改版的情况好理解CSS 类名变了、DOM 结构调整了原来的选择器自然就失效了。这种问题的排查思路很简单把页面源码拉下来对比实际 DOM 结构和选择器找出差异。关键是别只看浏览器里看到的页面效果因为浏览器显示的可能是 JS 运行后的最终效果而脚本拿到的可能是原始 HTML。一定要对比脚本真正拿到的 HTML。动态渲染则是另一个世界。如果页面数据是 JavaScript 异步加载的脚本直接抓取到的 HTML 里压根没有目标数据。常见的动态渲染手段有三种Ajax 异步请求、懒加载、iframe 嵌入。Ajax 场景下你可以直接找数据接口省去解析 HTML 的麻烦懒加载场景下数据往往在某个滚动事件后才会请求你需要模拟滚动或用无头浏览器iframe 场景最坑数据在子页面里必须定位到 iframe 的 src 再发一次请求。我建议在解析层做一层“抽象”不要把所有选择器写死在业务逻辑里。定义一个配置化的字段映射表把每个字段的 CSS/XPath 选择器都放在配置里。这样页面结构变了改配置就能恢复不用重新发版。多花这点时间后面能省很多事。3.2 编码异常乱码的源头其实只有两种乱码是提取任务里存在感最强的异常没有之一。但只要弄明白编码错误是怎么产生的这个问题就一点不神秘。乱码的源头基本只有两类第一类是服务器返回的字节流编码和解析时使用的编码不一致第二类是服务器响应头里声明的字符集和实际内容不一致。第一类情况很好理解你用 UTF-8 解码 GBK 编码的数据得到的必然是一堆乱码。问题在于怎么识别实际编码。我的做法是优先查看响应头里的 Content-Type 字段比如Content-Type: text/html; charsetgbk这通常是最可靠的信息源。如果响应头没有声明编码再根据网页内容里meta charsetgbk去判断。如果两个都没有就只能靠启发式检测了。import requests import chardet resp requests.get(url) encoding resp.encoding or utf-8 # 如果响应头未声明 charset用 chardet 推断 if resp.encoding is None or resp.encoding ISO-8859-1: encoding chardet.detect(resp.content)[encoding] resp.encoding encoding text resp.text这里有一个很多人踩过的坑某些服务端在响应头里没声明编码时请求库会默认把编码识别为 ISO-8859-1进而导致解码错误。当你看到“锟斤拷”这种奇异字符时基本都是把 UTF-8 字节流按 GBK 或 Latin-1 解码导致的。排查时不要凭肉眼猜直接用工具检测原始字节流一次就能锁定。第二类情况更隐蔽。响应头声明了 charsetutf-8但页面实际内容是 GBK 编码这时即使你完全按响应头来解码依然会乱码。这种一般是服务端配置出错了需要以实际内容为准用前面提到的检测逻辑覆盖响应头的声明。3.3 JSON/XML 解析失败的真面目解析 JSON 和数据提取紧密相关尤其当目标数据是通过接口返回的时候。JSON 解析失败的报错信息往往很直接比如Expecting value、Expecting property name enclosed in double quotes。这些报错看着吓人原因归类后也就那么几种。非法字符是最常见的原因。比如返回内容里带了 UTF-8 BOM 头某些解析器就会直接报错。解决办法是先对文本做一次 BOM 清理再解析。其次是单引号替代双引号或者在字符串里出现了未转义的控制字符这些都会让标准 JSON 解析器崩溃。处理办法是在解析之前先对原始文本做一个预处理把常见的非法字符替换掉。看一个很典型的例子接口返回如下{name: 张三, age: 18}这本身不是合法的 JSON因为键和字符串都用了单引号。用 Python 的 json 模块解析会直接报错。但它的“来源”往往是某个框架的错误输出或日志文件。你可以先用正则或字符串替换把单引号换成双引号再尝试解析。如果出现嵌套引号替换逻辑就得写得更严谨或者直接放弃用 JSON 解析改用其他更宽容的解析方案。XML 解析失败的排查思路类似但多了两个坑命名空间和实体字符。命名空间会让 XPath 失效实体字符不处理好会被解析器视为非法。遇到 XML 解析问题时我习惯先确认根元素和命名空间声明再写路径表达式。4. 字段清洗与落库阶段的隐性异常4.1 None、空字符串、缺字段处理逻辑完全不同提取数据并不止于“拿到字段”还要把字段整理成能用的形态。这个阶段最常见的异常是代码在处理缺失值时直接报AttributeError或者KeyError。但更让人头疼的是数据“没有内容”的多种表现方式。同样是缺失有的字段是None有的是空字符串有的是字段键完全不存在有的则是一个 NoneType 字符串 null。如果你不加区分地统一处理就会把有值的数据误判为空或者把空数据当成合法值写入。我自己的处理原则是None表示未知需要根据业务决定是丢弃还是填默认值空字符串表示无内容通常可以直接替换为 0 或者空字段键不存在则意味着数据结构本身有问题需要检查解析层。定义一个统一的清洗入口而不是在业务代码里到处判断会让这类异常的排查容易得多。def clean_value(value, default): if value is None: return default if isinstance(value, str) and value.strip() in (, null, NaN): return default return value这样写的好处是所有字段统一走清洗函数后面出问题只需要维护这一处入口不需要去翻几十个业务字段的手工逻辑。4.2 类型转换和日期格式异常为何高发提取任务里类型转换异常的高发程度绝对排前三。它们的共同特征是数据样本规模小的时候看起来一切正常一跑全量任务就崩。最典型的例子是字符串转数字。表面上你提取到的是 1234看似能顺利转成 int。但真实数据里混着 1,234、1234.0、1234元、等 1234 元左右这种五花八门的格式。一旦碰上你的转换逻辑就会崩。处理思路是先做标准化移除货币符号、千分位逗号、中文单位再根据实际格式选择转换方式。日期格式更是重灾区。同一个字段里可能出现 2024-01-05、2024/1/5、2024年1月5日、Jan 5, 2024、时间戳甚至 Excel 序列号日期。每次遇到一种新格式就加一个分支代码会越来越臃肿。我建议用一个日期解析工具库统一处理并且在实际项目里先跑一遍样本数据统计日期格式的分布再决定处理策略。不是每个日期都需要精确解析有些场景下只需要提取年份就够了。4.3 存储异常不只在数据库还可能在字符集数据清洗完成后的落库阶段同样会冒出一堆异常。最经典的是主键或唯一约束冲突重复抓取时同一主键的数据第二次写入会直接报错。处理方案通常是“存在则更新不存在则插入”也就是 UPSERT 语义。不同数据库的写法不同但思路一致。还有一类很容易被忽视的异常是字符集。数据库表、连接字符串、字段本身的字符集如果和提取到的数据编码不一致就会出现数据能写入、但查出来是乱码的情况。注意这和前面讲到的响应解码乱码不是一回事。有时你的代码里看到的数据完全正常写入数据库后却变乱这基本就是数据库连接层字符集设置的锅。浮点精度问题也值得提一嘴。在提取金额、交易数据时别直接用浮点类型存储否则会出现 0.1 0.2 不等于 0.3 的精度损失。金额类字段建议用整数类型的分或者使用高精度数值类型来存。写存储逻辑前最好先检查一遍目标表的字段类型、字符集、约束规则。这些信息在运行时报错前就能看出来省得最后被一个主键冲突搞得满头大汗。5. 文件型提取的专项异常PDF、Excel、CSV5.1 PDF 提取扫描件不是文本是图片除了网页和接口文件型提取也是日常工作里绕不开的部分尤其是 PDF。PDF 提取的异常很有特点因为它表面上是一个文件里面却可能藏着两种完全不同的形式。文本型 PDF 提取相对简单直接用解析库就能拿到文字。但扫描版 PDF 就完全是另一回事了——页面上的每个字本质上都是图片里的像素解析库拿不到任何文字。如果硬用文本解析得到的要么是空字符串要么是一堆没有意义的符号。解决办法是引入 OCR 能力把页面渲染成图片再识别文字。实际操作中PDF 表格提取比纯文本提取更痛苦。哪怕文件本身是文本型的表格线、单元格合并、跨页断行都会把提取结果切割得七零八落。最常见的问题是同一表格单元格里的文本被解析成了多行导致多列数据错位。我的建议是优先使用支持表格结构解析的专用库如果解析结果依然不理想就把 PDF 页面转成图片走 OCR 表格识别虽然速度慢但准确率往往更高。5.2 Excel 提取合并单元格和类型混搭Excel 提取相对友好但也不是没有坑。最大的坑是合并单元格。如果一个单元格跨行合并那么合并区域里只有左上角那个单元格有值其他单元格读出来是空的。这在提取“每行一条记录”的场景里会导致大量空值。解决办法是读取时检测合并单元格信息把左上角的值填充到整个合并区域。这一步必须在数据解析阶段做不能留到清洗阶段。因为合并单元格是按坐标记录的清洗阶段拿到的数据已经丢掉了坐标信息没法再还原。Excel 里的数据类型混搭也很麻烦。有时候一列数字里混着几个文本格式的单元格或者日期列里既有日期对象又有字符串。用 pandas 读取的时候它可能会自动把整列推断成字符串导致后续计算处理异常。我建议读取 Excel 时显式指定列类型不要把类型推断完全交给工具。5.3 CSV 提取分隔符和 BOM 的战争CSV 看起来最“简单”但它在大规模数据提取场景下反而是异常率最高的文件格式之一。第一个坑是分隔符。很多 CSV 根本不是用逗号分隔的有制表符分隔的 TSV有分号分隔的欧洲格式。用默认分隔符读取整个表格会变成一列或者字段错位。判断方法很简单打开原始文件的头部几行统计每一行里不同分隔符出现的次数取最一致的。第二个坑是 BOM。用记事本或者某些工具保存的 UTF-8 CSV 会带 BOM 头即文件开头有三个不可见字节。读取后第一个字段名会变成\ufeff字段名看起来没毛病但字段匹配永远失败。处理方式是一开始读取文件时就指定正确的编码或者读取后显式去除 BOM。第三个坑是换行符。字段内部如果包含换行符而 CSV 又没有正确处理引号读取时会莫名其妙地多出几行。这也是 CSV 提取异常里最隐蔽的一种。处理 CSV 的一个实用习惯是拿到文件先别急着整体读取先抽样看头部和末尾的几行原始字节确认编码、分隔符、换行符再批量读取。这一步花不了 30 秒却能避开绝大多数 CSV 异常。6. 异常定位与监控建立自己的排查工具箱6.1 日志里该记什么比怎么记更重要很多人的脚本不是没有日志而是日志形同虚设。原因很简单等异常真正出现时日志里只有一句报错信息完全没有上下文根本无从排查。我调试提取任务时日志至少要包含这些字段当前处理的资源标识URL 或文件名、请求开始时间、结束时间、耗时、状态码、异常类型、重试次数、关键响应片段。[timestamp] [level] [task_id] url... status403 time_ms235 retry1 resp_snippethtml... errorForbiddentask_id 非常关键尤其是并发场景。没有任务标识多个任务同时跑的时候你根本分不清日志对应的是哪一条数据。加一个唯一标识符就能把异常日志和具体任务关联起来。6.2 固定现场响应快照和元数据排查异常时最怕的就是“现场被破坏”。比如服务端返回了一个非预期的 JSON你的脚本尝试解析失败后直接把响应内容丢掉只留下一个解析异常。等你想研究它为什么解析失败时原始数据已经没了。我的建议是为每次请求保留一份“现场快照”。不用存整个响应体那太占空间可以只保存响应头和响应体的前几百字节。这些内容通常足够你定位问题。如果异常类型和解析相关再把完整响应体落盘保存。现场保留得越多后面定位的路径就越短。有些服务端返回的错误信息非常隐蔽比如通过响应头返回一个 token 过期时间而你只看响应体就漏掉了关键信息。所以保存快照时响应头一定不能省。6.3 一套“六问排查法”解决大多数定位难题当提取异常出现时别急着网上搜报错信息先回答下面六个问题这个异常是今天刚出现还是一直存在是不是固定某一个或某一批资源才触发目标页面或接口的返回内容最近有没有变化换一个网络环境或运行环境还能复现吗同样的输入数据换一个解析方式结果会不同吗数据量小的时候正常数据量大的时候才异常吗这套问题看着简单但基本能筛掉一半以上“假异常”。比如问题 2 能帮你快速区分是数据本身的问题还是代码逻辑问题问题 4 能帮你确认是不是请求策略触发了限制问题 6 则能暴露并发、连接池这类只在压力下才出现的隐患。我遇到过最典型的场景是某几条数据一处理就报编码错误其他数据完全正常。用这六个问题排查一遍锁定原因在输入数据本身而不是代码逻辑。解决方案就变成了对输入做一层内容校验而不是去改通用的解析逻辑。6.4 异常分级的兜底策略最后聊一聊异常处理的整体策略。我把异常分成了三个等级可重试、可跳过、须停止。可重试的异常包括连接超时、服务端 5xx、由于网络抖动导致的数据读取失败。这类异常不代表逻辑有问题给它几次重试机会是合理的。可跳过的异常包括某一条数据字段缺失、部分页面解析不到目标内容、个别文件格式异常。这种异常如果阻断整个任务会直接浪费整批数据跳过并记录即可。须停止的异常包括请求凭证失效、账户被限制、数据库连接失败、代码逻辑错误。这种异常往往意味着整个任务继续跑下去毫无意义甚至可能造成更大的数据污染应该立即停止并通知负责人。这套分级策略稳定运行了很多次核心是一个判断原则这个异常继续重试或跳过是否会让整体结果更差如果不会就重试或跳过如果会就立刻停下来。个人经验里提取任务的异常不是一个一个独立解决的它们经常成群出现。刚解决完连接超时又冒出来编码问题刚把编码搞定又发现数据落库主键冲突。但只要你养成分层思考、保留现场、规范记录的习惯这些坑都会变成你工具箱里的一部分。每次解决一个异常其实就是在给下一个异常铺路。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
