目录一、拾枝杂谈二、WorkBuddy 写的脚本好奇心很重三、爬虫脚本“如何判断当前是否需要登录”四、为什么加了 DOM 检测就解决了Δ总结一、拾枝杂谈WorkBuddy 的干活能力没有让我失望。我之前让 WorkBuddy 实现一个比较复杂的需求就是分别收集7个平台的文章数据然后写入到飞书表格中方便我进行数据统计。这是一个典型的“多平台内容矩阵——数据采集自动化”项目我和 WorkBuddy 经过多轮探讨和尝试最终敲定了“Playwright 模拟用户登录态和点击行为精简 profile 持久化登陆数据”的方式。但是之所以说它是一个“复杂”的需求我认为原因主要有三点第一每个平台的反爬策略和风控方式都不一样比如 小红书 和 搜狐号对登录状态更加敏感刚开始可能你本地的 Google Chrome 窗口 以及 Playwright 启动的窗口都可以同时登录但是一段时间后你就会发现这两个平台同时只允许登录一个窗口。这个窗口登录就会强制另一个窗口的登出。第二每个平台的后台统计数据不一样比如在 CSDN 中“展现量”是一个很重要的统计指标而在 微信公众号 里面则没有“展现量”的说法反而有“在看”、“转载”这样的特有字段。不同的统计字段意味着爬虫脚本映射字段以及飞书表格的格式都会受到影响。第三飞书表格的字段和格式不统一。我让 WorkBuddy 做的这个需求并不是我一时起意的决定某种程度上说是“被逼无奈”。因为我之前是手动统计的但是当我仅仅统计了两篇文章后我就放弃了“古法统计”。太tm费事儿了我不仅需要手动去7个平台的后台一篇篇文章的查看还需要一篇篇对应到飞书表格。我的飞书表格的格式是这样设置的每个平台对应一个主表每个平台下面的每一篇文章都要单独创建一个新的子表“子结点”进行单独统计。所以当文章越写越多的时候这个工作量可想而知了。但是问题就在于我之前没想到 WorkBuddy 能干成这个事儿所以我自己手动统计的时候采取了“省事儿”办法就是直接自己先写了几个比较常见的统计字段比如“展现量”“阅读量”“点赞量”等等但是这么统计的话每个平台都千篇一律了而且也不符合实际。因此用 WorkBuddy 写入飞书的时候还必须考虑如何解决多平台字段不一致的问题。此外表格单元格的格式也得我来定还得让 WorkBuddy 听懂我的需求比如表头的单元格怎么展现日期格式选哪种。综上这三个主要问题让“WorkBuddy搭建多平台数据矩阵”这件事变得复杂复杂不是因为“困难”而是因为“繁琐”。二、WorkBuddy 写的脚本好奇心很重之前我已经通过 WorkBuddy成功收集了自己在CSDN微信公众号和知乎上的文章的数据并且也成功写入到了飞书表格。于是我开始进行第四个平台“今日头条”的统计。因为 chrome-auto-profile 是复制过来的精简 profile所以每个平台第一次收集数据的时候都需要我先登录一下然后 playwright 再将登陆数据持久化到本地。但是在头条这个平台上出了点幺蛾子。当我正常通过手机验证码登录时发现还没等我来得及输入手机号页面自己就开始划来划去的不知道在找什么然后它还会随便点开一篇首页的臭新闻装模做样的看看然后再关闭窗口。完事儿后还更我来一句“探索结果显示脚本始终停留在今日头条公共首页没有登录进去”。尝试了两三次后都是这样于是乎我忍无可忍告诉 WorkBuddy“你先让脚本不要乱点乱划拉先等我登陆成功再继续操作”。WorkBuddy 听懂了我的话可能它也觉得有点不好意思先是和气地给我解释了一番“之前的脚本逻辑是 打开页面 - 立刻检测登陆状态 - 没检测到登录弹窗就直接往下点。现在的逻辑改了打开页面后如果发现没登陆就先乖乖等待不动任何按钮。其实这里面有一个爬虫脚本“判断页面状态”的细节。非常值得说道。三、爬虫脚本“如何判断当前是否需要登录”当时的场景大概是这样的我打开今日头条首页后页面弹出了一个登录窗口但是脚本没看到它以为“没检测到登陆弹窗”于是它就继续往下执行导航逻辑包括到处点按钮、划页面、甚至点进一篇新闻又关掉直到最后它发现还是没到“创作者后台”于是就报错了。这是因为脚本最初使用的是一种很原始很粗糙的方式检测方式大概长这样page_textawaitpage.content()# 或者 page.inner_text()if登录inpage_text:returnTrue# 认为是登录页这个逻辑很简单就是把整个页面的文字部分拿过来检查比对其中有没有“登录”两个字。但是在头条首页的HTML中到处都可能有“登录”这俩字比如顶部导航栏、页面的底部链接、JavaScript代码里面的字符、甚至是隐藏的div里面。所以这就导致了脚本会陷入一种“二极管”的状态要么是 false positive即只是发现了某处文本中有“登录”二字就误判为“已经弹出了登录框”要么是 false negative即弹窗出来了但是脚本扫描文本时没匹配到正确的关键词就以为没弹误判为“已经登录了”。但是之后 WorkBuddy 给脚本改了逻辑改为了DOM元素检测就是把浏览器解析为一棵DOM树每个HTML标签都是树上的一个节点。DOM元素检测就是不只看文字而是直接查找页面上有没有某个具体的元素节点并且这个节点是可见的。具体来说头条登录弹窗外层的 div 类名大概长这样divclassttp-modal-wrapperstyledisplay:block;divclasslogin-modaldiv扫码登录/divdiv手机登录/div.../div/div所以检测代码就要变成这样const modalsdocument.querySelectorAll(.ttp-modal-wrapper);for(const m of modals){if(m.offsetParent!null)returntrue;//弹窗可见 → 需要登录}其中offsetParent ! null是判断一个元素是否真的显示在页面上不是 display: none 或藏在某个隐藏父元素里。四、为什么加了 DOM 检测就解决了因为脚本的检测逻辑变了从“文字游戏” 变成了 “逮捕特定UI组件”。.ttp-modal-wrapper这个类名是头条的登陆弹窗特有的只有登陆弹窗真正显示出来时这个元素才可见。所以当弹窗没出来的时候找不到这个可见元素脚本会认为已经登陆或者无需登录便不会乱点而当弹窗出来的时候可以找到这个可见元素这时候脚本会乖乖等待我扫码登陆登陆成功后再继续。相关代码是这样的const modalsdocument.querySelectorAll(.ttp-modal-wrapper, .ttp-login-modal, [class*login-modal]);可以说更改后的脚本实际上是同时检查了三种情况1类名完全等于 ttp-modal-wrapper 的元素2类名完全等于 ttp-login-modal 的元素3class 属性里包含 login-modal 这几个字的元素。最后的“[class*“login-modal”]”这玩意儿我们管它叫做属性包含选择器意思是 只要元素的 class 属性里面出现了 “login-modal” 这个子串它就匹配。这样的话就提高了检测的容错率。Δ总结OK以上就是本篇文章的全部内容了感谢阅读。这篇文章主要和大家分享了一个 up 在通过 WorkBuddy 操作头条时遇到的一个有趣的事情脚本不听使唤左滑右划的经过排查才发现时之前写的脚本偷懒了用了原始检测方式后面改成 DOM检测就好多了。关注迅高AI实验室学习AI不迷路