使用std::string::find定位标签，提取原始文本后清除首尾空白，再用std::stringstream按空格分割三元组，逐个以逗号解析为经度、纬度、海拔（缺失则设0.0），全程try/catch防stod异常。
Google Earth 导出的 KML 文件里，坐标通常藏在 <coordinates></coordinates> 标签内，格式是空格分隔的“经度,纬度,海拔”三元组（如 116.404,39.915,0），但实际解析时容易因换行、缩进、多余空格或缺少海拔值崩溃——直接用 std::stringstream 按空格切分再按逗号拆解，是最轻量且可控的方式，无需引入 XML 解析库。
怎么提取 <coordinates></coordinates> 标签内的原始文本
KML 是标准 XML，但如果你只关心轨迹点，不必上 libxml2 或 pugixml。Google Earth 生成的 KML 中，路径坐标几乎总在 <linestring><coordinates>...</coordinates></linestring> 或 <track><coord>...</coord></track> 结构里。对简单场景，正则或字符串查找更直接：
- 用
std::string::find定位"<coordinates>"</coordinates>和""，注意处理大小写和前后空白 - 提取后调用
std::string::erase清掉首尾空白和换行符（\r\n\t） - 避免用正则匹配嵌套标签——KML 可能含注释或 CDATA，正则易误判；只定位最外层
<coordinates></coordinates>即可 - 若文件含多个
<coordinates></coordinates>（如多条路径），需循环提取，每次从上次结束位置继续搜索
如何安全地把坐标字符串转成 std::vector<:tuple double>></:tuple>
原始文本类似："116.404,39.915,0 116.405,39.916,0.5 116.407,39.918"（注意：第三个值可能缺失）：
- 用
std::stringstream按空格分割出每个三元组字符串，跳过空字符串（if (token.empty()) continue） - 对每个
token，用std::string::find_first_of(",")找逗号，分三段解析：经度、纬度必存在，海拔可选；若找不到第二个逗号，设海拔为0.0 - 用
std::stod转换，包裹try/catch——KML 里偶尔混入非数字字符（如注释残留"#116.404"），不捕获会导致程序终止 - 顺序必须是“经度,纬度,海拔”，Google Earth 严格遵循此序；反了会把北京画到南美洲
常见错误现象和绕过方法
直接跑通代码却画错位置？大概率栽在这几个点上：
立即学习“C++免费学习笔记（深入）”；
-
std::stod遇到科学计数法（如"1.16404e+2"）能正确解析，但某些旧编译器 locale 设置异常时会失败——显式调用std::stod(token, nullptr, std::locale::classic()) - KML 中坐标可能用制表符或混合空格分隔，
std::stringstream默认只认空格，需先用std::replace把\t替成空格 - Google Earth 有时导出带
<coord></coord>的扩展标签（尤其含时间戳的<track></track>），此时应优先解析<coord></coord>内容，而非忽略命名空间前缀硬找<coord></coord> - 经纬度值范围不对：经度超 [-180,180] 或纬度超 [-90,90]，说明解析时把两个坐标串连在一起了（如
"116.404,39.915116.405,39.916"）——这是空格被吃掉导致的，检查是否漏调std::string::erase清除所有空白
真正麻烦的不是解析本身，而是 KML 实际结构比规范松散得多：同一份数据，Google Earth 桌面版、网页版、移动版导出的标签嵌套深度和命名空间都可能不同。如果必须支持全格式，别硬刚字符串处理——老老实实用 pugixml 加 XPath 查询 //coordinates | //gx:coord，但对单次轨迹提取，手撕字符串更快、依赖更少、出错路径更清晰。
