dot文件是纯文本，可用std::ifstream逐行读取；需用正则提取边关系、跳过注释、配对花括号，并做路径规范化与节点校验，而非依赖json/xml解析器或重型语法生成器。
DOT文件本质是文本，不是二进制格式，直接用标准库读取即可
Graphviz的.dot文件是纯文本，遵循明确的语法规则（比如以digraph或graph开头，节点用"node_name"表示，边用"A" -> "B"定义）。C++无需专用解析器——std::ifstream逐行读、std::string切分、正则匹配就能覆盖绝大多数场景。
常见错误是试图用JSON解析器或XML库去读.dot，结果报错或漏掉注释行。其实//和/* */在DOT里是合法注释，必须跳过；而strict digraph G {这种带空格/关键字组合的行，不能靠简单std::getline + find("->")硬拆。
- 先用
std::regex匹配有效语句：例如R"(\"([^\"]+)\"\s*->\s*\"([^\"]+)\")"抓边，R"(^(\w+)[\s{]+)?"识别图声明 - 遇到
{和}要计数配对，避免误判子图边界 -
//注释必须在分割前整行过滤，否则可能把"foo//bar" -> "baz"错切成两段
用antlr4生成C++解析器太重，轻量场景推荐手写状态机
ANTLR4能生成完整DOT语法树，但引入libantlr4-runtime、编译g4文件、处理内存生命周期，对只想提取“哪些节点连了哪些边”的项目属于杀鸡用牛刀。实际项目中，90%需求只是遍历边关系或找某个节点的所有入边。
一个三状态机就够用：IN_GRAPH（刚读到digraph）、IN_STMT（大括号内）、IN_SUBGRAPH（遇到subgraph {时嵌套）。每个状态只关心当前行是否含->、{、}或=。
- 边解析优先级高于属性赋值：同一行
"a" -> "b" [color=red]，先取"a"和"b"，再用正则R"(\[.*color=([^,\]]+)\])"提颜色 - 节点名可能带空格或特殊字符，必须按双引号包裹规则提取，不能用
std::stringstream >>按空格切 - 忽略
node [shape=box]这类全局属性，除非你真要渲染样式
第三方库如dotreader存在兼容性陷阱
GitHub上几个标称“C++ DOT parser”的小众库（如dotreader、dotcpp）大多停更于2018年前，不支持DOT 2.40+新增的html-like标签节点（如<table>...</table>），也常把edge [dir=back]误判为节点。
更麻烦的是路径处理：这些库默认把"src/main.cpp"当字符串字面量，但实际项目里你可能需要把"../include/utils.h"自动转成相对于项目根目录的规范路径——它们不提供hook点。
- 若坚持用第三方库，务必测试
digraph G { a [label="x\ny"]; b; a -> b [weight=2.5]; }这类混合语法 - 检查其
Node.id()返回值是否保留原始引号（应为"a"而非a），否则和源码符号对不上 - 避免依赖
boost::spirit实现的解析器——编译时间暴涨且Windows下常因模板深度爆栈
真正难的是语义校验，不是语法解析
语法正确不等于图有意义。比如digraph { "A" -> "B"; "B" -> "C"; "C" -> "A"; }是合法DOT，但构成环，后续做拓扑排序会失败；又如"file.cpp" -> "missing.h"在依赖分析中意味着头文件缺失，但解析器本身不会报错。
所以解析后必须加一层业务校验：
- 收集所有
"xxx"字符串，去重后得到节点全集；再检查每条->边的两端是否都在该集合内 - 对节点名做路径规范化：用
std::filesystem::weakly_canonical()处理相对路径，避免"./src/a.h"和"src/a.h"被当成两个节点 - 如果目标是头文件依赖分析，需额外过滤掉系统路径（如
/usr/include/）和构建产物（如build/generated/），这部分逻辑必须自己写
最易被忽略的是编码问题：Windows下记事本保存的UTF-8 with BOM的.dot文件，C++读取时std::ifstream默认当ANSI处理，首行digraph会导致整个解析失败。得手动跳过BOM字节或改用std::wifstream。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
