网页自动化难点梳理：哪些步骤能自动，哪些必须换工具

做网页自动化的人常有一种乐观：只要把步骤拆得够细，就没有不能自动化的流程。

真跑一遍完整流程就会发现，前面顺得出奇，最后停在一道过不去的墙上。一次账号注册流程的实测结果很典型：填表、选日期、收验证码、过安全检查全都跑通了，整体不到一分钟跑完，自动化率大概 85%，剩下的是必须对着摄像头做的视频自拍验证。

把这条流程按成本拆开看，边界其实比想象中清楚。

单页上的确定性操作，脚本基本不会失手

姓名、邮箱、密码、生日这类输入，是最稳的一层。模拟键盘输入，每个字段留一点间隔，整步耗时五秒左右。

这里唯一的坑是元素定位。不少现代前端写出来的输入框没有语义化的 name，只能用索引或者结构去拿。写法不优雅，但在自动化场景里反而稳。

这就是第一类任务的样子：页面结构固定、动作明确、结果可预期。凡是落在这个范围内的操作，脚本成功率都很高。

一到自定义组件，成本就从页面结构里冒出来

真正花时间的是生日、性别这类下拉选择。

页面看起来是个选择菜单，底层却是一个带无障碍角色的自定义组件。常规办法一一失效：标准的下拉选择方法不行，按无障碍标签定位不行，直接点目标元素也不行。能稳定跑的只有一种，完整复现真人的操作顺序，点开下拉，等选项渲染出来，按文本找到目标项，再点它。

代码十几秒就写完了，调试可能花几小时。这一层的边界不在你的技术水平，而在页面结构愿不愿意配合。遇到自定义组件，最省时间的做法是直接放弃常规方法。

跨站保持状态，是成本开始明显上升的地方

验证码发到邮箱这一步，逻辑本身很简单：打开邮箱、找到最新一封、提取数字验证码、回填。整步 20 秒左右。

坑也不复杂，但一定会踩：脚本读到了旧邮件，验证码就是错的，必须按时间取最新一封。

通过之后，很多平台还会跳到一个额外的检查页，再发一次新码。处理逻辑可以复用，值不能复用上一步的。

真正麻烦的是这中间有两个站点、两套会话。邮箱的登录态要维持，平台的会话要跨步骤保留，代理 IP、时区、语言还得跟环境对得上。跨站状态保持的成本就是这么一点点堆起来的。单看每一步都不难，串起来之后失败率明显上升。

脚本在这里只是执行者，它决定不了自己以什么身份出现在网站上。设备指纹、IP 与环境是否匹配，才是平台判断的依据。这也是跑多账号的团队通常会把环境隔离单独做一层的原因：每个环境一套独立的指纹和 IP，像 PurpleMark 这类工具提供的就是这部分能力，而脚本只负责在里面执行动作。

需要看懂页面的活，纯脚本只能靠分支硬撑

再往后走，问题的性质就变了。

当页面文案、结构会随账号、地区或者灰度实验变化，写死的选择器会一批一批失效。这时候有两条路：要么把所有可能的分支都堆进代码，越堆越难维护；要么把这一步交给能理解页面语义的模型来判断。页面上的一句提示、一个按钮的含义，对人来说是常识，对选择器来说是噪音。

平台在主动对抗，纯脚本会一次次重新失效

还有一种成本容易被忽略：对手是会动的。

平台看的从来不是你会不会填表，而是设备指纹是否正常、IP 与设备环境是否对得上、行为像不像真人、有没有批量操作的痕迹。风控升级一次，昨天还能跑的选择器和行为特征可能就要重写。

这意味着纯脚本方案不会有完工的那一天。它不是一次性交付的工程，而是需要持续跟进的维护工作。

人脸验证这类环节，不是技术问题

流程的最后一关是需要真人面对摄像头完成的验证，整个自动化就停在这里。

脚本能填表、能点按钮、能读邮件、能输验证码，但需要生物特征参与的动作做不了。原因不是技术不够好，而是这道验证存在的目的就是确认屏幕前坐着一个真人，它和自动化的目标直接对立。任何声称能自动通过人脸验证的方案，通常涉及伪造生物特征信息，属于违规甚至违法，风险远大于收益。

即使某个环节技术上做得到，也要看平台的用户协议允不允许。多数平台对自动化注册类行为有明确限制，这是规则层面的约束，和技术能力无关。

结论是分层选工具，不是追求全自动

把这条流程按层过一遍，选择就很清楚：

• 页面固定、动作确定的事交给脚本，成本最低也最稳。
• 需要跨站维持登录态和会话的，先把浏览器环境这一层单独管起来，别把它和环境问题混在一起排查。
• 页面结构没写死、要靠理解语义判断的，交给模型，比在代码里堆分支划算。
• 需要真人参与或者用户协议明确禁止的，不要硬做端到端自动化。

先手动走一遍完整流程，确认有没有过不去的环节，再决定投入多少开发。自动化真正划算的地方，是那些重复、确定、不需要判断的操作。