一次 403 之后，我重新理解了网络爬虫
最初写网络爬虫时，我最关心的是页面数量。循环能翻多少页，数据库里能多出多少行，看起来就是最直接的进度。
直到请求突然返回 403，程序停在中间，我才发现自己甚至说不清已经成功了多少、失败发生在哪一页、重新启动后会不会把旧数据再写一遍。
那次经历让我开始把爬虫看成一条数据管道，而不是一段不断发送请求的脚本。
先判断问题发生在哪一层
403 只说明服务器拒绝了当前请求，并不自动给出原因。页面访问频率、登录状态、权限、接口变化和服务规则都可能影响结果。
我不会把“绕过去”当成唯一目标，而会先确认：
- 目标数据是否公开，采集行为是否符合网站规则与使用边界
- 浏览器和程序请求的响应状态、内容类型是否一致
- 问题是持续出现，还是只在特定页面或特定频率下发生
- 页面结构或接口是否已经改变
- 当前任务是否应该降速、暂停或停止
如果数据不适合自动采集，最正确的技术方案就是不采集。合规判断不是写完代码后的附加项，而应该在设计阶段出现。
失败也必须留下记录
早期脚本出错时，我只能看到最后一行异常。现在我会为一次任务记录开始时间、目标范围、当前页、响应状态、重试次数、解析数量和写入数量。
这些日志不需要复杂，但要能回答三个问题：
- 程序最后成功到了哪里
- 失败发生在请求、解析还是存储阶段
- 下一次应该从哪里继续
当错误可以被定位，调试就不再依赖猜测。
重试不是无限重复同一个请求
网络抖动和临时服务异常确实需要重试，但无上限地立即重发，只会让情况更糟。
更稳妥的处理是限制次数，逐步增加等待时间，并区分哪些错误值得重试。对于明确的权限拒绝或结构变化，继续重复通常没有意义，应该记录现场并停止当前任务。
我也会把采集范围拆成更小批次，保存已经完成的进度。这样一次中断不会让整个任务从零开始。
数据写进去之前还要过几道关
抓到内容并不等于得到可用数据。字段缺失、格式变化、重复记录和异常字符都会在后续分析中制造麻烦。
我通常在写入 MySQL 前完成基础校验与规范化，并为记录设计稳定的唯一标识。数据库的唯一约束和更新策略可以成为最后一道防重复保护，而不是把所有希望都放在内存中的一个集合上。
我现在怎样判断一个爬虫是否完成
它不再只是“能抓到数据”。一个相对可靠的采集任务应该知道自己采了什么、漏了什么、在哪里失败，能够在合理范围内恢复，也能解释数据如何进入最终表结构。
Requests、Scrapy 或 Playwright 只是不同工具。真正决定质量的，是任务边界、观察能力、恢复策略、数据约束和对目标站点规则的尊重。
403 没有让我学会一个万能技巧，却让我开始认真对待爬虫中那些不够显眼、但更接近工程的问题。