页面内容未在初始HTML中是因采用WebSocket等异步加载机制：requests仅获静态HTML，需通过Network面板筛选ws协议确认连接，或抓取XHR接口获取真实数据。
页面内容根本没在初始HTML里，不是解析问题，是数据加载方式变了
用浏览器开发者工具确认是否走WebSocket
打开 Chrome 或 Edge，按 F12 → 切到 Network 标签页 → 刷新页面 → 在筛选栏输入 ws 或 websocket → 看是否有连接建立（状态为 101 Switching Protocols）
- 如果看到
ws://或wss://开头的连接，并且后续有Message标签显示来回传输的 JSON 数据，基本可断定核心数据走 WebSocket - 此时右键该连接 →
Copy→Copy as fetch无法直接复用，因为 WebSocket 是长连接，不能靠单次 HTTP 请求模拟 - 注意区分：有些网站用
EventSource（SSE）或轮询（/api/data?ts=xxx），它们不属 WebSocket，但同样不会出现在初始 HTML 中
requests + BeautifulSoup 抓不到数据的必然原因
requests.get() 只获取服务端返回的首屏 HTML 字符串，它不执行 JavaScript，也不建立 WebSocket 连接
- 所谓“空数据”区域，HTML 源码里往往只有占位
<div id="list"></div>或<loading></loading>，没有真实内容 - BeautifulSoup 解析这个空壳，自然
soup.find_all('li', class_='item')返回空列表 - 这不是选择器写错、编码问题或网络超时，而是架构层面的数据延迟加载机制导致的
验证是否为前端渲染（CSR）的快速手法
禁用 JavaScript 后看页面是否还有数据
立即学习“Python免费学习笔记（深入）”；
- Chrome DevTools →
Settings（齿轮图标）→Preferences→ 勾选Disable JavaScript - 刷新页面：如果列表区域彻底空白或只剩骨架屏，说明数据完全依赖 JS 渲染（大概率含 WebSocket/SSE/动态 API）
- 对比开启 JS 时的 Network 面板，重点观察
XHR或Fetch/XHR子标签下是否有带实际数据的响应（如/api/v1/projects），这类才是真实数据源
能用什么替代 requests 直接抓取？
若确认数据走 WebSocket，requests 本身无法处理；需切换工具链
- 优先尝试抓取背后的 REST API：在 Network 面板中找
XHR请求，复制其 URL、Headers（尤其Cookie、Authorization）、参数，用requests.get(url, headers=headers, params=params)直接调用——这比模拟 WebSocket 简单得多 - 真要连 WebSocket：用
websockets库（非标准库，需pip install websockets），手动实现握手、消息收发、心跳维持，还要逆向协议格式（比如消息是纯文本、JSON 还是二进制） - 无头浏览器（Playwright / Selenium）可执行 JS 并等待 WebSocket 数据落进 DOM，但重、慢、易被反爬，仅当 API 不暴露且必须保真渲染时才考虑
真正棘手的不是“怎么连上 WebSocket”，而是它通常配合 token 鉴权、加密 payload、动态 endpoint 或心跳保活——这些细节藏在前端 JS 里，必须静态分析或动态调试才能还原。别指望靠抓包完事。
