简介这份面向具备一定编程基础的学习者与开发者的Python爬虫技术文档围绕网络数据采集的完整流程展开帮助读者理解爬虫的基本概念、运行原理与工程规范并逐步掌握从网页请求到数据落地的实现方法。内容以发送请求、解析网页、数据存储三大核心环节为主线结合requests、BeautifulSoup、lxml与Scrapy等常用库的特点和应用场景延伸到动态加载处理、反爬机制应对、采集效率提升等进阶技巧同时强调网站协议、法律法规与用户隐私保护。资源包内含1个docx文档压缩后约16KB体量轻便适合作为随查随用的学习笔记或项目入门参考。目前已有629人学习读者可从中获得较清晰的知识框架、库选型思路与合规采集意识并可将示例思路迁移到批量公开数据获取、信息监测或小型数据挖掘项目中。1. 从四十个链接说起这套 Python 爬虫资料到底解决什么问题上个月一个做运营的朋友甩给我四十多个链接说“你帮我复制到表格里就行”。复制到第七条我就放弃了这种事本来就该交给 Python 爬虫。麻烦的地方在于多数打着“从基础到实战”旗号的教程讲到 requests.get 就收尾了读者手里只剩一行 print不知道一页 HTML 怎么变成一张能交付的表。这套资料把网络数据采集拆成三段——发送 HTTP 请求、解析网页、数据处理与落盘再往上叠动态渲染、并发和 Scrapy 工程化最后收在 robots.txt 与隐私边界上。它适合已经能写 Python 函数、想第一次把采集流程完整跑通的人纯新手也能看但至少要熟悉字典、列表推导和异常处理否则中间那几段解析代码会看得吃力。2. 技术栈分工requests、BeautifulSoup、lxml、Scrapy 各站哪一班岗2.1 一条采集链路的三个断面与各自的失败姿势把爬虫当成一个流水线看它只有三个断面请求层负责把 URL 变成一段 HTML 文本解析层负责把文本变成结构化字段存储层负责把字段变成文件或表。听着简单实际翻车的位置高度集中在三个断面各自的边界上而且失败信号完全不一样。请求层的典型症状是状态码异常403 表示对方不认你的身份429 表示你打得太快连接超时或 reset 往往是网络环境或者对方限流网关在拦。解析层的症状更阴——请求返回 200正文也有几十 KB但选择器一个都没命中这时候八成是页面结构和你想象的不一致或者内容压根是 JS 渲染出来的。存储层的症状最容易被忽略字段串位、中文变问号、长数字被 Excel 转成科学计数法数据看着有实际上已经不能用了。理解这三个断面选型就不再是“哪个库火用哪个”而是“这一层我需要什么能力”。原文列出的 requests、BeautifulSoup、lxml、Scrapy 四个库正好可以按断面归位库所在断面主要职责什么时候别用requests请求发 GET/POST、带请求头、维护会话需要浏览器执行 JS 时BeautifulSoup解析容错解析脏 HTML按标签/属性定位千万级节点、追求极致速度时lxml解析XPath 精确取数C 底层速度快HTML 结构极度残缺、需要强容错时Scrapy全链路调度、去重、并发、管道一条龙只想抓几十页的一次性脚本这张表是后面所有代码的前提。写脚本之前先问自己一句这次是几十页还是几万页几十页requests 加 BeautifulSoup 二十分钟收工几万页并且要长期跑硬写线程池最后会变成维护噩梦该上 Scrapy。2.2 BeautifulSoup 与 lxml同一份 HTML 的两种取法这两个库经常被放在一起比较其实它们解决的是不同层面的问题。BeautifulSoup 的核心价值是容错真实网页里闭合标签缺失、属性没引号是常态它能把这种残缺文档修成树再交给你lxml 的核心价值是快和精确底层是 C 实现的 libxml2XPath 表达能力比 CSS 选择器强一截。先看 BeautifulSoup 的写法from bs4 import BeautifulSoup def parse_with_bs4(html: str): # 第二个参数指定解析后端lxml 比默认的 html.parser 快不少 soup BeautifulSoup(html, lxml) # select 走 CSS 选择器select_one 只取第一个命中的 cards soup.select(div.item) rows [] for card in cards: title_node card.select_one(h3.title) link_node card.select_one(a.detail) rows.append({ # get_text(stripTrue) 会丢掉标签内多余的空白和换行 title: title_node.get_text(stripTrue) if title_node else None, href: link_node.get(href) if link_node else None, }) return rows再看同一份 HTML 的 XPath 写法from lxml import etree def parse_with_lxml(html: str): tree etree.HTML(html) # 容错地把字符串解析成树 titles tree.xpath(//div[classitem]/h3[classtitle]/text()) hrefs tree.xpath(//div[classitem]/a[classdetail]/href) # XPath 返回的是列表长度可能不一致用 zip 合并前先确认元素个数 return [ {title: t.strip(), href: h} for t, h in zip(titles, hrefs) if t.strip() ]两段代码的差别不只是语法。BeautifulSoup 按卡片循环天然保证 title 和 href 属于同一张卡片lxml 那版分别取两个列表再 zip一旦某个卡片缺了标题两个列表就错位了——这是我在真实项目里踩过的坑数据量小的时候根本看不出来跑到几千条才发现后半段标题全串了。所以用 XPath 时更稳的写法是定位到父节点再逐个取子节点def parse_with_lxml_safe(html: str): tree etree.HTML(html) rows [] # 先取父节点保持卡片内的字段绑定关系 for card in tree.xpath(//div[classitem]): title card.xpath(./h3[classtitle]/text()) href card.xpath(./a[classdetail]/href) rows.append({ title: title[0].strip() if title else None, href: href[0] if href else None, }) return rows参数上要留意的几处etree.HTML的入参必须是 str如果 requests 返回的是 bytes 且你知道编码用etree.HTML(resp.content)让它自己嗅探反而更省事xpath(./...)开头的点表示相对当前节点漏掉就是从根找起结果会重复出所有卡片的字段。BeautifulSoup 的parser参数选lxml时依赖本机装了 lxml没装会直接抛异常选html.parser则零依赖但慢。性能上十万级节点的页面lxml 通常比 BeautifulSoup 快三到五倍。但也别因此一律上 lxml——结构脏到 lxml 解析出一棵空树的时候BeautifulSoup 往往还能救回来。常见做法是先用 lxml解析结果为空再回退到 BeautifulSoup两个都不行才说明页面是 JS 渲染的。2.3 Scrapy 该不该上并发模型与项目边界Scrapy 不是“更高级的 requests”它是另一种组织方式。原文给的示例很短实际工程里它的价值体现在调度层内置的请求队列、去重指纹、按域名限速、失败重试、以及 Item Pipeline 这套数据处理钩子。import scrapy class ListSpider(scrapy.Spider): name list custom_settings { # 每个请求之间至少间隔 0.8 秒给对端留口气 DOWNLOAD_DELAY: 0.8, # 同一个域名下最多 4 个请求并发别把并发数开到天上去 CONCURRENT_REQUESTS_PER_DOMAIN: 4, # 自动限速根据响应延迟动态调节节奏 AUTOTHROTTLE_ENABLED: True, # 结果直接落成 jsonl一行一条断了也不会全丢 FEEDS: {items.jsonl: {format: jsonlines, encoding: utf8}}, } def start_requests(self): # 分页入口Scrapy 会自动排队 for page in range(1, 6): yield scrapy.Request( fhttps://www.example.com/list?page{page}, callbackself.parse, errbackself.on_error, ) def parse(self, response): for card in response.css(div.item): yield { title: card.css(h3.title::text).get(default).strip(), # urljoin 处理相对路径别自己拼字符串 url: response.urljoin(card.css(a.detail::attr(href)).get()), } def on_error(self, failure): # 单页失败不影响整轮记下来回头补 self.logger.warning(抓取失败: %s, failure.request.url)几个参数值得说清楚。DOWNLOAD_DELAY是全局下限CONCURRENT_REQUESTS_PER_DOMAIN控制同域并发这两个一起决定了对方服务器的感受AUTOTHROTTLE_ENABLED打开后 Scrapy 会盯着响应时间自动调整比手写 sleep 明智。parse里的yield出去的字典会进 Pipeline清洗、去重、写库都能在那儿做业务代码和调度代码就此分开。反过来说如果你只是想抓几十个页面导出个 Excel引入 Scrapy 就是给自己找麻烦要建工程、写 settings、理解 Twisted 的异步模型收益为零。判断标准很朴素——需要断点续跑、需要分布式、需要长期定时执行才考虑 Scrapy一次性小任务requests 加个 for 循环就是最优解。3. 跑通第一条链路从一次 GET 到一张能打开的 CSV3.1 环境与最小目录结构先把依赖装齐。requests 和 beautifulsoup4 是必装lxml 和 pandas 看需求selenium 等到要抓动态页再说python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate pip install requests beautifulsoup4 lxml pandas目录别一上来就摊一堆文件三个模块加一个入口足够crawler/ ├── fetch.py # 请求层Session、重试、超时 ├── parse.py # 解析层CSS / XPath 两种取法 ├── store.py # 存储层清洗 落盘 └── main.py # 串流程这个拆分的好处是等需求从“抓一个站”变成“抓五个站”你只需要在 parse.py 里加选择器请求和存储逻辑一行不用改。3.2 请求层把 Session、超时、重试封成一个函数裸写requests.get(url)在真实站点上撑不过十分钟。下面这版是我一般会用的最小封装# fetch.py import time import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry DEFAULT_UA ( Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36 ) def build_session(retries: int 3, backoff: float 1.5) - requests.Session: 构造带重试策略和连接复用的 Session session requests.Session() retry Retry( totalretries, # 总重试次数 backoff_factorbackoff, # 第 n 次重试等待 backoff * 2^n 秒 status_forcelist[429, 500, 502, 503, 504], # 只对这些状态码重试 allowed_methods[GET], # 别对 POST 盲目重试会重复提交 ) # 连接池大小要和并发数匹配太小会频繁建连 adapter HTTPAdapter(max_retriesretry, pool_connections20, pool_maxsize20) session.mount(https://, adapter) session.mount(http://, adapter) session.headers.update({ User-Agent: DEFAULT_UA, Accept-Language: zh-CN,zh;q0.9, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, }) return session def fetch(session: requests.Session, url: str, timeout(5, 15), sleep: float 1.0) - str: 返回 HTML 文本失败直接抛异常由调用方决定怎么处理 resp session.get(url, timeouttimeout) # 4xx / 5xx 立刻抛别让错误页混进解析层 resp.raise_for_status() # 让响应自己报编码报错了再手动指定 if not resp.encoding or resp.encoding.lower() iso-8859-1: resp.encoding resp.apparent_encoding text resp.text if sleep: time.sleep(sleep) return text参数里最值得琢磨的是timeout(5, 15)这是个二元组前者是建立连接的超时后者是等待首字节的超时。只写一个数字时两者相同抓慢接口很容易在读取阶段被掐断。status_forcelist不去加 403因为 403 是身份问题重试一百次也还是 403反而是 429 和 5xx 值得重试。raise_for_status()这行看着不起眼但它是一条分界线请求层只负责告诉你这次拿到的到底是不是有效内容判断逻辑留给上层。我见过不少脚本把所有异常都 try 住然后继续跑最后导出的表里混进一堆登录页 HTML排查半天才发现是三次重试全失败了。至于编码那段判断是因为有一批老站点在响应头里写死ISO-8859-1却实际输出 UTF-8不纠正就会有整页中文变乱码——这个在第 5 章还会展开。3.3 解析层一套字段两条取数路径把第 2 章的两段解析函数合到一个文件里做成同一个签名方便按站点切换# parse.py from bs4 import BeautifulSoup from lxml import etree def parse_css(html: str) - list[dict]: soup BeautifulSoup(html, lxml) rows [] for card in soup.select(div.item): title card.select_one(h3.title) link card.select_one(a.detail) rows.append({ title: title.get_text(stripTrue) if title else , href: link.get(href, ) if link else , }) return rows def parse_xpath(html: str) - list[dict]: tree etree.HTML(html) if tree is None: # 解析彻底失败时 lxml 会返回 None return [] rows [] for card in tree.xpath(//div[classitem]): title card.xpath(./h3[classtitle]/text()) href card.xpath(./a[classdetail]/href) rows.append({ title: title[0].strip() if title else , href: href[0] if href else , }) return rows两个函数都做了空值兜底返回的字段名保持一致。这一点在二次开发时特别省事——换站点只需要换选择器下游完全无感。选择器怎么定我的习惯是先在浏览器开发者工具里右键“复制 selector”粘到代码里跑一次命中了再精简。类名里带哈希的那种形如item-3f8a2千万别直接抄那是构建工具生成的隔天就变得往上找稳定的父级结构比如div.list div这种位置型选择器。tree is None那个判断也别省lxml 在极端情况下比如拿到的是空字符串会返回 None不判的话下一行 xpath 直接 AttributeError。3.4 存储层pandas 落盘与字段清洗解析出来的字典列表直接扔给 DataFrame再做一轮清洗最后按格式落盘# store.py import pandas as pd def save(rows: list[dict], path: str items.csv) - pd.DataFrame: df pd.DataFrame(rows) if df.empty: return df # 统一去掉首尾空白、把连续空白压成一个空格 for col in (title, href): if col in df.columns: df[col] df[col].astype(string).str.replace(r\s, , regexTrue).str.strip() # 相对链接补成绝对链接后面二次访问用得上 df.drop_duplicates(subset[href], inplaceTrue) df.reset_index(dropTrue, inplaceTrue) # utf-8-sig 让 Excel 双击打开不乱码 df.to_csv(path, indexFalse, encodingutf-8-sig) return dfutf-8-sig是血泪经验普通 utf-8 编码的 CSV 用 Excel 打开中文百分百变问号加个 BOM 头就正常了。代价是某些程序读这个文件时表头会多一个不可见字符所以如果要喂给别的系统改成encodingutf-8更稳妥。astype(string)而不是默认的 object是为了让str访问器对所有行生效遇到 NaN 也不会炸。最后drop_duplicates按 href 去重是因为分页列表的最后一页经常重复上一页的内容不去重会导出大量重复行。main.py把这些串起来就是一条完整链路# main.py from fetch import build_session, fetch from parse import parse_css from store import save def main(): session build_session() all_rows [] for page in range(1, 6): url fhttps://www.example.com/list?page{page} try: html fetch(session, url) rows parse_css(html) print(f{url} - {len(rows)} 条) all_rows.extend(rows) except Exception as exc: print(f{url} 失败: {exc}) df save(all_rows) print(f共写入 {len(df)} 条) if __name__ __main__: main()单页失败不影响整体这是最小可用的容错策略。跑通这一步剩下的都是在这个骨架上加东西。4. 进阶实战动态渲染、并发与 Scrapy 工程化4.1 动态页面Selenium 的关键在等待策略requests 拿到的是服务端吐出的原始 HTML页面上那些滚动加载、点击加载更多的内容它一条都看不到。判断方法很简单浏览器里 F12 看 Elements 有没有数据禁用 JavaScript 再刷新一次如果数据没了就是动态渲染。Selenium 的用法原文给过一段但真正决定成败的是等待方式from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC options webdriver.ChromeOptions() options.add_argument(--headlessnew) # 无头模式服务器上也能跑 options.add_argument(--disable-gpu) options.add_argument(--window-size1440,900) driver webdriver.Chrome(optionsoptions) try: driver.get(https://www.example.com/list) # 显式等待等目标元素出现最多 10 秒出现就立刻继续 WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.CSS_SELECTOR, div.item)) ) # 触发懒加载滚到底再等一轮 driver.execute_script(window.scrollTo(0, document.body.scrollHeight);) WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.CSS_SELECTOR, div.item:nth-child(20))) ) html driver.page_source finally: driver.quit() # 必须放 finally否则异常时浏览器进程会残留time.sleep(3)和显式等待的差距在实际项目里非常明显固定睡眠在快网下浪费三秒在慢网下又不够WebDriverWait是条件触发元素一出现就走。driver.quit()放 finally 也是踩出来的之前有个定时任务跑了两天机器上堆了几十个僵尸 Chrome 进程内存直接被吃光那次的教训是浏览器实例必须和无头模式、异常兜底一起考虑。Selenium 的缺点同样明显启动一个 Chrome 少说一两秒内存几百 MB抓一百页要跑几分钟。实战里的常见做法是先用 requests 试探有没有可直连的数据接口浏览器 Network 面板筛 XHR很多时候列表数据是 JSON能拿到 JSON 就用 requests 直接请求拿不到再退回 Selenium。这条路径比死磕浏览器渲染效率高一个数量级。4.2 并发线程池和 asyncio 的取舍串行抓一百页每页 sleep 1 秒光等待就一百秒。并发能把这部分压下去但两种方案适用场景不同。线程池适合 requests 这种同步库改造成本最低from concurrent.futures import ThreadPoolExecutor, as_completed def crawl_all(urls: list[str], workers: int 8): session build_session() results {} with ThreadPoolExecutor(max_workersworkers) as pool: # future 到 url 的映射方便失败时定位 future_map {pool.submit(fetch, session, u): u for u in urls} for fut in as_completed(future_map): url future_map[fut] try: results[url] fut.result() except Exception as exc: print(f{url} 失败: {exc}) return resultsmax_workers8不是随便写的。requests 的 Session 在连接池里默认最多复用 10 个连接线程数超过池容量反而会阻塞在排队上。另外并发数和对端承受能力要匹配八个线程打一个小站点已经把对方压得够呛别再加。asyncio 方案适合 I/O 极密集、单页响应很慢的场景协程切换成本比线程低但要求全链路异步import asyncio import aiohttp async def fetch_async(session, url, sem): # 信号量控制并发上限比一次性发几千个请求温和得多 async with sem: async with session.get(url, timeoutaiohttp.ClientTimeout(total20)) as resp: resp.raise_for_status() await asyncio.sleep(0.5) # 异步睡眠不阻塞其它协程 return await resp.text() async def crawl(urls, limit: int 8): sem asyncio.Semaphore(limit) connector aiohttp.TCPConnector(limitlimit) async with aiohttp.ClientSession(connectorconnector) as session: tasks [fetch_async(session, u, sem) for u in urls] # return_exceptionsTrue 让单个失败不取消整批 return await asyncio.gather(*tasks, return_exceptionsTrue)两段代码的关键差别在资源模型线程池靠操作系统调度线程一多上下文切换成本上来协程在单线程内切换几千并发也扛得住。代价是 asyncio 里不能出现任何同步阻塞调用requests.get混进去会把事件循环卡死所以必须换成 aiohttp 或 httpx。选型建议很直接几十到几百个 URL线程池足够改起来也快上千个 URL 并且要长期跑再考虑 asyncio。别为了显得专业提前上异步调试成本不低。4.3 Scrapy 工程Item 定义与 Pipeline 落库第 2 章展示的是 Scrapy 的最小爬虫工程化之后要把字段定义和数据落库拆出去。字段定义用 Item好处是字段名集中管理后期改名字只需要动一处# items.py import scrapy class RecordItem(scrapy.Item): title scrapy.Field() url scrapy.Field() page scrapy.Field()Pipeline 负责清洗和写库。下面这版用 SQLite 落盘跑完直接能查# pipelines.py import sqlite3 class SqlitePipeline: def open_spider(self, spider): self.conn sqlite3.connect(records.db) self.conn.execute( CREATE TABLE IF NOT EXISTS records ( url TEXT PRIMARY KEY, title TEXT, page INTEGER ) ) self.conn.commit() def process_item(self, item, spider): # url 建了主键重复抓取时用 REPLACE 覆盖而不是报错 self.conn.execute( INSERT OR REPLACE INTO records (url, title, page) VALUES (?, ?, ?), (item.get(url), item.get(title), item.get(page)), ) return item def close_spider(self, spider): self.conn.commit() self.conn.close()主键冲突这块值得多说一句爬虫重跑是常态用普通 INSERT 会在第二条重复数据上抛 IntegrityError整批回滚INSERT OR REPLACE靠主键天然幂等重跑几次结果都一样。这个特性在小脚本里靠drop_duplicates模拟数据量一大就必须交给数据库。启用 Pipeline 要在 settings 里注册顺序按数字从小到大执行ITEM_PIPELINES { mycrawler.pipelines.SqlitePipeline: 300, }300是优先级数值小的先跑。如果后面要加一个去重 Pipeline把它设成 100 放在写库前面脏数据就不会进表。5. 排查手册爬虫上线前后最容易翻车的五个点5.1 现象状态码 200但选择器一条都没命中原因通常有三个页面结构和你看到的浏览器 DOM 不一致、内容是 JS 渲染的、或者你拿到的是验证页。先用print(html[:500])把响应头五百个字符打出来一看便知。如果里面是完整的 HTML用浏览器开发者工具重新核一遍选择器多半是类名带哈希或者多了个中间层 div如果里面是一大段 script 加几个空容器那就是动态渲染回到第 4 章换 Selenium或者去 Network 面板找 XHR 里的 JSON 接口。还有一种隐蔽情况请求被重定向到了移动版或地区版页面结构完全不同。resp.url打一下看看和你请求的是不是同一个地址。5.2 现象跑了三四十条突然全部 403 或返回空原因不在代码在节奏。固定 UA、固定间隔、没有会话保持对端的风控模型几十个请求就能识别出来。解决分三层把time.sleep改成带随机扰动的间隔比如time.sleep(random.uniform(1.0, 2.5))让请求时间不呈等差分布复用 Session 保持 Cookie让整轮看起来像同一个访客检查目标站点的 robots.txt确认你要抓的路径本身是允许的。如果对方明确不欢迎正确做法是找官方开放的数据接口或者申请授权而不是想办法绕。这条线守住了后面所有优化才有意义。5.3 现象抓下来的中文全是问号或乱码原因是响应头里的编码声明和实际字节流不一致。requests 的resp.encoding优先取响应头的 charset取不到会退回 ISO-8859-1而这个默认值对中文站点几乎必错。解决方式是在解析前显式纠一次resp session.get(url, timeout(5, 15)) if not resp.encoding or resp.encoding.lower() in (iso-8859-1, ascii): resp.encoding resp.apparent_encoding # 从字节流猜编码 html resp.textapparent_encoding用的是 chardet 那套探测对长文本准确率高短响应偶尔会猜错所以只在响应头不可信时才用它。另外记得 CSV 输出用utf-8-sigExcel 打开才不会乱。5.4 现象并发开到 16总耗时比串行还长原因是并发数超过了连接池容量线程全堵在排队上外加对端开始限流、重试次数飙升。动手前先量一下单请求耗时再核算如果单请求 800ms8 并发理论吞吐是每秒 10 条你把并发开到 32多出来的 24 个线程只是在等连接池的空位。检查HTTPAdapter(pool_maxsize...)是不是小于线程数把它调到线程数的 1.2 倍左右同时确认 429 出现频率一旦上来了说明该降速而不是加速。5.5 现象导出的 Excel 里链接变成科学计数法长数字末尾变 0原因是 Excel 对超过 15 位的数字会自动转浮点纯数字串的 ID、订单号首当其冲。解决办法是在 pandas 里把这些列强制转成字符串再落盘df[order_id] df[order_id].astype(string) df.to_excel(out.xlsx, indexFalse)如果下游一定要用 xlsx 且数据里有超长数字更稳的做法是导出 CSV 时给该字段加个前缀比如或制表符或者干脆只交付 CSV把打开方式交给使用方决定。这种问题不解决数据看着齐整实际已经失真了。6. 二次开发把示例脚本改成自己项目里的采集器这套资料的代码偏演示性质直接用到项目里第一件事是把散落的常量收进配置。我会在项目根目录放一个config.py把站点、选择器、页数、节奏全挤进去# config.py SITE { name: demo_list, list_url: https://www.example.com/list?page{page}, pages: 5, list_selector: div.item, fields: { title: h3.title, # CSS 选择器 href: a.detail, # 取属性时再拼 ::attr(href) }, delay: (1.0, 2.5), # 随机间隔区间 timeout: (5, 15), max_workers: 6, }之后新增一个站点只需要往配置里加一段字典解析和请求代码一行不动。这一步改造的收益在第 3 个站点接入时才体现出来——前面两个站点手写的时候你没感觉第三个开始就是复制粘贴改选择器改到第五个必然会漏。第二个改造点是失败可追溯。给每条记录加source和fetched_at两个字段出问题时能立刻知道是哪台机器、哪一轮抓的。SQLite 那张表里加两列就行代价几乎为零。第三个改造点是验证。爬虫最怕的是“跑完了但数据不对”所以我会在写库之后加一段自查检查项判断方式触发后动作条数突降与上一轮相比跌幅超过 50%中止并告警关键字段为空title 为空的比例超过 10%打印样本人工核对链接格式异常href 不以 http 开头检查 urljoin 与相对路径重复率过高主键冲突比例超过 30%检查分页参数是否失效这套检查写起来不到三十行但拦下过好几次静默失败——页面改版后选择器失效脚本照跑不误只是每条都是空标题。最后一句经验。从那以后我每接一个采集需求都强制先把三件事写进配置再动手要哪几个字段、允许多快的节奏、数据最终存哪儿。这三行没定下来就写代码后面返工的概率高得离谱。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/11/3 6:22:26 · 阅读 1.2k Python爬虫全链路：从requests解析到Scrapy工程化
简介这份面向具备一定编程基础的学习者与开发者的Python爬虫技术文档围绕网络数据采集的完整流程展开帮助读者理解爬虫的基本概念、运行原理与工程规范并逐步掌握从网页请求到数据落地的实现方法。内容以发送请求、解析网页、数据存储三大核心环节为主线结合requests、BeautifulSoup、lxml与Scrapy等常用库的特点和应用场景延伸到动态加载处理、反爬机制应对、采集效率提升等进阶技巧同时强调网站协议、法律法规与用户隐私保护。资源包内含1个docx文档压缩后约16KB体量轻便适合作为随查随用的学习笔记或项目入门参考。目前已有629人学习读者可从中获得较清晰的知识框架、库选型思路与合规采集意识并可将示例思路迁移到批量公开数据获取、信息监测或小型数据挖掘项目中。1. 从四十个链接说起这套 Python 爬虫资料到底解决什么问题上个月一个做运营的朋友甩给我四十多个链接说“你帮我复制到表格里就行”。复制到第七条我就放弃了这种事本来就该交给 Python 爬虫。麻烦的地方在于多数打着“从基础到实战”旗号的教程讲到 requests.get 就收尾了读者手里只剩一行 print不知道一页 HTML 怎么变成一张能交付的表。这套资料把网络数据采集拆成三段——发送 HTTP 请求、解析网页、数据处理与落盘再往上叠动态渲染、并发和 Scrapy 工程化最后收在 robots.txt 与隐私边界上。它适合已经能写 Python 函数、想第一次把采集流程完整跑通的人纯新手也能看但至少要熟悉字典、列表推导和异常处理否则中间那几段解析代码会看得吃力。2. 技术栈分工requests、BeautifulSoup、lxml、Scrapy 各站哪一班岗2.1 一条采集链路的三个断面与各自的失败姿势把爬虫当成一个流水线看它只有三个断面请求层负责把 URL 变成一段 HTML 文本解析层负责把文本变成结构化字段存储层负责把字段变成文件或表。听着简单实际翻车的位置高度集中在三个断面各自的边界上而且失败信号完全不一样。请求层的典型症状是状态码异常403 表示对方不认你的身份429 表示你打得太快连接超时或 reset 往往是网络环境或者对方限流网关在拦。解析层的症状更阴——请求返回 200正文也有几十 KB但选择器一个都没命中这时候八成是页面结构和你想象的不一致或者内容压根是 JS 渲染出来的。存储层的症状最容易被忽略字段串位、中文变问号、长数字被 Excel 转成科学计数法数据看着有实际上已经不能用了。理解这三个断面选型就不再是“哪个库火用哪个”而是“这一层我需要什么能力”。原文列出的 requests、BeautifulSoup、lxml、Scrapy 四个库正好可以按断面归位库所在断面主要职责什么时候别用requests请求发 GET/POST、带请求头、维护会话需要浏览器执行 JS 时BeautifulSoup解析容错解析脏 HTML按标签/属性定位千万级节点、追求极致速度时lxml解析XPath 精确取数C 底层速度快HTML 结构极度残缺、需要强容错时Scrapy全链路调度、去重、并发、管道一条龙只想抓几十页的一次性脚本这张表是后面所有代码的前提。写脚本之前先问自己一句这次是几十页还是几万页几十页requests 加 BeautifulSoup 二十分钟收工几万页并且要长期跑硬写线程池最后会变成维护噩梦该上 Scrapy。2.2 BeautifulSoup 与 lxml同一份 HTML 的两种取法这两个库经常被放在一起比较其实它们解决的是不同层面的问题。BeautifulSoup 的核心价值是容错真实网页里闭合标签缺失、属性没引号是常态它能把这种残缺文档修成树再交给你lxml 的核心价值是快和精确底层是 C 实现的 libxml2XPath 表达能力比 CSS 选择器强一截。先看 BeautifulSoup 的写法from bs4 import BeautifulSoup def parse_with_bs4(html: str): # 第二个参数指定解析后端lxml 比默认的 html.parser 快不少 soup BeautifulSoup(html, lxml) # select 走 CSS 选择器select_one 只取第一个命中的 cards soup.select(div.item) rows [] for card in cards: title_node card.select_one(h3.title) link_node card.select_one(a.detail) rows.append({ # get_text(stripTrue) 会丢掉标签内多余的空白和换行 title: title_node.get_text(stripTrue) if title_node else None, href: link_node.get(href) if link_node else None, }) return rows再看同一份 HTML 的 XPath 写法from lxml import etree def parse_with_lxml(html: str): tree etree.HTML(html) # 容错地把字符串解析成树 titles tree.xpath(//div[classitem]/h3[classtitle]/text()) hrefs tree.xpath(//div[classitem]/a[classdetail]/href) # XPath 返回的是列表长度可能不一致用 zip 合并前先确认元素个数 return [ {title: t.strip(), href: h} for t, h in zip(titles, hrefs) if t.strip() ]两段代码的差别不只是语法。BeautifulSoup 按卡片循环天然保证 title 和 href 属于同一张卡片lxml 那版分别取两个列表再 zip一旦某个卡片缺了标题两个列表就错位了——这是我在真实项目里踩过的坑数据量小的时候根本看不出来跑到几千条才发现后半段标题全串了。所以用 XPath 时更稳的写法是定位到父节点再逐个取子节点def parse_with_lxml_safe(html: str): tree etree.HTML(html) rows [] # 先取父节点保持卡片内的字段绑定关系 for card in tree.xpath(//div[classitem]): title card.xpath(./h3[classtitle]/text()) href card.xpath(./a[classdetail]/href) rows.append({ title: title[0].strip() if title else None, href: href[0] if href else None, }) return rows参数上要留意的几处etree.HTML的入参必须是 str如果 requests 返回的是 bytes 且你知道编码用etree.HTML(resp.content)让它自己嗅探反而更省事xpath(./...)开头的点表示相对当前节点漏掉就是从根找起结果会重复出所有卡片的字段。BeautifulSoup 的parser参数选lxml时依赖本机装了 lxml没装会直接抛异常选html.parser则零依赖但慢。性能上十万级节点的页面lxml 通常比 BeautifulSoup 快三到五倍。但也别因此一律上 lxml——结构脏到 lxml 解析出一棵空树的时候BeautifulSoup 往往还能救回来。常见做法是先用 lxml解析结果为空再回退到 BeautifulSoup两个都不行才说明页面是 JS 渲染的。2.3 Scrapy 该不该上并发模型与项目边界Scrapy 不是“更高级的 requests”它是另一种组织方式。原文给的示例很短实际工程里它的价值体现在调度层内置的请求队列、去重指纹、按域名限速、失败重试、以及 Item Pipeline 这套数据处理钩子。import scrapy class ListSpider(scrapy.Spider): name list custom_settings { # 每个请求之间至少间隔 0.8 秒给对端留口气 DOWNLOAD_DELAY: 0.8, # 同一个域名下最多 4 个请求并发别把并发数开到天上去 CONCURRENT_REQUESTS_PER_DOMAIN: 4, # 自动限速根据响应延迟动态调节节奏 AUTOTHROTTLE_ENABLED: True, # 结果直接落成 jsonl一行一条断了也不会全丢 FEEDS: {items.jsonl: {format: jsonlines, encoding: utf8}}, } def start_requests(self): # 分页入口Scrapy 会自动排队 for page in range(1, 6): yield scrapy.Request( fhttps://www.example.com/list?page{page}, callbackself.parse, errbackself.on_error, ) def parse(self, response): for card in response.css(div.item): yield { title: card.css(h3.title::text).get(default).strip(), # urljoin 处理相对路径别自己拼字符串 url: response.urljoin(card.css(a.detail::attr(href)).get()), } def on_error(self, failure): # 单页失败不影响整轮记下来回头补 self.logger.warning(抓取失败: %s, failure.request.url)几个参数值得说清楚。DOWNLOAD_DELAY是全局下限CONCURRENT_REQUESTS_PER_DOMAIN控制同域并发这两个一起决定了对方服务器的感受AUTOTHROTTLE_ENABLED打开后 Scrapy 会盯着响应时间自动调整比手写 sleep 明智。parse里的yield出去的字典会进 Pipeline清洗、去重、写库都能在那儿做业务代码和调度代码就此分开。反过来说如果你只是想抓几十个页面导出个 Excel引入 Scrapy 就是给自己找麻烦要建工程、写 settings、理解 Twisted 的异步模型收益为零。判断标准很朴素——需要断点续跑、需要分布式、需要长期定时执行才考虑 Scrapy一次性小任务requests 加个 for 循环就是最优解。3. 跑通第一条链路从一次 GET 到一张能打开的 CSV3.1 环境与最小目录结构先把依赖装齐。requests 和 beautifulsoup4 是必装lxml 和 pandas 看需求selenium 等到要抓动态页再说python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate pip install requests beautifulsoup4 lxml pandas目录别一上来就摊一堆文件三个模块加一个入口足够crawler/ ├── fetch.py # 请求层Session、重试、超时 ├── parse.py # 解析层CSS / XPath 两种取法 ├── store.py # 存储层清洗 落盘 └── main.py # 串流程这个拆分的好处是等需求从“抓一个站”变成“抓五个站”你只需要在 parse.py 里加选择器请求和存储逻辑一行不用改。3.2 请求层把 Session、超时、重试封成一个函数裸写requests.get(url)在真实站点上撑不过十分钟。下面这版是我一般会用的最小封装# fetch.py import time import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry DEFAULT_UA ( Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36 ) def build_session(retries: int 3, backoff: float 1.5) - requests.Session: 构造带重试策略和连接复用的 Session session requests.Session() retry Retry( totalretries, # 总重试次数 backoff_factorbackoff, # 第 n 次重试等待 backoff * 2^n 秒 status_forcelist[429, 500, 502, 503, 504], # 只对这些状态码重试 allowed_methods[GET], # 别对 POST 盲目重试会重复提交 ) # 连接池大小要和并发数匹配太小会频繁建连 adapter HTTPAdapter(max_retriesretry, pool_connections20, pool_maxsize20) session.mount(https://, adapter) session.mount(http://, adapter) session.headers.update({ User-Agent: DEFAULT_UA, Accept-Language: zh-CN,zh;q0.9, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, }) return session def fetch(session: requests.Session, url: str, timeout(5, 15), sleep: float 1.0) - str: 返回 HTML 文本失败直接抛异常由调用方决定怎么处理 resp session.get(url, timeouttimeout) # 4xx / 5xx 立刻抛别让错误页混进解析层 resp.raise_for_status() # 让响应自己报编码报错了再手动指定 if not resp.encoding or resp.encoding.lower() iso-8859-1: resp.encoding resp.apparent_encoding text resp.text if sleep: time.sleep(sleep) return text参数里最值得琢磨的是timeout(5, 15)这是个二元组前者是建立连接的超时后者是等待首字节的超时。只写一个数字时两者相同抓慢接口很容易在读取阶段被掐断。status_forcelist不去加 403因为 403 是身份问题重试一百次也还是 403反而是 429 和 5xx 值得重试。raise_for_status()这行看着不起眼但它是一条分界线请求层只负责告诉你这次拿到的到底是不是有效内容判断逻辑留给上层。我见过不少脚本把所有异常都 try 住然后继续跑最后导出的表里混进一堆登录页 HTML排查半天才发现是三次重试全失败了。至于编码那段判断是因为有一批老站点在响应头里写死ISO-8859-1却实际输出 UTF-8不纠正就会有整页中文变乱码——这个在第 5 章还会展开。3.3 解析层一套字段两条取数路径把第 2 章的两段解析函数合到一个文件里做成同一个签名方便按站点切换# parse.py from bs4 import BeautifulSoup from lxml import etree def parse_css(html: str) - list[dict]: soup BeautifulSoup(html, lxml) rows [] for card in soup.select(div.item): title card.select_one(h3.title) link card.select_one(a.detail) rows.append({ title: title.get_text(stripTrue) if title else , href: link.get(href, ) if link else , }) return rows def parse_xpath(html: str) - list[dict]: tree etree.HTML(html) if tree is None: # 解析彻底失败时 lxml 会返回 None return [] rows [] for card in tree.xpath(//div[classitem]): title card.xpath(./h3[classtitle]/text()) href card.xpath(./a[classdetail]/href) rows.append({ title: title[0].strip() if title else , href: href[0] if href else , }) return rows两个函数都做了空值兜底返回的字段名保持一致。这一点在二次开发时特别省事——换站点只需要换选择器下游完全无感。选择器怎么定我的习惯是先在浏览器开发者工具里右键“复制 selector”粘到代码里跑一次命中了再精简。类名里带哈希的那种形如item-3f8a2千万别直接抄那是构建工具生成的隔天就变得往上找稳定的父级结构比如div.list div这种位置型选择器。tree is None那个判断也别省lxml 在极端情况下比如拿到的是空字符串会返回 None不判的话下一行 xpath 直接 AttributeError。3.4 存储层pandas 落盘与字段清洗解析出来的字典列表直接扔给 DataFrame再做一轮清洗最后按格式落盘# store.py import pandas as pd def save(rows: list[dict], path: str items.csv) - pd.DataFrame: df pd.DataFrame(rows) if df.empty: return df # 统一去掉首尾空白、把连续空白压成一个空格 for col in (title, href): if col in df.columns: df[col] df[col].astype(string).str.replace(r\s, , regexTrue).str.strip() # 相对链接补成绝对链接后面二次访问用得上 df.drop_duplicates(subset[href], inplaceTrue) df.reset_index(dropTrue, inplaceTrue) # utf-8-sig 让 Excel 双击打开不乱码 df.to_csv(path, indexFalse, encodingutf-8-sig) return dfutf-8-sig是血泪经验普通 utf-8 编码的 CSV 用 Excel 打开中文百分百变问号加个 BOM 头就正常了。代价是某些程序读这个文件时表头会多一个不可见字符所以如果要喂给别的系统改成encodingutf-8更稳妥。astype(string)而不是默认的 object是为了让str访问器对所有行生效遇到 NaN 也不会炸。最后drop_duplicates按 href 去重是因为分页列表的最后一页经常重复上一页的内容不去重会导出大量重复行。main.py把这些串起来就是一条完整链路# main.py from fetch import build_session, fetch from parse import parse_css from store import save def main(): session build_session() all_rows [] for page in range(1, 6): url fhttps://www.example.com/list?page{page} try: html fetch(session, url) rows parse_css(html) print(f{url} - {len(rows)} 条) all_rows.extend(rows) except Exception as exc: print(f{url} 失败: {exc}) df save(all_rows) print(f共写入 {len(df)} 条) if __name__ __main__: main()单页失败不影响整体这是最小可用的容错策略。跑通这一步剩下的都是在这个骨架上加东西。4. 进阶实战动态渲染、并发与 Scrapy 工程化4.1 动态页面Selenium 的关键在等待策略requests 拿到的是服务端吐出的原始 HTML页面上那些滚动加载、点击加载更多的内容它一条都看不到。判断方法很简单浏览器里 F12 看 Elements 有没有数据禁用 JavaScript 再刷新一次如果数据没了就是动态渲染。Selenium 的用法原文给过一段但真正决定成败的是等待方式from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC options webdriver.ChromeOptions() options.add_argument(--headlessnew) # 无头模式服务器上也能跑 options.add_argument(--disable-gpu) options.add_argument(--window-size1440,900) driver webdriver.Chrome(optionsoptions) try: driver.get(https://www.example.com/list) # 显式等待等目标元素出现最多 10 秒出现就立刻继续 WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.CSS_SELECTOR, div.item)) ) # 触发懒加载滚到底再等一轮 driver.execute_script(window.scrollTo(0, document.body.scrollHeight);) WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.CSS_SELECTOR, div.item:nth-child(20))) ) html driver.page_source finally: driver.quit() # 必须放 finally否则异常时浏览器进程会残留time.sleep(3)和显式等待的差距在实际项目里非常明显固定睡眠在快网下浪费三秒在慢网下又不够WebDriverWait是条件触发元素一出现就走。driver.quit()放 finally 也是踩出来的之前有个定时任务跑了两天机器上堆了几十个僵尸 Chrome 进程内存直接被吃光那次的教训是浏览器实例必须和无头模式、异常兜底一起考虑。Selenium 的缺点同样明显启动一个 Chrome 少说一两秒内存几百 MB抓一百页要跑几分钟。实战里的常见做法是先用 requests 试探有没有可直连的数据接口浏览器 Network 面板筛 XHR很多时候列表数据是 JSON能拿到 JSON 就用 requests 直接请求拿不到再退回 Selenium。这条路径比死磕浏览器渲染效率高一个数量级。4.2 并发线程池和 asyncio 的取舍串行抓一百页每页 sleep 1 秒光等待就一百秒。并发能把这部分压下去但两种方案适用场景不同。线程池适合 requests 这种同步库改造成本最低from concurrent.futures import ThreadPoolExecutor, as_completed def crawl_all(urls: list[str], workers: int 8): session build_session() results {} with ThreadPoolExecutor(max_workersworkers) as pool: # future 到 url 的映射方便失败时定位 future_map {pool.submit(fetch, session, u): u for u in urls} for fut in as_completed(future_map): url future_map[fut] try: results[url] fut.result() except Exception as exc: print(f{url} 失败: {exc}) return resultsmax_workers8不是随便写的。requests 的 Session 在连接池里默认最多复用 10 个连接线程数超过池容量反而会阻塞在排队上。另外并发数和对端承受能力要匹配八个线程打一个小站点已经把对方压得够呛别再加。asyncio 方案适合 I/O 极密集、单页响应很慢的场景协程切换成本比线程低但要求全链路异步import asyncio import aiohttp async def fetch_async(session, url, sem): # 信号量控制并发上限比一次性发几千个请求温和得多 async with sem: async with session.get(url, timeoutaiohttp.ClientTimeout(total20)) as resp: resp.raise_for_status() await asyncio.sleep(0.5) # 异步睡眠不阻塞其它协程 return await resp.text() async def crawl(urls, limit: int 8): sem asyncio.Semaphore(limit) connector aiohttp.TCPConnector(limitlimit) async with aiohttp.ClientSession(connectorconnector) as session: tasks [fetch_async(session, u, sem) for u in urls] # return_exceptionsTrue 让单个失败不取消整批 return await asyncio.gather(*tasks, return_exceptionsTrue)两段代码的关键差别在资源模型线程池靠操作系统调度线程一多上下文切换成本上来协程在单线程内切换几千并发也扛得住。代价是 asyncio 里不能出现任何同步阻塞调用requests.get混进去会把事件循环卡死所以必须换成 aiohttp 或 httpx。选型建议很直接几十到几百个 URL线程池足够改起来也快上千个 URL 并且要长期跑再考虑 asyncio。别为了显得专业提前上异步调试成本不低。4.3 Scrapy 工程Item 定义与 Pipeline 落库第 2 章展示的是 Scrapy 的最小爬虫工程化之后要把字段定义和数据落库拆出去。字段定义用 Item好处是字段名集中管理后期改名字只需要动一处# items.py import scrapy class RecordItem(scrapy.Item): title scrapy.Field() url scrapy.Field() page scrapy.Field()Pipeline 负责清洗和写库。下面这版用 SQLite 落盘跑完直接能查# pipelines.py import sqlite3 class SqlitePipeline: def open_spider(self, spider): self.conn sqlite3.connect(records.db) self.conn.execute( CREATE TABLE IF NOT EXISTS records ( url TEXT PRIMARY KEY, title TEXT, page INTEGER ) ) self.conn.commit() def process_item(self, item, spider): # url 建了主键重复抓取时用 REPLACE 覆盖而不是报错 self.conn.execute( INSERT OR REPLACE INTO records (url, title, page) VALUES (?, ?, ?), (item.get(url), item.get(title), item.get(page)), ) return item def close_spider(self, spider): self.conn.commit() self.conn.close()主键冲突这块值得多说一句爬虫重跑是常态用普通 INSERT 会在第二条重复数据上抛 IntegrityError整批回滚INSERT OR REPLACE靠主键天然幂等重跑几次结果都一样。这个特性在小脚本里靠drop_duplicates模拟数据量一大就必须交给数据库。启用 Pipeline 要在 settings 里注册顺序按数字从小到大执行ITEM_PIPELINES { mycrawler.pipelines.SqlitePipeline: 300, }300是优先级数值小的先跑。如果后面要加一个去重 Pipeline把它设成 100 放在写库前面脏数据就不会进表。5. 排查手册爬虫上线前后最容易翻车的五个点5.1 现象状态码 200但选择器一条都没命中原因通常有三个页面结构和你看到的浏览器 DOM 不一致、内容是 JS 渲染的、或者你拿到的是验证页。先用print(html[:500])把响应头五百个字符打出来一看便知。如果里面是完整的 HTML用浏览器开发者工具重新核一遍选择器多半是类名带哈希或者多了个中间层 div如果里面是一大段 script 加几个空容器那就是动态渲染回到第 4 章换 Selenium或者去 Network 面板找 XHR 里的 JSON 接口。还有一种隐蔽情况请求被重定向到了移动版或地区版页面结构完全不同。resp.url打一下看看和你请求的是不是同一个地址。5.2 现象跑了三四十条突然全部 403 或返回空原因不在代码在节奏。固定 UA、固定间隔、没有会话保持对端的风控模型几十个请求就能识别出来。解决分三层把time.sleep改成带随机扰动的间隔比如time.sleep(random.uniform(1.0, 2.5))让请求时间不呈等差分布复用 Session 保持 Cookie让整轮看起来像同一个访客检查目标站点的 robots.txt确认你要抓的路径本身是允许的。如果对方明确不欢迎正确做法是找官方开放的数据接口或者申请授权而不是想办法绕。这条线守住了后面所有优化才有意义。5.3 现象抓下来的中文全是问号或乱码原因是响应头里的编码声明和实际字节流不一致。requests 的resp.encoding优先取响应头的 charset取不到会退回 ISO-8859-1而这个默认值对中文站点几乎必错。解决方式是在解析前显式纠一次resp session.get(url, timeout(5, 15)) if not resp.encoding or resp.encoding.lower() in (iso-8859-1, ascii): resp.encoding resp.apparent_encoding # 从字节流猜编码 html resp.textapparent_encoding用的是 chardet 那套探测对长文本准确率高短响应偶尔会猜错所以只在响应头不可信时才用它。另外记得 CSV 输出用utf-8-sigExcel 打开才不会乱。5.4 现象并发开到 16总耗时比串行还长原因是并发数超过了连接池容量线程全堵在排队上外加对端开始限流、重试次数飙升。动手前先量一下单请求耗时再核算如果单请求 800ms8 并发理论吞吐是每秒 10 条你把并发开到 32多出来的 24 个线程只是在等连接池的空位。检查HTTPAdapter(pool_maxsize...)是不是小于线程数把它调到线程数的 1.2 倍左右同时确认 429 出现频率一旦上来了说明该降速而不是加速。5.5 现象导出的 Excel 里链接变成科学计数法长数字末尾变 0原因是 Excel 对超过 15 位的数字会自动转浮点纯数字串的 ID、订单号首当其冲。解决办法是在 pandas 里把这些列强制转成字符串再落盘df[order_id] df[order_id].astype(string) df.to_excel(out.xlsx, indexFalse)如果下游一定要用 xlsx 且数据里有超长数字更稳的做法是导出 CSV 时给该字段加个前缀比如或制表符或者干脆只交付 CSV把打开方式交给使用方决定。这种问题不解决数据看着齐整实际已经失真了。6. 二次开发把示例脚本改成自己项目里的采集器这套资料的代码偏演示性质直接用到项目里第一件事是把散落的常量收进配置。我会在项目根目录放一个config.py把站点、选择器、页数、节奏全挤进去# config.py SITE { name: demo_list, list_url: https://www.example.com/list?page{page}, pages: 5, list_selector: div.item, fields: { title: h3.title, # CSS 选择器 href: a.detail, # 取属性时再拼 ::attr(href) }, delay: (1.0, 2.5), # 随机间隔区间 timeout: (5, 15), max_workers: 6, }之后新增一个站点只需要往配置里加一段字典解析和请求代码一行不动。这一步改造的收益在第 3 个站点接入时才体现出来——前面两个站点手写的时候你没感觉第三个开始就是复制粘贴改选择器改到第五个必然会漏。第二个改造点是失败可追溯。给每条记录加source和fetched_at两个字段出问题时能立刻知道是哪台机器、哪一轮抓的。SQLite 那张表里加两列就行代价几乎为零。第三个改造点是验证。爬虫最怕的是“跑完了但数据不对”所以我会在写库之后加一段自查检查项判断方式触发后动作条数突降与上一轮相比跌幅超过 50%中止并告警关键字段为空title 为空的比例超过 10%打印样本人工核对链接格式异常href 不以 http 开头检查 urljoin 与相对路径重复率过高主键冲突比例超过 30%检查分页参数是否失效这套检查写起来不到三十行但拦下过好几次静默失败——页面改版后选择器失效脚本照跑不误只是每条都是空标题。最后一句经验。从那以后我每接一个采集需求都强制先把三件事写进配置再动手要哪几个字段、允许多快的节奏、数据最终存哪儿。这三行没定下来就写代码后面返工的概率高得离谱。希望帮到你。本文还有配套的精品资源点击获取