因为gumbo_parse返回GumboOutput*，其root字段指向根节点，所有内容均在子树中，需先判断node->type再访问对应字段（如GUMBO_NODE_TEXT时用node->v.text.text），否则强制类型转换会导致崩溃。
为什么直接用 gumbo_parse 后拿不到节点内容？
因为 gumbo_parse 返回的是 GumboOutput*，其 root 字段指向文档根节点（html 元素），但很多人误以为它包含 body 或文本节点——其实初始解析后所有内容都在子树里，且文本、注释、CDATA 都是独立的 GumboNode 类型，需手动遍历。
常见错误现象：output->root->children.length == 0 或取 text 字段崩溃，本质是没检查 type 就强转 element 或 text 字段。
- 必须先判断
node->type == GUMBO_NODE_ELEMENT才能访问node->v.element - 文本节点类型是
GUMBO_NODE_TEXT，对应字段是node->v.text.text（注意不是node->text） -
GumboOutput的root是，body在root->children的某个子节点里，不是固定索引 1 —— 要遍历找tag == GUMBO_TAG_BODY
如何安全提取所有
不能靠字符串匹配，也不能假设 DOM 结构扁平。Gumbo 不自动合并相邻文本节点，一个 可能含多个 GUMBO_NODE_TEXT、GUMBO_NODE_ELEMENT（如内嵌 ），甚至 GUMBO_NODE_WHITESPACE。
实操建议：写递归函数，对每个节点做类型分发：
void extract_text_from_p(const GumboNode* node, std::string& out) {
if (node->type != GUMBO_NODE_ELEMENT) return;
if (node->v.element.tag == GUMBO_TAG_P) {
// 进入 p 标签，遍历其所有子孙，只取 TEXT 类型
gumbo_vector_t* children = &node->v.element.children;
for (unsigned int i = 0; i length; ++i) {
const GumboNode* child = static_cast<const gumbonode>(children->data[i]);
if (child->type == GUMBO_NODE_TEXT) {
out += child->v.text.text;
} else if (child->type == GUMBO_NODE_ELEMENT) {
// 继续深入，比如处理 <p>hello<em>world</em></p>
extract_text_from_p(child, out);
}
}
return;
}
// 否则继续向下找 p 标签
gumbo_vector_t* children = &node->v.element.children;
for (unsigned int i = 0; i length; ++i) {
extract_text_from_p(static_cast<const gumbonode>(children->data[i]), out);
}
}</const></const>
注意：Gumbo 不管理内存生命周期，out += child->v.text.text 中的指针指向解析器内部缓冲区，只要 GumboOutput* 没被 gumbo_destroy_output 就有效。
gumbo_parse_with_options 哪些参数值得调？
默认 gumbo_parse 用的是内置选项，但实际项目中常需控制行为：
-
options->max_errors：设为 0 可禁用错误收集（省内存），非调试时建议关掉，避免GumboOutput->errors占用额外空间 -
options->tab_stop：影响内缩进解析，默认 8；若 HTML 来源已知用 4，可设为 4，否则保持默认 -
options->allocator：仅当已有内存池或需 hook 分配时才设；否则留空（nullptr），用 libcmalloc - 不要碰
options->fragment_context和options->fragment_namespace—— 这是给解析片段用的，传了却没设gumbo_parse_fragment会触发未定义行为
性能影响：开启错误收集（默认）会让解析慢约 5–10%，大文档下明显；关闭后 GumboOutput 体积减少约 15%。
为什么编译链接总报 undefined reference to 'gumbo_parse'？
不是头文件没包含，而是链接阶段找不到符号 —— Gumbo 默认不生成共享库，CMake 构建时若没显式启用 BUILD_SHARED_LIBS=ON，libgumbo.a 是静态库，但你的项目可能用了 -lgumbo（动态链接语法）。
解决路径：
- 确认安装方式：用
pkg-config --libs gumbo看输出，如果是-L/usr/local/lib -lgumbo，说明系统有 .so；否则大概率只有 .a - 静态链接写法：
g++ main.cpp -o app /usr/local/lib/libgumbo.a（路径按实际调整） - 若用 CMake，别只写
find_package(gumbo)，要加target_link_libraries(myapp gumbo)并确保find_package正确找到 config 文件（Gumbo 安装后不一定生成标准 cmake config） - Mac 上用 Homebrew 安装的 gumbo，头文件在
/opt/homebrew/include/gumbo.h，但库在/opt/homebrew/lib/libgumbo.dylib，路径不一致易漏-L
最容易被忽略的一点：Gumbo 的 C 接口不带 C++ name mangling，所以 C++ 代码中必须用 extern "C" 包裹头文件包含，否则链接器找不到符号：
extern "C" {
#include <gumbo.h>
}</gumbo.h>
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
