GeoHash编码本质是二维坐标到一维字符串的递归空间折叠：先对经纬度分别二分编码，再按“先纬度后经度”交替交织比特，最后用固定base32表查表转字符串。
GeoHash 编码原理必须先理清：不是简单经纬度转字符串
直接手写 geohash_encode 前，得明白它本质是「二维坐标到一维字符串的递归空间折叠」：对经度、纬度分别做二分区间编码（类似线段树），再按偶奇位交替拼接比特，最后 base32 编码。错把经纬度直接转 float 再格式化成字符串，就完全偏离 GeoHash 语义了。
关键点：
- 经度范围固定为
[-180.0, 180.0)，纬度为[-90.0, 90.0)，超出需截断或报错，不能取模 - 精度由输出字符串长度决定：每增加 1 位字符 ≈ 经度误差减半 × 纬度误差减半，5 位约 4.9km，8 位约 19m
- base32 字符表顺序必须严格为
"0123456789bcdefghjkmnpqrstuvwxyz"（缺i, l, o, u避免混淆）
手写 encode 的核心三步：二分编码 → 交织比特 → base32 查表
不依赖 Boost 或第三方库，纯 C++11 可完成。重点在避免浮点累积误差和整数溢出。
实操建议：
- 用
int表示「当前区间内偏移步数」而非直接存浮点中间值，例如对经度做 32 次二分，可用uint64_t存 64 位编码串（足够 12 位 GeoHash） - 交织时，**先纬度后经度**：GeoHash 标准规定第 0 位是纬度 bit，第 1 位是经度 bit，即
lat_bit, lng_bit, lat_bit, lng_bit... - base32 查表必须用数组而非
std::map或 switch——每字符查表要快，且表长固定 32
简例（伪逻辑）：
geohash_decode
- 只解出一个点坐标，没返回
min_lon/max_lon/min_lat/max_lat—— 这样无法做范围查询或邻近格子计算 - base32 解码时未处理大小写：GeoHash 字符串规范是小写，但实际中可能混入大写，应统一
tolower - 对空字符串或非法字符（如
'i'）未设 fallback，导致越界访问base32_table数组
性能提示：解码时可预分配固定长度的 bit vector（如 std::vector 或 uint64_t[2]），避免频繁 resize。
边界与精度陷阱：为什么你的相邻格子总是算错？
手写实现最常崩在「格子边界不闭合」：比如 "wx4g0" 和 "wx4g1" 对应的经度区间理论上应首尾相接，但因浮点二分累积误差，可能留微小缝隙或重叠。
解决办法很实在：
- 所有区间运算用
double足够，但**每次二分都重新计算中点**，别基于上一步的浮点结果累加 - 生成邻近格子（north/south/east/west）时，不要对编码字符串末位字符加减，而应先 decode 成区间，再平移区间，最后 re-encode —— 否则跨纬度带或本初子午线时必然出错
- 测试用例必须覆盖极点（
lat=±90）、日期变更线（lng=±180）、赤道（lat=0）—— 这些地方二分收敛速度不同，容易暴露逻辑漏洞
真正难的从来不是算法本身，而是让 encode(lat, lng, 5) 和 decode("u09tu") 在所有边界条件下，能 round-trip 且区间端点数学上可验证闭合。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
