真 Chrome + CDP 做网页自动化的七个坑

做网页自动化时间久了，踩过的坑基本都集中在同一件事上：页面不按你想象的方式渲染。下面记录七个最高频的，附规避思路。

一、别用 launch()，用 CDP 接管真 Chrome
launch() 每次都起一个全新 profile：没有 Cookie、没有 localStorage、没有登录态，还带自动化标记，站点很容易识别。正确做法是用远程调试端口起一个持久化 profile 的 Chrome，再接管它。环境越接近真人，脚本越稳。

二、遮罩层是点击失败的头号原因
点不动不一定是选择器错。新手引导弹窗、客服浮窗、Cookie 提示条都会盖住按钮，可点击性检查直接超时。先截一张全屏图看有没有半透明遮罩，再去怀疑定位。

三、0 乘 0 的蜜罐输入框
登录表单常藏一个宽高为零或不可见的密码框，专门钓脚本。按位置取第一个很可能命中它，填完校验失败，日志里只有「账号或密码错误」。按可见性过滤，或用表单自身语义类名定位。

四、iframe 里的元素
在线 IDE、在线文档、支付页普遍用 iframe 嵌套，主文档里找不到里面的输入，要先遍历 frame，按 URL 特征挑出目标再操作。跨域 iframe 拿不到 DOM，只能走它自己的接口。

五、networkidle 是个陷阱
带长轮询、WebSocket、埋点心跳的站点永远等不到 networkidle。用 domcontentloaded 加短暂固定等待，再对关键元素做有上限的轮询，比死等网络空闲可靠得多。

六、登录态靠 profile 复用
profile 目录在，第二天连上去就是登录态，不必重跑登录流程。但容器重建或出口 IP 变化时平台会作废旧会话，重登一次即可，不等于账号出问题。

七、验证码的边界
滑块、点选、游戏类验证码本质是风控判定。更该做的是降低触发概率：控制操作节奏、稳定出口 IP、一个环境只跑一个账号。绕过属于合规红线，不建议碰。

小结
脚本稳不稳，八成取决于对页面真实形态的观察，而不是 API 写得多花。遇到失败先截图，看清页面到底长什么样，比改十行选择器有效得多。