爬取源码与浏览器看到的不一致，根本原因是requests仅获取服务器返回的原始HTML，不执行JS、不加载iframe、不处理重定向；而浏览器展示的是JS渲染、AJAX注入、iframe嵌套后的完整DOM。
爬取的源码和浏览器看到的不一样，绝大多数情况不是代码写错了，而是你根本没拿到浏览器最终渲染出来的那个 DOM —— requests 拿的是服务器吐出的原始 HTML 字节流，而浏览器展示的是 JS 执行、AJAX 加载、iframe 注入之后的完整结果。
为什么 response.text 和浏览器“查看网页源代码”都对不上？
这不是 bug，是设计如此：requests 不解析 <meta charset>，不执行 JS，不加载 iframe，也不处理重定向后的最终页面。常见表现包括：
- 目标元素在
response.text里完全不存在，但在浏览器 Elements 面板里清清楚楚 - 页面有 “加载中…” 文字，但爬虫拿到的就是这行文字，没后续数据
-
response.url和你请求的 URL 不一致（发生了 302），但你没察觉 - 中文乱码：服务器响应头没声明编码，
response.text错误地用 ISO-8859-1 解了 UTF-8 字节
实操建议始终优先用 response.content + 显式解码，而不是依赖 response.text：
html_bytes = response.content encoding = 'utf-8' # 或用 chardet.detect(html_bytes)['encoding'] html = html_bytes.decode(encoding, errors='replace')
怎么确认内容是不是由 JavaScript 动态渲染的？
打开浏览器开发者工具 → Network 面板 → 刷新页面 → 点击顶部 HTML 请求 → 查看 Preview / Response 标签页。如果这里看到的结构和 Elements 面板里差很多（比如少了列表、多了 loading 占位符），基本就是 JS 渲染。
立即学习“Python免费学习笔记（深入）”；
- 再切到 Elements 面板，右键任意目标元素 → “Break on” → “attribute modifications”，刷新看是否触发断点：触发说明 DOM 是 JS 后续改的
- 禁用 JS 后刷新页面（DevTools → Settings → Debugger → “Disable JavaScript”），如果目标内容消失了，那它必然依赖 JS
- 检查 Network 中是否有 XHR/Fetch 请求返回 JSON 数据，且这些数据恰好对应页面上动态插入的内容
此时别硬刚 requests，直接抓那个 XHR 的 URL 更快更稳 —— 它通常参数少、响应轻、无渲染开销。
iframe 内容为什么总被漏掉？
requests 默认只请求你给的那个 URL，不会自动递归请求 <iframe src="..."> 里的地址。你看到的“完整页面”，其实是多个独立 HTTP 响应拼起来的。
- 浏览器 Elements 面板里能看到 iframe 子文档的 DOM，但
response.text里只有那一行<iframe src="subpage.html"> - 想获取 iframe 内容，得单独发一次
requests.get()去请求它的src属性值（注意处理相对路径、base 标签、cookie 传递） - 有些 iframe 的
src是 JS 动态写的（比如iframe.src = '/data?token=' + token），这时必须先执行 JS 才能拿到真实地址
这种场景下，Selenium 或 Playwright 不是“重武器”，而是必要工具 —— 它们会自动加载并解析所有 iframe，生成一棵完整的嵌套 DOM 树。
比对时最容易忽略的细节
就算你拿到了“看起来一样”的两个 HTML 字符串，哈希值也可能不同。不是因为内容不对，而是因为：
- 服务器每次返回的时间戳、随机 token、埋点 script 标签位置不同
- 浏览器保存的“网页源代码”可能已自动格式化/补全标签，而
requests拿到的是压缩原始流 - 空格、换行、制表符在 HTML 中无语义，但会影响字符串哈希
- 注释、
<script>、<style>标签顺序或内容微调（如 sourcemap URL 变了）也会导致差异
真正有效的比对，不是比整个字符串，而是提取关键节点文本（比如用 BeautifulSoup.select('h1.title') 拿标题）或计算 DOM 结构指纹（如子元素数量、class 名集合），再对比这些稳定特征。
