Polyline编码是Google提出的轨迹压缩算法，将经纬度序列转为紧凑ASCII字符串，采用增量差分、ZigZag编码和5-bit分组解码；不能用std::stod直接解析，因其无分隔符、非浮点文本，且字符代表带符号增量而非坐标值。

什么是 Polyline 编码，为什么不能直接用 std::stod 解析？

说到轨迹数据的压缩与传输，Google的Polyline编码绝对是个绕不开的角色。它可不是简单的Base64或者JSON序列化，而是一套精巧的自定义规则，融合了变长整数、增量差分、ZigZag编码和ASCII字符映射。如果你试图用std::stod去直接解析它，结果只会是一头雾水——因为整个字符串是连贯编码的，中间没有逗号之类的分隔符，而且每个字符代表的并非原始坐标，而是坐标之间的“增量差值”。

典型的错误场景是怎样的呢？比如面对字符串"_p~iF~ps|U_ulLnnqC_mqNvxq`@"，你把它当成一个坐标或者拆分成乱码字符，std::stod在遇到第一个非数字字符（比如那个下划线‘_’）时就会罢工，要么返回0，要么直接抛出异常。

要真正理解它，得抓住几个关键点：

• 字符串里的每个字符，其实对应一个5比特的编码单元（ASCII码值减去63），需要连续读取，5位一组。
• 所有数值都以“带符号整数”的形式存储，但用了ZigZag编码来巧妙处理正负：偶数代表非负数（比如0→0，2→1），奇数则代表负数（比如1→-1，3→-2）。
• 坐标是“增量”累加出来的：第二个点的纬度等于第一个点的纬度加上解码出的纬度增量乘以1e-5，经度同理。每个点都不是独立值。

如何手写 C++ 解码器：核心四步不可跳过

既然标准库里没有现成的函数，手动实现一个解码器就成了必经之路。这个过程必须严格遵循Google的官方算法，下面这四步逻辑环环相扣，一步都不能省。

立即学习“C++免费学习笔记（深入）”；

• 第一步：逐字符解码。对每个字符c，先计算c - 63，然后将这个5比特的值左移相应位数，与下一个5比特单元拼接起来。这个过程一直持续，直到读到一个最高位为0的单元（即value & 0x20 == 0），一个完整的变长整数才算读完。
• 第二步：ZigZag解码。对上一步拼出来的无符号整数val，执行(val >> 1) ^ (-(val & 1))这个魔法般的操作，就能还原出有符号的坐标增量（delta）。
• 第三步：累积还原坐标。需要维护两个累加器lat_sum和lng_sum。每次解码出一个增量，就累加上delta * 1e-5。这里务必使用double类型，float的精度可能不够看。
• 第四步：注意精度对齐。Google默认使用5位小数（即乘以1e-5），但有些第三方服务可能会用6位（1e-6）。如果不确认输入来源就硬编码1e-5，是常见的兼容性陷阱。

来看一个核心循环的示意片段，关键逻辑都在这里：

std::vector> decodePolyline(const std::string& encoded) {
    std::vector> coords;
    int64_t lat = 0, lng = 0;
    size_t i = 0;
    while (i < encoded.size()) {
        int64_t shift = 0, result = 0;
        // Step 1: read variable-length integer
        do {
            if (i >= encoded.size()) return coords;
            int64_t b = encoded[i++] - 63;
            result |= (b & 0x1f) << shift;
            shift += 5;
        } while (b >= 0x20);
        // Step 2: zigzag decode
        int64_t dlat = (result >> 1) ^ (-(result & 1));
        lat += dlat;
        // 经度的解码逻辑完全相同，此处省略重复部分...
        coords.emplace_back(lat * 1e-5, lng * 1e-5);
    }
    return coords;
}

decodePolyline 函数在 Windows / GCC / Clang 下的整数溢出风险

算法本身看起来是安全的，单次坐标增量最大也就±1.8e7左右（对应±180度）。问题出在连续累加上。如果错误地使用了int32_t（特别是在32位环境或旧代码迁移时），可能解码不到5个点，累加值就溢出了，导致坐标瞬间“跳”到地球的另一端。

更隐蔽的风险来自编译器的差异：GCC和Clang默认将有符号整数溢出视为“未定义行为”，而MSVC在Debug模式下可能会触发断言。因此，实践中务必注意：

• 强制使用int64_t来存储累计值和中间解码结果result，不要依赖平台相关的int或long。
• 在拼接result时，可以增加一个安全检查：if (shift > 64) throw std::runtime_error(“polyline overflow”)，防止因异常数据导致过度移位。
• 绝对不要尝试用std::stoi或atol来处理单个字符，它们根本无法理解这种变长编码格式。

遇到 "Invalid polyline string" 错误时优先检查哪三处？

这个错误提示通常来自自定义代码或第三方库。别慌，90%的情况下，问题都出在下面这三个看似低级却非常致命的地方：

• 第一，检查输入字符串的“纯净度”。字符串开头是否意外包含了空格、换行符，甚至是UTF-8的BOM头（\xEF\xBB\xBF）？有效的Polyline字符范围应在0x40–0x7F之间，第一个字符无效就会导致解码器“开门黑”。
• 第二，严防数组访问越界。在解码循环中，如果忘记判断索引i是否已到达字符串末尾encoded.size()就访问encoded[i]，在ASan（地址消毒器）下会直接崩溃，在Release模式下则可能静默地读取到错误数据。
• 第三，确认经纬度顺序。Google Polyline的固定顺序是[纬度, 经度]。但有些国产的SDK或地图引擎可能要求[经度, 纬度]。如果解码出来的点全都落在太平洋中央，十有八九是顺序搞反了。

至于更棘手的边界情况，比如超长轨迹（超过1万个点），则需要关注浮点数的累积误差。虽然double类型在理论上能保持1e-5的精度到很大的量级，但实践中更稳妥的做法是：每累积解码1000个点左右，就重置一次基准坐标，并记录偏移量。这样可以避免轨迹末尾的点出现米级的偏移，确保精度始终在线。