iframe的src属性只能发起get请求，不能直接执行post请求；它加载的是目标url返回的html内容，而post行为需由该页面内的表单或脚本触发。
iframe src 属性是否可直接请求？
不能一概而论。只有当 src 指向的是一个真实、可公开访问的 HTML 文件 URL，且该 URL 不依赖父页面 Cookie/Referer/Token 等上下文时，requests.get() 才可能拿到有效 HTML。多数现代网站的 iframe src 是动态生成的（如带临时 token 的地址），或指向一个仅响应给特定 Referer 的接口，直接请求会返回 403、空页或重定向到登录页。
常见错误现象：response.text 是空白、、或返回一段 JS 跳转代码。
- 先用浏览器开发者工具 Network 面板确认该 iframe 请求的完整 headers（尤其是
Referer、Cookie、X-Requested-With） - 对比
requests发出的请求与浏览器实际发出的请求，缺失任意一项关键 header 都可能导致失败 - 若
src是相对路径（如./detail.html），需手动拼接为绝对 URL：用urljoin(主页面URL, iframe_src)
代理后 iframe 内容仍是空的？检查同源策略与 X-Frame-Options
即使你成功请求到了 iframe 的 HTML，也可能在本地解析时发现 DOM 结构异常简单——这不是爬虫问题，而是目标站点主动防御。两个关键 HTTP 响应头会直接干预 iframe 渲染行为：
-
X-Frame-Options: DENY或SAMEORIGIN：服务端禁止被嵌入，浏览器会拒绝加载 iframe 内容（Network 中能看到请求，但 Elements 面板里 iframe 是空的） -
Content-Security-Policy: frame-ancestors 'none'：更现代的替代方案，效果同上
此时 requests 仍能获取到原始 HTML（因为它是服务端响应，不受浏览器策略限制），但你拿到的“底层文档结构”其实是服务端返回的、未被浏览器执行任何框架拦截逻辑前的原始内容。换句话说：代理本身不绕过这些头，但 requests 不受其约束——它看到的就是服务器给的“真实底层 HTML”，哪怕浏览器选择不渲染它。
如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更
多层嵌套 iframe 怎么递归提取？别硬写正则
用 BeautifulSoup 解析主页面时，<iframe></iframe> 标签只是个容器，它的 src 属性值才是下一层入口。递归的关键是：每层都当作独立页面处理，而不是试图在父页面 DOM 中“读取子 iframe 的 document”。
- 不要用
re.findall(r'src="([^"]+)"', html)提取 iframe 地址——容易匹配到 script、img、a 标签里的 src - 正确做法：用
soup.find_all('iframe', src=True)，再对每个iframe['src']做urljoin()和去重 - 设置递归深度限制（比如最多 3 层），避免陷入无限嵌套或广告联盟跳转链
- 每层请求都复用同一 session，保留 Cookie 上下文，否则跨层登录态会丢失
为什么 Selenium 获取的 iframe 内容和 requests 不一样？
根本区别不在工具，而在执行环境：requests 拿到的是服务端返回的原始 HTML 字符串；Selenium 拿到的是浏览器渲染引擎执行 JS 后生成的最终 DOM（含动态插入的 iframe、AJAX 加载的内容、前端路由切换后的视图）。两者“底层 HTML 文档结构”的定义不同。
典型场景：
- 页面初始 HTML 里没有
<iframe></iframe>标签，JS 运行后才动态插入（document.createElement('iframe')）→requests看不到，Selenium能看到 - iframe
src是一个 JSON 接口（src="/api/data?_t=123"），返回纯数据而非 HTML →requests得到 JSON，Selenium可能因前端 JS 处理逻辑而渲染出完整表格 - 某些 iframe 内容由 WebSocket 或长轮询更新 →
requests只能捕获快照，Selenium可等待并截取变化后状态
真正需要“代理后的真实底层 HTML”，优先用 requests + 手动构造请求；若目标本质是“用户看到的最终结构”，那就得切到 Selenium 或 Playwright，并明确接受它带来的性能开销和稳定性代价。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
