为什么Python爬虫抓取的网页源码和浏览器看到的不一样_识别动态渲染与iframe内嵌内容-Python教程-PHP中文网

爬取源码与浏览器看到的不一致，根本原因是requests仅获取服务器返回的原始html，不执行js、不加载iframe、不处理重定向；而浏览器展示的是js渲染、ajax注入、iframe嵌套后的完整dom。

为什么python爬虫抓取的网页源码和浏览器看到的不一样_识别动态渲染与iframe内嵌内容

爬取的源码和浏览器看到的不一样，绝大多数情况不是代码写错了，而是你根本没拿到浏览器最终渲染出来的那个 DOM —— requests 拿的是服务器吐出的原始 HTML 字节流，而浏览器展示的是 JS 执行、AJAX 加载、iframe 注入之后的完整结果。

这不是 bug，是设计如此：requests 不解析 <meta charset>，不执行 JS，不加载 iframe，也不处理重定向后的最终页面。常见表现包括：

实操建议始终优先用 response.content + 显式解码，而不是依赖 response.text：

html_bytes = response.content
encoding = 'utf-8'  # 或用 chardet.detect(html_bytes)['encoding']
html = html_bytes.decode(encoding, errors='replace')

打开浏览器开发者工具 → Network 面板 → 刷新页面 → 点击顶部 HTML 请求 → 查看 Preview / Response 标签页。如果这里看到的结构和 Elements 面板里差很多（比如少了列表、多了 loading 占位符），基本就是 JS 渲染。

再切到 Elements 面板，右键任意目标元素 → “Break on” → “attribute modifications”，刷新看是否触发断点：触发说明 DOM 是 JS 后续改的
禁用 JS 后刷新页面（DevTools → Settings → Debugger → “Disable JavaScript”），如果目标内容消失了，那它必然依赖 JS
检查 Network 中是否有 XHR/Fetch 请求返回 JSON 数据，且这些数据恰好对应页面上动态插入的内容

此时别硬刚 requests，直接抓那个 XHR 的 URL 更快更稳 —— 它通常参数少、响应轻、无渲染开销。

Li Python Sec Check

Python 安全规范检查工具：基于 CloudBase 规范、腾讯安全指南，LLM 智能分析（默认禁用，优先本地执行）

下载

requests 默认只请求你给的那个 URL，不会自动递归请求 <iframe src="..."></iframe> 里的地址。你看到的“完整页面”，其实是多个独立 HTTP 响应拼起来的。

浏览器 Elements 面板里能看到 iframe 子文档的 DOM，但 response.text 里只有那一行 <iframe src="subpage.html"></iframe>
想获取 iframe 内容，得单独发一次 requests.get() 去请求它的 src 属性值（注意处理相对路径、base 标签、cookie 传递）
有些 iframe 的 src 是 JS 动态写的（比如 iframe.src = '/data?token=' + token），这时必须先执行 JS 才能拿到真实地址

这种场景下，Selenium 或 Playwright 不是“重武器”，而是必要工具 —— 它们会自动加载并解析所有 iframe，生成一棵完整的嵌套 DOM 树。