企业官网建设流程全解析

很多刚入门的朋友会用Python的requests库把网页源码抓下来，再用BeautifulSoup把数据抠出来，最后存进CSV，然后觉得爬虫差不多就会了。直到某天遇到一个必须登录才能看的页面、一个请求频率太高会被临时封掉的网站、或者一个数据量过千就得跑半天的任务，才反应过来，自己一直停在“脚本”阶段，并没有进入“工程”阶段。这篇进阶版要聊的，就是从零基础衔接上来的关键知识点：请求、解析、存储、反爬、工程化，一条线走完，顺便把热词里那些“Python爬虫”“requests爬虫”“sqlalchemy储存爬虫数据”“分布式爬虫”具体落到实操上。

内容定位是“零基础衔接进阶”，所以不讲Hello World和变量类型，也不会一上来就谈分布式集群。适合两类人：一是已经能跑通简单爬虫但不知道怎么系统进阶的初学者；二是学了一半卡在“会写但撑不起项目”，离真正的爬虫工程师还差一口气的人。整篇文章不要求很强的编程背景，但建议你手边开着Python环境，把示例代码敲一遍。

1. 先想清楚：零基础到进阶真正要跨过的三道坎

1.1 爬虫不只是“拿到HTML”：请求、解析、存储的完整链路

零基础阶段看到的爬虫教程，90%都在讲一件事：requests.get(URL)，然后解析HTML。这个简化没有错，但会把人的视野限制住。网络爬虫原理本身并不复杂，本质上就是模拟浏览器向服务器发起HTTP请求，再对响应做提取，可真实项目不是单点操作，而是一条流水线：采集、清洗、落地、监控。每个环节在进阶阶段都有自己的深度。

以请求为例：零基础只要拿到200状态码就行；进阶要考虑超时、重试、请求头、连接复用；再往上要考虑频率控制和分布式协调。解析也一样：基础只要找得到数据；进阶要考虑性能和健壮性；更进阶要考虑页面结构变化时的自适应。存储环节就更明显了，初学者存CSV觉得万事大吉，一旦要做增量、去重、并发写入，CSV就成了瓶颈。

所以你问“零基础到进阶到底差什么”，差的就是把“能跑的脚本”拆成“能扛事的系统”的能力。后面的章节都是围绕这条链路展开的。

1.2 零基础最常见的两个误区

第一个误区是“能用就行”。临时脚本和稳定系统的边界，在于异常处理。我见过太多人写爬虫不设超时、不处理请求异常，本地跑十分钟没问题，放到服务器上跑一晚上，第两百次请求时网络抖动了一下，整个程序直接崩掉，之前的进度全丢。“能用”和“稳定”之间，差的不是代码量，是健壮性的意识。

第二个误区是“越快的代码越高级”。很多人一提到进阶就想着上多线程、上异步、上分布式，结果代码写得花里胡哨，反而没法维护。Python爬虫大部分场景是IO密集型，多线程和异步确实有效；但如果是解析密集型的任务，多线程在GIL下收益有限，反而多进程更合适。选型不取决于哪个技术“听起来厉害”，而取决于你的瓶颈在哪。先学会用一个简单的循环把任务跑稳，再谈并发优化。

1.3 “进阶”到底指什么

我可以直接给个定义：进阶不是会用更花哨的库，而是三个能力的提升。

第一是稳定性，让爬虫能持续跑，挂了自己能恢复；第二是规范性，代码拿给别人看，别人能快速接手，你写的SQLAlchemy表结构别人能看懂；第三是合规性，知道什么数据能爬、什么不能爬，知道频率控制在什么程度不影响网站正常服务。这三点才是“进阶版”和“入门版”的分水岭。技术上能抓多少数据是一回事，能不能稳定、规范、合规地抓，是另一回事。

2. 请求这一层，需要补哪些东西才能“稳”

2.1 状态码、超时与重试：先学会健壮地请求

零基础写请求通常是这样：requests.get(url)，然后用response.text。进阶的第一步，是学会看状态码。

200是正常；301/302是跳转，requests默认不跟随时要注意allow_redirects参数；403是服务器拒绝访问，这时候重试等于给服务器“送人头”；429表示请求太频繁，服务器明确告诉你“慢一点”；5xx是服务器内部错误或网关问题，这种可以重试。

真正完整的请求逻辑，应该包含超时、重试和连接池。我一般用requests.Session配合urllib3的Retry来做，一个基础模板长这样：

import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry session = requests.Session() retry = Retry( total=3, connect=3, backoff_factor=0.5, status_forcelist=[500, 502, 503, 504], allowed_methods=["GET"] ) adapter = HTTPAdapter( max_retries=retry, pool_connections=10, pool_maxsize=20 ) session.mount("http://", adapter) session.mount("https://", adapter) resp = session.get("https://example.com/data", timeout=10) print(resp.status_code, resp.json())

backoff_factor=0.5表示第一次重试等0.5秒，第二次等1秒，第三次等2秒，指数退避，避免重试风暴。429这种状态码不要放在status_forcelist里硬重试，而是应该读响应头里的Retry-After，按服务器要求的时间再继续。

2.2 Session、Cookie与登录态的本质

很多初学者不知道Cookie是什么，看到登录后的页面就抓瞎。打个比方：服务器是无状态的，它不记得你是谁，但你在第一次访问时它会发给你一个“身份牌”，也就是Cookie；你后续每次请求都带着这个身份牌，服务器就认得你了。

在requests里，最直接的做法是手动从浏览器复制Cookie粘到请求头里。但这有个问题，Cookie是会过期的，手动复制只能管一时。进阶做法是用Session对象自动维护：先用requests.post提交登录表单，服务器返回的Set-Cookie会被Session自动保存，后续再用同一个Session访问需要登录的页面，就带着身份牌了。

login_data = {"username": "your_name", "password": "your_password"} session = requests.Session() session.post("https://example.com/login", data=login_data) # 后续访问自动携带登录态 resp = session.get("https://example.com/private")

这里的关键点是：登录的本质不是“打开一个网页”，而是“拿到一个合法的身份凭证并持续携带”。理解了这个，你再遇到需要token、需要签名、需要扫码登录的网站，思路都是一样的，只是在获取凭证的方式上做变化。

2.3 Headers伪装与时序模拟：服务器视角看请求

服务器判断你是不是爬虫，往往不是你抓了多少数据，而是你请求的“气质”不对。正常浏览器发请求，会带一整套请求头：User-Agent、Referer、Accept-Language、Accept-Encoding、Host等等。初学者只改一个User-Agent，其他头是requests的默认值，服务器一眼就能看出来。

我的习惯是配置一个完整的默认Headers，而不是每次单独传。比如模拟Chrome的常见组合就要包含UA、Referer、Accept、Accept-Language。另外时序上也要注意，正常人看页面是“点一下，停几秒，再看下一个”，爬虫是“咔咔咔疯狂连点”，服务器后端很容易通过请求间隔识别。常见的处理是加随机延迟：

import random import time req_delay = random.uniform(1.2, 3.5) time.sleep(req_delay)

不要用固定间隔比如sleep(2)，固定间隔反而更机械化。随机间隔让请求分布更接近真人操作，也能降低对目标服务器造成瞬时压力的概率。当然，这只是一层很基础的防护，真正的重点是“不要过度伪装”——一个请求头完美得无可挑剔、每次间隔完全均匀的请求，在统计意义上反而更可疑。

2.4 连接池与异常兜底

requests默认每次请求都会创建新连接，这对批量任务来说是很大的浪费。前面代码里用HTTPAdapter设置pool_connections和pool_maxsize，就是让Session复用TCP连接，减少三次握手开销。我实际测试过，同样1000个请求，开了连接池之后耗时能降到原来的三分之一左右，尤其是访问HTTPS站点，效果更明显。

异常兜底则是另一个必修课。requests的异常体系是有层级的：requests.exceptions.RequestException是总纲，底下分Timeout、ConnectionError、HTTPError等。不要只写一个裸的try/except，那会把所有错误一视同仁，不利于排查。建议分开捕获：

try: resp = session.get(url, timeout=10) resp.raise_for_status() except requests.exceptions.Timeout: # 超时：记录日志，跳过或重试 pass except requests.exceptions.ConnectionError: # 连接失败：可能网络抖动，先睡一会再重试 pass except requests.exceptions.HTTPError as e: # HTTPError：4xx/5xx，按状态码处理 pass

我踩过的一个坑是：爬虫跑了一天后所有请求集体超时，排查了半天，发现是某个循环里每次都用requests.get创建新连接，没有复用Session，导致目标服务器把我这个IP的连接数打满了。后来改成全局唯一Session，问题立刻消失。连接池不是性能优化，是稳定性的基础。

3. 解析方案怎么选：正则不够用的下一步

3.1 四种解析方案怎么选

零基础学解析，通常从正则表达式开始。正则确实强大，但它不适合用来解析HTML，因为HTML结构复杂、标签嵌套，正则是“按字符串模式硬抠”，HTML稍微改个属性顺序就会失配。而且正则写出来的代码可读性极差，维护成本高。

真正干活的时候，我一般按下面这张表来选：

我的建议是：零基础先用BeautifulSoup跑通逻辑，上生产环境优先用lxml + XPath。XPath的语法很直观，//div[@class='list']/a[@class='item']/text()翻译过来就是“找到class为list的div下所有class为item的a标签的文本”，既好写也好排查。

from lxml import etree html = """ <html><body><div class="list"> <a href="/a" class="item">第一项</a> <a href="/b" class="item">第二项</a> </div></body></html> """ tree = etree.HTML(html) titles = tree.xpath("//div[@class='list']/a[@class='item']/text()") hrefs = tree.xpath("//div[@class='list']/a[@class='item']/@href") print(titles, hrefs)

3.2 从HTML转向JSON接口：数据其实在接口里

关于“爬虫逆向”，先说一个很多新手不知道的事实：大部分现代网站的数据根本不在HTML里，而是在JS脚本异步请求回来的JSON接口里。你在浏览器里看到的页面内容，是HTML骨架加JavaScript渲染的结果；requests拿到的是骨架，自然找不到数据。

正确的做法是打开浏览器开发者工具，切到Network面板，刷新页面，过滤XHR请求，找到返回JSON数据的那一条连接，直接请求这个JSON接口解析数据，比渲染HTML高效得多。就拿游戏战绩查询这个场景来说，与其去渲染一个复杂的页面，不如先看它前端到底调用了哪个开放接口，往往直接就能拿到结构清晰的JSON。

用JSON的好处是字段结构固定、不怕页面改版、性能高。很多人以为“爬虫逆向”多神秘，其实第一步就是搞清楚“数据到底从哪里来”。当你能稳定找到真实接口、分析签名参数时，你已经在做逆向的启蒙工作了。但这里要强调一个边界：学习分析签名机制没问题，但不要为了突破别人的保护措施而去破解非公开数据。

3.3 解析健壮性的三个习惯

我把从实战里总结出来的三个习惯写在这里，每个都吃过亏。

第一个习惯是写解析前先看结构。拿到HTML不要直接写XPath，先在浏览器里用Elements面板确认目标节点的层级、class名、兄弟节点关系，再动手写表达式。很多XPath写半天不生效，就是因为class名写错了或层级搞错了。

第二个习惯是给解析加兜底。用find或xpath找不到元素时，不要让它抛异常搞崩整个爬虫，而是要返回空值并记录日志。比如某一条数据缺了标题，可以这样处理：

try: title = tree.xpath("//h1/text()")[0].strip() except (IndexError, AttributeError): title = "" logger.warning(f"标题解析失败，URL: {url}")

第三个习惯是清洗数据。从页面抓下来的字符串经常会带换行、空格、全角半角混用，数字字段可能带单位。清洗分三步：strip去空白、统一格式（日期转成datetime，数字转成int/float）、去重。不要指望页面给你干净数据，清洗这一步省不掉的。

4. 用SQLAlchemy把爬下来的数据存成体系

4.1 为什么随手存CSV会在三天后后悔

CSV作为学习阶段的存储方案，没有任何问题，文件打开就能看，也能拖进Excel。问题出现在三个场景里：

一是并发写入。多线程爬虫往同一个CSV文件写入时，两个线程同时操作文件指针，轻则数据错乱，重则文件损坏。二是数据量上来之后，几万条记录CSV还能凑合，到几十万条时，用pandas读一次要好几秒，而且没有索引，每次去重必须全表扫描。三是字段类型容易错乱，ID被Excel识别成科学计数法这事，相信不少人都经历过。

SQLAlchemy是Python生态里最主流的ORM工具，它把数据库表映射成Python类，你操作的是对象，它负责翻译成SQL语句。除了SQLite，换成MySQL、PostgreSQL只改一行连接字符串，表结构定义完全复用。这一步是从“爬虫脚本”跨向“数据系统”的关键节点。

4.2 SQLAlchemy的ORM建模与建表

举一个最简单的文章表模型，把核心用法串起来。

from sqlalchemy import create_engine, Column, Integer, String, DateTime from sqlalchemy.orm import declarative_base from sqlalchemy.orm import sessionmaker from datetime import datetime Base = declarative_base() class Article(Base): __tablename__ = "articles" id = Column(Integer, primary_key=True, autoincrement=True) url = Column(String(500), unique=True, index=True, nullable=False) title = Column(String(200), nullable=False) author = Column(String(100)) created_at = Column(DateTime, default=datetime.now) engine = create_engine("sqlite:///crawler.db", echo=False) Base.metadata.create_all(engine)

unique=True这个约束非常重要，它告诉数据库“同一个URL只能出现一次”，重复插入就会触发唯一约束错误。这是数据库层面最基础的去重手段，比你在Python里做 if not in list 要可靠得多。index=True则给URL字段建索引，等表有几万行数据时，按URL查询会快很多。

4.3 Session、连接池与批量写入

SQLAlchemy的Session是操作数据库的入口，可以理解成一个“工作单元”。写入数据的标准流程是：创建对象，add到Session，commit提交。但有一个反直觉的点：不要每条数据都commit一次。

假设你爬了2000条数据，一条一条commit，每条连接需要几百毫秒，总耗时好几秒甚至十几秒。而正确的做法是攒够一批再写：

items = [...] db = sessionmaker(bind=engine)() batch = [Article(url=item["url"], title=item["title"], author=item.get("author")) for item in items] db.add_all(batch) db.commit() db.close()

分批批量写入时，建议每500条或1000条提交一次，既能控制事务大小，也不会因为一条脏数据导致全部回滚。连接池方面，create_engine时默认pool_size=5、max_overflow=10，也就是说默认最多15个并发连接。多线程爬虫如果开了20个线程同时写库，一定要调大连接池上限，否则线程会互相等待数据库连接。

4.4 增量爬取与去重：数据库不只为存

真正让数据库发光的地方，是增量爬取。全量爬虫每次把整个站重新抓一遍，既低效又容易触发反爬。增量爬取的思路是：记录每个URL的抓取时间，或者给每条记录加一个updated_at字段，下次只抓那些没有抓过或者已经更新的页面。

去重也有三件套可以组合使用：数据库唯一约束做底层兜底；SQLAlchemy查询时先查一次记录是否存在；写入时捕获IntegrityError忽略重复数据。我经常用的是第一种加第三种组合，效率最高。

try: db.add(article) db.commit() except IntegrityError: db.rollback() logger.info(f"重复数据跳过: {article.url}")

这里rollback一定要做，因为事务已经失败了，不rollback的话后续所有写入都会卡住。你在CSV阶段打死也不会考虑这些问题，但一旦数据量上来，数据库方案带给你的不是“更好看”，而是“能跑下去”。

5. 反爬与合规：技术博弈的边界在哪

5.1 常见反爬机制与应对思路

反爬机制的目标不是完全禁止爬虫，而是限制异常行为。常见的机制有几类：UA指纹检测、请求频率限制、验证码、签名参数加密、字体反爬。对应到技术思路大概是这样的：

UA检测是最容易过的，配置完整请求头就行。频率限制是主流，应对的核心不是“更快地绕过”，而是“更慢地适配”，随机延迟加指数退避在大多数场景已经足够。签名参数加密则是现在很多App和网站用的方式，请求里带一个动态sign，服务器校验通过才返回数据，这种需要分析前端的加密算法和签名逻辑，也就是大家常说的“爬虫逆向”。

这里我多说一句。逆向本身是安全研究里的正当技能，分析JS加密、理解签名机制，能极大提升你对HTTP协议和前端安全的认知。但用在爬虫上，是典型的“能力越大责任越大”。你可以为了学习去分析公开网站的签名，但不要真的用它去突破对方限制、抓取非公开数据，更不要用爬下来的数据去做骚扰、诈骗、侵权的事。技术本身没有立场，但使用技术的人要有边界。

5.2 Selenium与浏览器自动化的适用场景

Selenium解决的核心问题是：页面由JavaScript动态渲染，requests拿不到数据。它的思路是启动一个浏览器内核，让页面像在真浏览器里一样运行，然后再模拟点击、滚动、输入，拿到最终渲染出来的DOM。

基础用法很直接：

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("--headless") driver = webdriver.Chrome(options=options) try: driver.get("https://example.com") el = WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.CSS_SELECTOR, ".item-title")) ) print(el.text) finally: driver.quit()

这里最需要改掉的习惯是退避式的time.sleep，显式等待才是正确做法。WebDriverWait会轮询页面直到元素出现，设置一个合理的超时时间（比如10秒），元素提前出现就提前执行，比固定睡三秒再查更稳定也更快。

我还要给你一个实用建议：能不开浏览器就不开。Selenium很耗资源，一个Chrome实例少说占几百MB内存，爬几百页就可能拖垮机器。优先用无头模式，用完必须driver.quit()释放进程。另外可以考虑Playwright和Puppeteer，Playwright在异步支持、请求拦截和性能上都比Selenium有优势，如果你已经有一定基础，建议直接看Playwright。

5.3 Robots协议、个人信息与“该不该爬”

Robots协议是网站通过robots.txt声明哪些路径可以爬、哪些路径不能爬的文本文件。从技术上讲它不强制，靠爬虫自觉遵守，但它是一个重要的行业惯例。搜索引擎的爬虫都尊重robots.txt，个人爬虫也应该参考。

比Robots协议更重要的是个人信息和数据合规。爬取公开的商业信息，比如商品价格、电影评分，通常没有问题；但涉及个人手机号、地址、聊天记录、社交媒体私信这类数据，性质就完全不同了。经常有人找我要抖音爬虫、快手爬虫、小红书爬虫的代码，我给出的第一个建议永远是：先确认数据是否公开，再确认抓下来之后能不能发布、能不能商用。

判断“该不该爬”我给自己定了三条标准：数据是否公开？是否涉及个人隐私？访问频率是否影响对方正常服务？三个答案都是“否”的前提下，再去考虑技术方案。合规是底线，技术是能力，底线永远走在能力前面。

6. 从脚本到系统：日志、并发与可视化

6.1 日志、断点续爬与异常兜底

初学者写爬虫，最喜欢用print来观察运行状态。print在控制台看看还行，一旦程序崩掉，翻终端记录翻到怀疑人生。进阶的第一课，就是把print换成logging。

logging的好处是分级、带时间戳、可以输出到文件。配置一次，之后所有模块都能用：

import logging logging.basicConfig( level=logging.INFO, format="%(asctime)s [%(levelname)s] %(name)s: %(message)s", handlers=[logging.FileHandler("crawler.log", encoding="utf-8"), logging.StreamHandler()] ) logger = logging.getLogger("crawler")

断点续爬则是“扛事”的关键。一个爬虫跑到第8000条时报了个异常直接退出，没有断点机制的话，下次只能从第1条重跑。最简单的断点方案是两个：一是把“已抓取的URL”列表定期保存到一个文件或数据库表里，启动时加载；二是给数据表加一个状态字段，每条记录标记pending/done/failed，下次任务只取pending和failed的记录继续处理。

异常兜底的思路是“别让一颗老鼠屎坏了一锅汤”。用try/except包住单条数据的处理逻辑，捕获异常后记录日志并continue，而不是让一条脏数据中断整个任务。跑长任务，这些细节决定成败。

6.2 并发路径：多线程、异步再到分布式

零基础到进阶，最容易在并发上走弯路。我的建议是沿着“单线程→多线程→异步→分布式”这条路一步步走，不要跳级。

单线程跑顺了，加多线程的收益最直接，Python的ThreadPoolExecutor用起来简单，代码改动也很小：

from concurrent.futures import ThreadPoolExecutor def crawl_one(url): # 单条爬取逻辑 pass with ThreadPoolExecutor(max_workers=8) as pool: pool.map(crawl_one, url_list)

这里要注意线程数不是越大越好，要跟数据库连接池、目标网站承受能力匹配。8到16个线程在大多数场景已经足够，再多就容易触发反爬了。

再往上走是asyncio + aiohttp/httpx，用异步IO实现更高并发，适合请求量大、单请求耗时的场景。但异步代码的回调链和事件循环对新手不太友好，建议把多线程用熟了再碰。如果项目规模到了一定程度，才需要考虑分布式爬虫：用Redis或消息队列做任务分发，多台机器跑同一个任务队列，配合数据库统一存储。这个阶段直接用Scrapy框架，它内置了请求调度、去重、中间件机制，比从零搭分布式要稳妥得多。

6.3 可视化与监控：让数据被看见

“Python爬虫可视化界面”也是热词里的常客。爬虫可视化分两种，一种是给开发看的运行监控，一种是给老板/用户看的数据展示。

运行监控的核心指标就三个：请求成功率、最近一小时抓取量、失败任务数。如果你用对了日志和数据库，做一个简单看板并不难，后端用FastAPI或Flask提供数据接口，前端用ECharts画折线图，定时刷新就行。

数据展示则简单得多。爬下来的排行榜、价格数据、舆情数据，用ECharts柱状图、折线图、词云能很直观地呈现。开发Web界面不熟练的话，也可以用Jupyter Notebook + Pandas做快速分析，再导出HTML报告。顺带提一个画图时经常遇到的小问题：横坐标标签太密集，挤成一团。解决办法很简单，要么旋转标签：

import matplotlib.pyplot as plt plt.xticks(rotation=45)

要么每隔几个取一个标签再显示。这种小问题看似琐碎，但你在真实交付时，图表是否清晰直接影响别人对你爬虫成果的信任度。

7. 从学习到接单：路线、避坑与边界问题

7.1 接单的本质是交付稳定性，不是交付requests

“爬虫接单一年收入”这个热词下面，永远有人在问接单能不能赚钱。我的回答一直很直接：能，但前提是你交付的不只是一个“会跑的一次性脚本”。能稳定跑三个月、有日志、有数据库、挂了能重启自愈的爬虫，和那种跑一次就完事的脚本，价格能差十倍。

接单前一定要问清楚四件事：数据来源是否合法、数据量预期有多大、对方是否需要长期运行维护、目标网站有没有官方开放接口。如果对方要做的是爬取某个平台的非公开数据，这个单子不要接。技术上的困难可以克服，法律上的风险没法靠技术解决。

7.2 零基础衔接进阶的路线图

如果让我给一条不带任何商业滤镜的学习路线，大概是这样的：

1. Python基础语法、函数、类、异常处理，环境问题要提前解决掉，Linux下装Python、VS Code配解释器、pip装依赖库，这些看似简单，却能让很多人卡住好几天。
2. requests + BeautifulSoup跑通一个静态页面的完整流程，感受“请求→解析→输出”的基础闭环。
3. 学XPath和lxml，把解析从BeautifulSoup切到高性能方案，同时学会看开发者工具的Network面板找JSON接口。
4. 学SQLAlchemy，把CSV换成数据库，掌握建模、批量写入、去重和增量。
5. 学Session、请求头伪装、频率控制，理解反爬的常见手法和应对思路。
6. 学Selenium或Playwright，处理动态页面，但记住能走接口不走浏览器。
7. 学logging、多线程、断点续爬，让脚本变成系统。
8. 按需学Scrapy、asyncio、分布式，这些是锦上添花，不要本末倒置。

不推荐零基础阶段一上来就学逆向和验证码破解，一个是因为容易走偏，另一个是这些内容对新手来说没有足够的前置知识，学了也是一知半解。

7.3 我踩过的几个坑

最后一个部分，分享几个我真实踩过的坑，每一个都付出了时间成本。

第一个坑是不设timeout。某次爬数据，爬着爬着服务器端卡住了，线程全部阻塞在等待响应上，整个程序像死了一样，半天没有任何输出。后来才发现requests请求没设timeout参数，TCP连接一直挂起。从那以后，我每个请求都带timeout，一个都不例外。

第二个坑是拿print当日志用。任务崩了之后，终端刷新一下就什么线索都没有了。换成logging之后才发现，若干问题其实早就发生了，只是print的内容没保存下来。

第三个坑是单条commit存数据库。第一次用SQLAlchemy时，一千条数据存了大几秒，我以为正常。后来改成批量提交，耗时直接降到零点几秒，当时就意识到“原来不是数据多，是姿势不对”。

第四个坑是写死UA。同一个User-Agent用半年，某天突然所有请求都403了。换了一个UA之后又好了。不要在一个爬虫里永远用同一个UA，准备几个常用浏览器的UA随机切换，能避免很多莫名其妙的封禁。

第五个坑是死磕requests。遇到动态页面，用requests怎么都拿不到数据，硬是分析了一晚上接口，最后还是决定打开Selenium，五分钟搞定。后来又发现Selenium太慢，最终找到了一种更轻量的方案。解决思路是可以演进的，别把一个技术方案用死。

回头看，零基础到进阶真正的分水岭，不是会了多少库，而是能不能快速定位问题是出在请求层、解析层还是存储层，然后对症下药。希望这篇能帮你少走几个我走过的弯路。