网站抓取测试
上周三凌晨两点，网站我盯着屏幕上滚动的测试日志，发现目标网站返回的网站HTML里多了一段\
很多人以为抓取测试就是测试写个循环，把URL丢进去，网站等结果出来。测试实际跑一遍就知道，网站第一个请求可能就卡住。测试我习惯先用curl -I看看响应头，网站Server字段是测试nginx还是cloudflare，有没有Set-Cookie。网站有一次碰到个站点，HEAD请求返回200，GET却返回403，原因在于它检查了User-Agent和Accept-Language的组合。这种细节不亲手测根本发现不了。
测试的第一步永远是确认目标是否允许抓取。robots.txt不是法律，但它是底线。我见过有人无视Disallow规则，结果IP段被整段封禁。更隐蔽的是，有些网站故意在robots.txt里写个假的Sitemap路径，专门用来标记不守规矩的爬虫。我的做法是：先读robots.txt，再手动访问几个页面，看返回的HTML里有没有蜜罐链接——那些display:none的\
接着是频率控制。我写过一个测试脚本，每秒钟发10个请求，持续30秒。前5秒一切正常，第6秒开始出现429状态码，第12秒直接连接超时。把间隔调到2秒后，稳定跑了200个请求没出问题。但别高兴太早，有些网站用的是滑动窗口限流，你前面慢后面快照样触发。我的经验是：随机化间隔，比如1.5到3.5秒之间取随机值，比固定间隔更难被识别。
解析环节最容易翻车。用BeautifulSoup抓一个电商列表页，价格字段明明在HTML里是\¥99\，解析出来却是空字符串。查了半天，发现页面加载后JS把价格改成了“登录后可见”。这种动态渲染的坑，要么上Selenium，要么直接找XHR接口。我偏好后者——打开开发者工具的Network面板，筛选XHR，刷新页面，往往能找到一个返回JSON的API，比解析HTML干净十倍。
测试过程中还要留意编码问题。有次抓一个中文站点，requests自动检测成ISO-8859-1，结果所有汉字变成乱码。手动指定response.encoding = 'utf-8'才正常。更离谱的是，同一个站点不同页面的编码居然不一样，列表页是utf-8，详情页是gbk。所以我现在养成了习惯：每个响应都打印前200个字节的十六进制，肉眼确认编码。
最后说个反直觉的观察。很多人花大力气绕过反爬，却忽略了缓存。我测试过一个新闻站，同一个URL在10分钟内返回的内容完全一样，连时间戳都没变。这意味着你根本不需要高频抓取，每10分钟拉一次就够了。先测缓存策略，再决定抓取频率，能省下大量被封的风险。
抓取测试的终点不是“跑通了”，而是“跑稳了”。跑通可能只要半小时，跑稳需要反复调整参数、监控日志、处理异常。我现在的测试清单里至少有15项检查：状态码分布、响应时间百分位、重试次数、代理池健康度、解析成功率、字段缺失率……每一项都可能成为压垮爬虫的最后一根稻草。别信那些“三行代码搞定抓取”的教程，真实世界里的网站，每一行HTML都在跟你作对。