页面内容未在初始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 源码里往往只有占位
  或 ，没有真实内容
• BeautifulSoup 解析这个空壳，自然 soup.find_all('li', class_='item') 返回空列表
• 这不是选择器写错、编码问题或网络超时，而是架构层面的数据延迟加载机制导致的

验证是否为前端渲染（CSR）的快速手法

禁用 JavaScript 后看页面是否还有数据

Python Hardener

通过完整的安全审查、代码整洁重构、健壮的错误处理、正确的日志记录以及完整的文档字符串覆盖，强化 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 里，必须静态分析或动态调试才能还原。别指望靠抓包完事。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！