优先检查是否真需浏览器渲染：若数据来自AJAX接口，直接用http.Client请求JSON；仅当强依赖DOM操作等才用chromedp控制Chrome渲染，注意编码、选择器及资源加载优化。
Go语言本身不执行JavaScript，所以直接用 net/http + goquery 无法获取前端动态渲染后的内容。处理动态网页，关键不是“换库”，而是明确页面数据来源：是AJAX接口返回的JSON？还是真需要浏览器渲染？对应策略完全不同。
优先检查是否真需渲染——先抓接口
很多所谓“动态网页”，实际只是用 JS 请求后端 API，HTML 骨架里没数据，但 Network 面板能看到清晰的 xhr/fetch 请求。这种场景最简单高效：
- 用浏览器开发者工具（F12 → Network → XHR），刷新页面，找带目标数据的请求（如
/api/movies或list.json） - 复制该请求的 URL、Method、Headers（尤其
Cookie、Authorization、Referer）和 Body（如有） - 在 Go 中用
http.Client模拟发起相同请求，直接解析返回的 JSON - 省去浏览器启动开销，速度快、稳定、易调试，且天然绕过大部分反爬前端逻辑
必须渲染时：用 chromedp 替代 Puppeteer
当页面逻辑强依赖 DOM 操作、Canvas 渲染、或 JS 修改了 URL/History 状态，才需真实浏览器环境。Go 生态中推荐 chromedp（轻量、纯 Go、无 Node 依赖）：
- 它通过 DevTools Protocol 控制 Chrome/Chromium，无需下载额外二进制（可复用系统已装 Chrome）
- 支持
chromedp.Navigate、chromedp.WaitVisible、chromedp.Click等语义化操作，比手动 sleep + 轮询更可靠 - 渲染完成后，可用
chromedp.OuterHTML或chromedp.InnerHTML获取最终 HTML，再交给goquery解析 - 注意设置
headless: true和合理超时（如 30 秒），避免挂起；用context.WithTimeout控制整段流程
规避常见坑：编码、选择器与资源加载
即使走浏览器方案，仍有几个细节极易出错：
立即学习“go语言免费学习笔记（深入）”；
- 中文乱码：chromedp 返回的 HTML 默认可能是 UTF-8，但部分页面声明
gbk或gb2312。若 goquery 找不到元素，先确认htmlContent字符串本身是否已乱码，必要时用golang.org/x/text/transform转码 - CSS 选择器失效：动态内容插入后，class 名可能含随机哈希（如
title_abc123），或结构层级变化。建议用属性选择器（[data-testid="movie-title"]）或文本匹配（Find("div").FilterFunction(...)）代替硬编码 class - 图片/字体等资源阻塞：默认 chromedp 会加载所有资源，拖慢速度。可加
chromedp.Flag("blink-settings", "imagesEnabled=false")禁用图片，或用chromedp.NetworkEnable拦截非必要请求
不要盲目并发渲染——成本远高于静态请求
每个 chromedp 实例相当于一个独立浏览器进程，内存占用高、启动慢。10 个并发就可能吃光 2G 内存：
- 避免对每个 URL 启一个新 chromedp context；应复用同一实例，串行处理多个页面（适合单页多 tab 场景）
- 若需真正并发，限制实例数（如最多 3 个），用 channel 控制调度，而非无脑开 goroutine
- 静态接口能解决的，绝不引入浏览器；90% 的“动态需求”其实只是没找到正确 API
