ssr页面可直接用requests抓取，因其完整html由服务器生成并返回，关键数据已包含在响应体中；但需验证status_code为200且content-type为text/html，并警惕混合渲染导致的动态数据缺失。
requests + BeautifulSoup 就够用，不需要启动浏览器。
为什么 SSR 页面可以直接用 requests 抓？
SSR 页面的完整 HTML 是服务器拼好再发给浏览器的，所有关键数据（商品标题、价格、描述）都已存在于响应体中。你用浏览器打开 F12 查看「Elements」标签页看到的内容，和 requests.get(url).text 拿到的字符串基本一致——前提是没被反爬拦截。
- 不需要执行 JavaScript，
document.querySelector或driver.page_source都是多余动作 -
response.status_code == 200是第一道验证，不是 200 就别往下解析了 - 注意检查响应头里的
Content-Type是否为text/html，有些 SSR 站点会把错误页也返回 200，但 body 是 JSON 错误信息
常见误判：以为是 SSR，实际首屏后还有 CSR 补充
很多所谓“SSR 页面”其实是混合渲染——首屏 HTML 有基础字段，但价格、库存、评论数等动态模块仍走 AJAX 加载。这时候只靠 requests 会漏数据。
- 打开浏览器开发者工具 → Network 标签页 → 刷新页面 → 看 XHR/Fetch 请求里有没有带关键字段的接口（比如
/api/product/detail或/v2/sku?skuId=123） - 如果有，说明得补抓接口，而不是硬啃 HTML 里的占位符（如
<div class="price">--</div>） - 接口请求通常带
Referer、X-Requested-With或 token，直接复用requests的 headers 即可，不用重写逻辑
解析时容易踩的坑：HTML 结构不稳，但数据位置稳定
SSR 页面 HTML 可能频繁改 class 名、div 层级、注释占位，但数据本身在 DOM 中的位置往往固定（比如总在第 3 个 meta 标签的 content 属性里，或某个 script 标签内嵌的 JSON）。
- 优先找
meta[name="description"]、script[type="application/ld+json"]这类语义化强、改动少的节点 - 避免依赖
div:nth-child(2) > ul > li:first-child这种纯结构路径，一改就崩 - 如果页面有内联 JSON（常见于 Next.js/Nuxt 的
<strong>NEXT_DATA<strong></strong></strong>或window.INITIAL_STATE），直接用正则或json.loads()提取，比 XPath 可靠得多
SSR 爬取真正的难点不在技术，而在识别“它是不是真的 SSR”——多看 Network 面板，少信页面源码里一眼看到的 HTML。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
