goquery.LoadHTMLString 解析失败但不报错，主因是 UTF-8 BOM（\uFEFF）导致 net/html 静默跳过非法字符；需用 strings.TrimPrefix 剥离 BOM 后再解析。
goquery.LoadHTMLString 解析失败但没报错？检查输入是否含 BOM
Go 的 goquery.LoadHTMLString 遇到带 UTF-8 BOM 的 HTML 字符串时，会静默解析失败（返回空文档），doc.Find 一律找不到节点，且不 panic、不 error。这不是 bug，是底层 net/html 解析器对 BOM 的处理策略：它把 BOM 当作非法字符跳过，导致后续标签识别错位。
- 用
strings.TrimSpace或bytes.TrimPrefix剥离开头的\uFEFF（BOM）再传给goquery.LoadHTMLString - 调试时先打印字符串前 10 字节：
fmt.Printf("% x", []byte(htmlStr)[:10])，看到ef bb bf就确认有 BOM - 如果 HTML 来自文件读取，改用
ioutil.ReadFile（Go 1.16+ 用os.ReadFile）后手动 trim，别直接用goquery.Open—— 它内部不处理 BOM
Find("a") 返回空？注意 CSS 选择器对大小写和命名空间敏感
goquery.Find 底层走的是 Go 标准库的 net/html，而该解析器默认把所有标签名转为小写。但如果你的 HTML 是 XHTML 或含 XML 命名空间（比如 Find("A") 或 Find("mycomponent") 都会失效。
- 一律用小写写选择器：
Find("a")、Find("div")，哪怕源 HTML 写的是@#@#@#@#@#@#@#@#@#@0 - 遇到 SVG 或 MathML 元素，不能靠
Find("svg rect")直接匹配；需先Find("svg").Each(...)进入命名空间子树再查 - 自定义标签（如 Web Components）在
net/html中被当作未知元素，但依然可被Find("*")捕获，之后用Nodes[0].Data手动比对标签名
ForEach 循环里调用 .Text() 总是空？Node.Data 和 TextContent 不是一回事
goquery.Selection.Text() 返回的是**所有后代文本节点拼接后的纯文本**，不含标签；但它依赖 DOM 树完整构建。如果节点本身是 <script></script>、 或注释节点，.Text() 返回空字符串——不是 bug，是设计如此，因为这些节点的“文本内容”在 HTML 规范中不参与渲染文本流。
- 要取
<script></script>里的 JS 代码，用selection.Nodes[0].FirstChild.Data（前提是它只有一个文本子节点） - 通用安全取法：
strings.TrimSpace(selection.Contents().Text())，Contents()包含所有子节点（含文本、注释、元素），再统一提取文本 - 若需保留换行/缩进，别用
.Text()，改用selection.Html()+ 正则清理标签，或遍历selection.Contents().Each(...)判断node.Type == html.TextNode
并发解析多个 HTML 页面内存暴涨？别复用 Document 实例
goquery.Document 不是线程安全的，更不能跨 goroutine 复用。常见反模式是全局声明一个 doc *goquery.Document，然后在多个 goroutine 里反复调用 doc.Find(...) —— 这会导致内部缓存混乱、节点引用泄漏，GC 无法回收，内存持续上涨。
- 每个 HTML 字符串都应独立调用
goquery.NewDocumentFromReader或goquery.LoadHTMLString，生成新*goquery.Document - 如果只是重复查询同一份 HTML，用
doc.Clone()比重建快，但注意Clone()也分配新内存，别在 hot loop 里无脑 clone - 极端性能场景（如每秒解析上万页），考虑用
net/html.Parse直接解析到*html.Node，绕过 goquery 封装，自己写简单 selector 匹配逻辑
事情说清了就结束。BOM、大小写、Text() 行为、并发复用——这四个点踩中任意一个，goquery 就会“看起来正常跑，结果啥也拿不到”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
