大规模浏览器自动化而不被封锁
为什么初期有效，后来却失效
基本的 Playwright 脚本在隔离测试中运行良好，但一旦针对实际生产网站运行，就会遇到越来越复杂的检测系统。最初的封锁通常来自用户代理指纹识别，随后是行为分析，最终是基础设施级别的 IP 信誉检查。
浏览器指纹
标准 Playwright 浏览器实例暴露了多个自动化标志：navigator.webdriver 属性、缺少插件、一致的屏幕分辨率，以及 TLS 握手中可识别的模式。
Playwright 的 chromium 配置需要额外配置才能匹配真实浏览器指纹。使用 playwright-extra 和 puppeteer-extra-plugin-stealth可以处理大多数常见的指纹检查。
行为模式
反自动化系统分析的不仅仅是浏览器属性——它们还分析行为：点击速度、鼠标移动轨迹、滚动模式，以及表单填写时间。
可靠的模式是添加随机延迟和模拟人类鼠标运动。关键是变异性：相同的延迟每次都相同，而有变化的延迟则更接近真实的人类行为。
IP 轮换和代理
基础设施级别的封锁需要基础设施级别的解决方案。住宅代理网络提供来自真实住宅互联网连接的 IP 地址，这使得基于 IP 信誉的封锁变得更加困难。
轮换策略很重要：每个会话使用不同的 IP，避免在同一地理位置快速连续请求，以及在代理之间按比例分配请求。
优雅地处理封锁
有些封锁是不可避免的。系统需要能够检测 CAPTCHA 出现的时机，对明显被封锁的请求进行指数退避，以及在重试之前切换代理。
每次失败都应该记录到日志——不仅是错误本身，还有失败前的完整请求上下文。这使得调试间歇性封锁成为可能，而不仅仅是重启任务。
可持续的运营
大规模浏览器自动化需要从战术性工具转变为运营基础设施的思维方式。这意味着监控成功率趋势，在检测模式演变时主动调整方法，以及为封锁期间的人工干预维护后备流程。