用 Browser MCP 驱动真实 Chrome 做网页任务自动化的四个坑

背景

最近在把一批重复的网页任务自动化：签到、浏览详情页、给开源仓库点星标、进入云端 IDE 停留一段时间。这类任务的完成态几乎都只体现在前端——按钮从「去完成」变成「已完成」，星标从 Star 变成 Starred。直接用 HTTP 请求打接口既还原不出真实行为，也更容易触发风控。所以我选了更笨但更稳的办法：用 Browser MCP 接管一个已经登录的 Chrome profile，按人的节奏点击、滚动、停留。过程中踩到的几个坑，记下来给后面复用。

坑一：命令作用在活动页签上，不是你以为的那个

打开新页签后，大部分命令默认作用在当前活动页签。批量执行时，只要中间有一次跳转、一次弹窗，焦点就换了，后面的读取会悄悄读到另一个页面，于是出现「明明点了却没反应」的错觉。我的做法很土：每开一个新页签，显式选中它，再读一次 URL 确认，然后才继续。多这一行，省掉大量误判。

坑二：单页应用的 hash 路由会吃掉 goto

实践中心是 #/practice-tasks 这种单页应用。直接 goto 到某个详情地址，会被前端路由接管，页面停在原地好像没动。正确方式是在列表里用选择器点真实链接，让应用自己完成跳转，新开的页签里才是真正的详情页。之后停留计时、滚动这些动作都要在那个详情页上做，才算数。

坑三：云 IDE 藏在跨域 iframe 里

开发者空间的 IDE 主体是一个跨域 iframe，主页面的 innerText 只有几十个字符，看起来像加载失败。实际上容器早就起来了。判断环境是否真的活着，我改成读 iframe 的 src 和页头的剩余时长，比读正文可靠得多。停留计时也只要保持在这个页面上就行。

坑四：星标按钮的点击目标在外层

代码托管站的星标按钮经常被图标覆盖，点最内层的文字元素会落空。往上找三到四层父元素，命中 button 或者 role=button 再点，成功率立刻上来。点击之后不要相信当前页面的瞬时变化，刷新一次再读按钮文案，确认已经变成 Starred。这一步顺带避免了另一个事故：对已经加过星的仓库再点一次，会把星取消掉。

确认操作生效的三个层次

• 页面状态：刷新后重新读取按钮文案，而不是只看点击瞬间的提示。
• 总量变化：回到状态页读总值，看差值是否等于任务面额。
• 会话状态：社区站点和主站往往是两套会话，页头出现「登录」就说明这一侧的登录态已经过期，此时继续操作只会白做。

小结

真实浏览器自动化的成本主要在等待和校验，而不是点击本身。给每个动作配一个可观测的确认点，比堆更多重试有用得多。还有一个体会：跨站点同步的任务经常出现「操作成功但状态不动」的情况，这类问题不是脚本能解决的，如实记录下来交给平台侧，比反复重试更划算。