先抛出一个核心判断：在 C++ 里解析 GeoJSON 的 FeatureCollection，最省事的办法就是用 nlohmann/json 这个库。它天然支持嵌套结构，对 type、features、properties 这些字段名完全兼容，不需要你提前定义 schema。但前提是——输入必须合法，否则 json::parse() 会直接抛异常，不处理就等于崩溃。
用 nlohmann/json 解析 GeoJSON FeatureCollection 最省事
GeoJSON 本质上就是 JSON，C++ 没有原生支持，硬写解析器纯属重复造轮子。直接用 nlohmann/json 是最稳妥的方案。具体操作很简单：
- 用
json j = json::parse(json_str)加载字符串；如果从文件读，先用std::ifstream读成std::string再 parse。 - 上来先检查根对象的类型：
if (j.at("type") != "FeatureCollection")，防止误传Feature或Geometry类型。 j.at("features")返回的是json::array_t，遍历时用for (const auto& f : j.at("features"))，别用size()+ 下标——nlohmann 的 range-for 更安全，也少写一行。
提取单个 Feature 的 geometry 和 properties 要分层访问
GeoJSON 的 Feature 是三层嵌套：feature → geometry → coordinates 和 feature → properties → {任意键值}。nlohmann/json 不做类型推断，所有字段访问都得显式调用 .at() 或 .value()，否则遇到缺失字段就会炸。
一个典型错误：直接写 f["geometry"]["coordinates"]。一旦某个 feature 缺了 geometry，程序直接 terminate。正确的做法是逐层防御性访问：
- 先确认
f.contains("geometry")，再检查f.at("geometry").contains("type")和f.at("geometry").contains("coordinates")。 - 坐标数组的维度不确定：
Point是[x,y]（长度为2的数组），LineString是[[x,y], [x,y]]（二维数组），Polygon是三维（外环+内环）。用f.at("geometry").at("coordinates").size()判断维度，别硬转成std::vector。 properties是自由结构，先检查f.at("properties").is_object()，再用.value("name", "")安全取默认值，千万别用.at("name")——万一没有这个字段，直接崩溃。
坐标系和精度问题在解析层无法解决，但必须留出接口
nlohmann/json 只管把数字当 double 解出来，它不管这是 WGS84 经纬度还是 Web Mercator 米制坐标。GeoJSON 规范明确要求坐标为 [longitude, latitude]（即 EPSG:4326），但实际数据经常不守规矩——比如国内某些导出工具会输出 GCJ-02 偏移坐标，或者把 coordinates 顺序写成 [lat, lon]。
解析代码里不要做坐标转换，但必须让调用方能轻易干预。常见做法是在解析循环里暴露原始 coordinates 数组的引用，而不是立刻转成自定义的 Point 结构体。
- 不要写
auto pt = Point{coord[0].get这种紧耦合代码，一旦上层想换坐标系就得改底层。(), coord[1].get ()} - 推荐返回
std::vector或json类型的coordinates字段，由上层决定是否调用 PROJ 或 GDAL 做转换。 - 如果必须存为内部结构，用
struct Coord { double x; double y; };而非lat/lon命名，避免语义误导。
性能敏感时避免重复解析和深拷贝
一个含上千 features 的 GeoJSON 文件，用 json::parse() 生成的 DOM 树内存占用可能达到数 MB，而且每次访问 .at("features")[i].at("geometry") 虽然是 O(1) 但带有 hash 查找开销。在高频场景（比如实时渲染）下，反复解析同一份数据是明显的瓶颈。
真正该优化的不是解析逻辑本身，而是复用策略和视口裁剪。解析是一次性的，后续操作应该基于内存中已有的 json 对象，而不是反复从字符串重 parse。
- 把解析结果缓存在类成员变量里，用
const json&引用传递，禁止json j = parsed_json这种隐式拷贝——深拷贝成本很高。 - 如果只关心视口内的 features，解析完立即用 bounding box（
geometry的coordinates极值）做过滤，别等全部解析完再遍历。 - 不要用
json::dump()回写调试——日志直接打印j.at("features").size()和前几个f.at("properties").dump()就够了，整个 dump 太慢。
解析 GeoJSON 的难点从来不在语法层面，而在于地理语义的模糊性：坐标顺序、CRS 声明缺失、空 geometry、混合 geometry type……这些都不会报 JSON 错误，但会让下游计算彻底失效。所以每一步访问都得带校验，宁可多写几行 contains()，也不要靠文档赌数据质量。
