从Demo到生产，多平台自动化系统稳定运行的核心挑战与解决方案

做过自动化项目的人都知道，Demo跑通和生产环境稳定运行之间，隔着一条巨大的鸿沟。

最近复盘了一个多平台RPA项目，整理出5个最致命的坑，每个都是真金白银买来的教训。

1. 反检测：别用自带浏览器内核

Playwright自带的Chromium特征太明显，主流平台的反爬系统秒识别。解法是连接本机安装的Chrome，通过CDP协议控制，配合独立Profile隔离会话。

关键参数：

• --disable-blink-features=AutomationControlled
• 通过CDP debug端口连接，而不是Playwright默认启动方式
• 每个平台独立Profile目录

这一步做对，反检测成功率直接从40%拉到95%以上。

2. Shadow DOM穿透：表单可能藏了10层

越来越多平台把关键表单放进Web Components的Shadow DOM里，page.locator()、page.query_selector() 在Shadow边界外完全失效。

我的方案：写JS递归遍历shadowRoot，按placeholder文本匹配输入框，不依赖随时可能变的CSS类名。递归深度上限设10层，覆盖目前遇到的所有场景。

这个方案的核心优势：对UI结构变化有很强的容错性。只要placeholder文案不变，表单怎么嵌套都能找到。

3. 验证码处理：不要硬解，做人机协作

滑块验证码自动识别率不稳定，强行破解反而触发更严格的风控。更聪明的做法：

1. 注入MutationObserver实时监听DOM变化
2. 检测到验证码关键词（滑块、安全验证等）立即触发告警
3. 钉钉机器人秒级推送，支持@指定人
4. 人工在浏览器窗口完成验证（30秒）
5. 系统检测验证码消失，自动恢复执行

这种"人机协作"模式比硬解验证码靠谱得多。同样的思路在AI Agent系统里也适用：让机器做擅长的重复工作，需要判断的交给人。

4. 多账号Session串台：Cookie是隐形炸弹

共享浏览器实例处理多账号任务时，上一个账号的Cookie会"污染"下一个任务，导致操作到错误账号上。

方案：

• 每个平台独立浏览器Profile目录
• 任务开始前读取Cookie中的账号标识字段
• 当前登录账号与目标账号不匹配 -> 强制登出再登录
• 不依赖"上一次登录成功"的缓存假设

5. Chrome僵尸进程会拖垮整台机器

Chrome超过120秒无页面交互，大概率已经挂死。不主动清理的后果：内存持续增长直到机器卡死。

进程守护方案：

• Watchdog线程定时检测Chrome活跃度
• 超时强制kill进程
• 主进程崩溃自动重启，带指数退避（避免秒崩秒启的死循环）
• 连续5次快速崩溃（<30秒）触发停机告警

总结

RPA最大的敌人不是技术难度，是平台UI的随时变化。

这5个问题的共同特点是：开发环境很难复现，只有在生产环境大规模运行时才会暴露。所以一定要有完善的日志、告警和自愈机制。

这些经验对做爬虫、做自动化测试、做AI Agent的同学都有参考价值。