动态渲染识别：浏览器渲染与 JS 数据
前置知识
本文基于模型知识整理，建议核对官方文档（见 参考资料）。
一句话定义
动态渲染指数据由前端 JavaScript 异步请求并写入 DOM，源码里只有壳；正确识别它决定了你走接口路线还是浏览器路线。
为什么重要
对动态站点沿用静态解析会得到「空数据但不报错」的假成功——这是新手最隐蔽的坑。渲染识别是 kp-009（接口抽取）、kp-013（浏览器自动化）之间的路由器：先判型，再选路。
前置知识
kp-002、kp-003。
核心概念
- CSR（客户端渲染）：服务器返回 HTML 壳 + JS 脚本，数据由 JS 在浏览器内请求后注入。
- SSR（服务端渲染）：数据已在 HTML 里，静态路线可用。
- 水合数据：部分站点把初始数据以 JSON 形式嵌在页面里（如
window.__INITIAL_STATE__={...}），可直接提取。 - 渲染流水线：解析 HTML → 构建 DOM/CSSOM → 执行 JS → 异步请求 → 更新 DOM。
原理与机制
三分判别决策树（每遇到新站点先走一遍）：
Ctrl+U 查看源码, 搜索目标关键字
├── 搜得到 → SSR: 走 kp-007 静态解析
├── 搜不到, 但源码里有 window.__XXX__ = {大段JSON} → 抽水合数据(正则/JSON提取), 仍是静态路线
└── 都没有 → CSR: Network 抓接口( kp-009/kp-014 )
├── 接口可直连复刻 → 接口路线(首选)
└── 参数加密/强风控 → 浏览器自动化( kp-013 )原理上，DevTools 的 Elements 面板展示的是 JS 执行后的 DOM，而 Ctrl+U 查看的是 服务器返回的原始 HTML——两者之差就是前端渲染的部分。这是判别的物理基础。
实例或案例
用 httpbin.org/html（SSR）与任意 SPA 站点做对照实验：前者源码即内容；后者源码只有一个 <div id="app"> 加若干 <script>。在练习站 quotes.toscrape.com/js 版本上验证：页面源码搜不到引言文本，但 Network 里有一条返回 JSON 数组的 XHR——走 kp-009 直接请求即可，无需浏览器。
常见误区
- 误区一：DevTools 看得到就认为源码有。 Elements ≠ 源码；判别必须用 Ctrl+U 的原始 HTML。
- 误区二：见 CSR 就上 Playwright。 渲染只是数据的搬运工，接口往往可以直连；浏览器是最后选项而非默认选项。
- 误区三：忽略水合数据。
__INITIAL_STATE__里的 JSON 常包含首屏全部数据，正则截取后json.loads一次搞定，成本远低于任何自动化。
自测题
- 为什么 Elements 面板内容不能作为「源码有此数据」的证据？
答：Elements 是实时 DOM（JS 执行后），源码才是服务器响应原文；判别渲染必须看源码。
- 什么是水合数据？怎么利用？
答：站点把初始状态 JSON 嵌在 HTML 的 script 变量里；正则/字符串定位后 json.loads 提取，免去渲染与接口分析。
- CSR 站点的两条处理路线及优先级？
答：先抓包找可直连接口（kp-009/014），失败再上浏览器自动化（kp-013）。
与其他知识点的关系
kp-009/kp-014 承接接口路线；kp-013 承接渲染路线；kp-016 中许多「抓不到数据」的误判其实源于没做本篇的判型。
延伸阅读
MDN「Client-side rendering」相关概念页；web.dev 的渲染性能科普。