网络爬虫的基本流程包括

写爬虫最怕一上来就写代码。网络我见过太多人打开编辑器就敲 requests.get()，爬虫结果跑两天被封了 IP，本流回头改代码的程包时间比重新写还长。真正跑得稳的网络爬虫，前期设计占七成，爬虫写代码只占三成。本流

先说目标拆解。程包你想抓一个电商网站的网络商品价格，这事听起来简单——打开列表页，爬虫翻页，本流进详情页，程包提取数字。网络但实际动手前得先回答几个问题：列表页是爬虫静态 HTML 还是 JS 渲染的？详情页的价格是不是异步加载的？翻页是 URL 参数控制还是滚动触发？这几个问题的答案直接决定你用什么工具。静态页面用 requests + BeautifulSoup 就够了，本流JS 渲染的得上 Playwright 或 Selenium。我一般先打开浏览器开发者工具，切到 Network 面板，刷新页面，看 XHR 请求里有没有直接返回 JSON 数据的接口。有的话，直接请求接口，比解析 HTML 省一半工作量。

确定数据来源之后，下一步是 URL 管理。别小看这件事。一个商品列表有 200 页，每页 40 个商品，加上详情页就是 8000 个 URL。你得有个地方存这些 URL 和它们的状态——待抓取、抓取中、已完成、失败。最简单的做法是用 Redis 的 set 或者 MySQL 表。我习惯用 SQLite，轻量，不用额外起服务，本地跑完全够用。每条记录包含 URL、状态、重试次数、上次抓取时间。这样爬虫中断了也能续上，不会从头再来。

请求环节是踩坑最多的地方。请求头里的 User-Agent 别用默认的 python-requests，换成真实浏览器的。Referer 有时候也查，尤其是详情页，带上列表页的 URL 能降低被拦截的概率。频率控制比你想的重要——我试过同一个站点，每秒 5 个请求跑 10 分钟没事，每秒 20 个请求 30 秒后直接 403。后来改成随机间隔 1 到 3 秒，稳定跑了一周。代理 IP 看情况，小规模抓取用不上，日请求量过万就得考虑代理池了。

拿到响应之后是解析。HTML 解析用 CSS 选择器比 XPath 写起来快，但 XPath 在处理复杂层级时更灵活。有个细节：很多网站会把价格拆成多个 span，比如 <span>¥</span><span>299</span><span>.00</span>，你得把它们拼起来。还有的用 CSS 伪元素或者 background-image 显示数字，这种就得截图做 OCR 了，成本高很多，能绕就绕。

数据存储别直接写 CSV。字段一多，编码问题、换行符问题全来了。用 SQLite 或者 PostgreSQL 建张表，字段类型定好，后面清洗和分析都方便。我一般还会存一份原始 HTML 到本地磁盘，按 URL 的 hash 做文件名。万一解析规则写错了，不用重新请求，直接读本地文件重跑解析就行。

最后是监控和重试。爬虫跑起来之后，你得知道它是不是还活着。简单做法是每抓 100 条打印一次进度，复杂点就接个 Telegram 或者钉钉机器人，失败率超过阈值就告警。重试策略用指数退避——第一次等 1 秒，第二次 2 秒，第三次 4 秒，最多重试 3 次。超过就标记为失败，人工介入看是规则问题还是反爬升级了。

整个流程走下来，代码量其实不大，大部分时间花在调试选择器、处理边界情况和应对反爬策略上。我自己的经验是，写爬虫之前先手动抓 20 条数据，把每个环节的坑都踩一遍，再动手写自动化代码，效率反而更高。