用libkml解析KML最直接，但需先编译：apt install libkml-dev或源码构建；解析KMZ须手动解压doc.kml再ParseKml；遍历Placemark需AsFeature()安全转型；坐标顺序为lng/lat/alt；UTF-8编码需校验BOM，避免乱码。
用 libkml 解析 KML 文件最直接，但得先编译它
libkml 是 Google 开源的官方 C++ KML 库，支持 KmlFactory、ParseKml 等核心接口，但不自带预编译二进制。直接 apt install libkml-dev 在多数发行版（如 Ubuntu 22.04+）可用；若不可用，需从源码构建：git clone https://github.com/google/libkml.git，然后用 CMake 编译（注意依赖 expat 和 minizip）。KMZ 是 ZIP 封装的 KML，libkml 本身不自动解压，得先用 minizip 或 libzip 提取 doc.kml 再喂给 ParseKml。
解析 KMZ 要手动解包，不能直接传 .kmz 文件给 ParseKml
ParseKml 只接受 XML 字符串或 std::istream，不识别 ZIP 容器。常见错误是把 .kmz 文件路径直接传进去，结果触发 XML parse error: not well-formed (invalid token)。正确流程是：
- 用
libzip打开 KMZ 文件，定位并读取其中的doc.kml（有些 KMZ 用root.kml或其他名，需遍历zip_get_num_entries） - 将解压出的 KML 内容加载为
std::string，再用ParseKml解析 - 若 KMZ 含多层嵌套 KML（如引用
NetworkLink），libkml 不自动递归加载，需自行提取并解析子文件
解析后遍历 Placemark 时注意 DOM 结构和命名空间
libkml 的 DOM 树以 KmlPtr 为根，真实地理要素藏在 Document 或 Folder 的 FeatureVector 里。直接 cast 到 PlacemarkPtr 很容易空指针崩溃——因为节点可能是 Folder、NetworkLink 或 GroundOverlay。安全做法是：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 用
AsFeature()安全转型，再用dynamic_cast<Placemark*>判别类型 - 坐标数据在
Point的coordinates()返回Vec3Vector，每个Vec3是lng, lat, alt（注意顺序不是 lat/lng） - KML 默认使用 WGS84，但
altitudeMode可能是clampToGround、relativeToSeaFloor等，影响alt值是否有效
中文标签和 UTF-8 编码问题常导致乱码或解析失败
libkml 默认按 UTF-8 解析，但部分 KML 文件声明了 <?xml version="1.0" encoding="GBK"?> 却实际存为 UTF-8，或反之。表现是 name() 返回空字符串或乱码。解决方法：
立即学习“C++免费学习笔记（深入）”；
- 用
std::ifstream以binary模式读取，先检测 BOM：若前 3 字节为\xEF\xBB\xBF，则确认 UTF-8；否则按声明 encoding 转换（推荐用iconv或utf8cpp） - 不要依赖 KML 文件头的
encoding声明——很多生成工具（如 QGIS 导出）会写错 - libkml 不处理 XML 实体（如
htmlcxx展开
libkml 对 ExtendedData 和自定义 Schema 支持较弱，字段名可能丢失命名空间前缀，需要手动 strip gx: 或 atom: 等 prefix 才能匹配预期 key。
