geolocation api 实际精度由设备与环境决定，coords.accuracy 值（米）为真实参考：开阔地手机 3–10 米，室内或老旧安卓机 50–500 米；enablehighaccuracy 仅尝试启用 gps，不保证更高精度，且耗电增、定位延迟升。
Geolocation API 的精度到底有多高？
实际精度取决于设备类型和环境，不是代码能直接控制的。navigator.geolocation.getCurrentPosition() 返回的 coords.accuracy 值（单位：米）才是真实参考——手机在开阔地可能 3–10 米，室内或老款安卓机常达 50–500 米；浏览器本身不提升硬件能力，只是暴露底层定位结果。
常见误区是以为调高 enableHighAccuracy: true 就一定更准，其实它只尝试启用 GPS（而非仅 WiFi/基站），但：
- 在无 GPS 模块的笔记本上会被忽略，仍走 IP 或 WiFi 定位
- 开启后耗电明显增加，部分 Android 会弹出额外权限确认
- 首次定位时间可能从几百毫秒拉长到数秒
浏览器对 navigator.geolocation 的硬性限制
现代浏览器强制要求 HTTPS 环境下才能使用 getCurrentPosition() 和 watchPosition()，HTTP 页面会直接拒绝并抛出 SecurityError。本地开发时 http://localhost 和 http://127.0.0.1 是例外，但一旦部署到非 localhost 的 HTTP 域名，必然失败。
用户拒绝授权后，后续调用不会自动重试——PermissionDeniedError 一旦触发，除非用户手动进浏览器设置改权限，否则 getCurrentPosition() 永远走 error 回调。没有“静默降级”机制。
立即学习“Java免费学习笔记（深入）”；
另外注意：navigator.geolocation 在部分 WebView（如微信内置浏览器、某些旧版 iOS WKWebView）中完全不可用，检测方式只能是：
if (!navigator.geolocation) {
console.error('Geolocation not supported');
}
如何合理处理 timeout 和 maximumAge
timeout 不是“最多等几秒”，而是“从开始定位起，若超时仍未拿到结果，则触发 error 回调”。它不中断底层定位过程，只是放弃等待。
maximumAge 控制是否接受缓存位置：设为 0 强制刷新（适合导航类应用），设为 300000（5 分钟）则可能直接返回上次成功结果（适合天气类轻量查询）。但注意：
- 缓存结果仍受
enableHighAccuracy影响：上次是低精度，这次即使设了true，缓存也不会变准 - Android Chrome 对
maximumAge支持不稳定，部分版本忽略该参数 - 若缓存过期且定位失败，error 回调会收到
PositionError.TIMEOUT，容易误判
为什么 watchPosition 返回的位置有时跳变剧烈？
navigator.geolocation.watchPosition() 持续监听时，设备可能在 GPS、WiFi、基站定位间动态切换，尤其在移动场景下。典型表现是 coords.latitude / coords.longitude 突然偏移几百米，coords.accuracy 也同步剧烈波动。
不能依赖原始数据直接绘点，必须加过滤逻辑：
- 丢弃
accuracy > 100的点（城市内步行场景） - 用速度估算：若前后两次距离 / 时间差 > 30 m/s（约 108 km/h），大概率是定位漂移
- 简单平滑可用加权移动平均，但别用太重的滤波——实时导航需要低延迟
真正难处理的是“静止时漂移”：用户坐在办公室不动，坐标却缓慢爬行。这源于 WiFi 定位源变化（比如附近路由器重启），目前无通用解法，只能结合业务容忍阈值做截断。
