发布于2026-07-09 阅读(0)
扫一扫,手机访问
你在用 XPath 提取链接时,有没有踩过这样的坑:打开开发者工具,明明看到 href 里藏着 mediaid 参数,信心满满写了个 //a[contains(@href, "mediaid")],结果一跑,啥也没抓到——甚至怀疑自己写的 XPath 是不是有语法问题。
先别急着改表达式。问题很可能出在一个被很多人忽略的环节上:浏览器开发者工具里展示的,是经过 Ja vaScript 渲染后的 DOM 结构,而爬虫直接拿到的,却是服务器返回的原始 HTML。这两者,有时候完全是两回事。
就拿这个例子来说,用户在开发者工具里看到的结构是下面这样的:
25746 Skini titl
乍一看,href 里确实带着 mediaid。但当你用 requests.get() 去抓取时,实际拿到的原始 HTML 却是:
Skini titl
看到了吧?mediaid 压根就不在服务端的响应里。要么是前端 JS 动态注入的,要么是页面加载后改写过的。这种情况下,contains(@href, "mediaid") 怎么可能命中?
所以正确的思路是什么?放弃对动态参数的执念,把精力放在页面结构上。观察真实源码会发现,所有目标链接都藏在 于是解决方案就变得简单直接: 这个表达式的意思是:选择所有 当然,有几个细节值得留意: 说到底,XPath 的可靠性不取决于表达式写得有多花哨,而取决于你对服务端返回的原始 HTML 结构理解得有多深。当参数化的 URL 不在源码层面出现时,回归结构、回归语义,往往比追着动态内容跑要高效得多。 售后无忧 office旗舰店 售后无忧 office旗舰店 售后无忧 office旗舰店 售后无忧 office旗舰店class="download" 的 //div[@class="download"]/a
class 属性精确等于 "download" 的
class="download" 的容器干扰。如果有,就得加更多上下文来缩小范围。response.text 来判断——也就是爬虫拿到的原始字符串,而不是浏览器渲染后的界面。requests 较劲了,直接上 Playwright 或 Selenium,拿到最终渲染结果再提取。
免责声明:正软商城发布此文仅为传递信息,不代表正软商城认同其观点或证实其描述。
产品推荐
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
7
8