Geolocation API 触发限流主因是未合理配置 maximumAge 和 timeout，导致高频、重复或后台定位请求；应设 maximumAge 复用缓存、timeout 防卡死、enableHighAccuracy=false 降功耗，并避免多模块叠加调用。
为什么 Geolocation API 会触发限流？
浏览器对 navigator.geolocation.getCurrentPosition() 的调用本身不限流，但实际中频繁调用常被误判为异常行为——尤其在短时间内重复请求、未处理失败回调、或在页面不可见时仍轮询定位。Chrome 和 Safari 会在后台标签页降级定位精度甚至拒绝响应，部分安卓 WebView 还会叠加系统级节流策略。
- 每次调用都可能触发 GPS 模块唤醒、WiFi 扫描、基站查询，系统层面对此有功耗保护机制
- 若未设置
timeout或maximumAge，浏览器可能缓存过期结果并反复重试，形成隐式高频请求 - 某些地图 SDK（如高德、腾讯）在内部封装
Geolocation后，额外加了防抖逻辑，但开发者若绕过 SDK 直接调用原生 API，就失去这层保护
如何用 maximumAge 和 timeout 控制请求节奏？
这两个选项不是“可选”，而是限流防控的关键开关。不设 maximumAge，等于每次都要新鲜定位；不设 timeout，失败请求可能卡住线程并触发重试逻辑。
-
maximumAge: 5 * 60 * 1000（5 分钟）：允许复用最近一次成功获取的位置，避免无意义刷新 -
timeout: 8000（8 秒）：防止弱网下长期挂起，超时后应降级（如用 IP 定位或上一次坐标） -
enableHighAccuracy: false：除非业务强依赖精度，否则关闭它能显著减少 GPS 唤醒频次和耗电
示例：
navigator.geolocation.getCurrentPosition(
successCb,
errorCb,
{
maximumAge: 300000,
timeout: 8000,
enableHighAccuracy: false
}
);
页面生命周期内该不该自动重试？
不该盲目重试。用户切到后台、锁屏、或网络中断时，重试不仅无效，还会被系统标记为骚扰行为。正确做法是监听可见性变化，并只在页面激活且网络可用时才考虑更新。
- 用
document.visibilityState === 'visible'判断是否前台 - 结合
navigator.onLine或fetch('/health')简单探测网络状态 - 首次定位成功后，用
setTimeout或requestIdleCallback延迟下一次尝试，避免密集触发 - 错误类型要区分：
PERMISSION_DENIED不重试，POSITION_UNAVAILABLE可等 30 秒再试，TIMEOUT建议直接降级
地图 SDK 自带定位要不要关掉？
要关，或者至少禁用其自动轮询。比如高德 JS API 的 AMap.Geolocation 默认开启 watchPosition 模式，即使你只调用一次 getCurrentPosition，它也可能在后台持续监听。腾讯地图的 qq.maps.Geolocation 同理。
立即学习“前端免费学习笔记（深入）”；
- 初始化时显式传入
{ timeout: 10000, maximumAge: 600000, noCache: true }等参数覆盖默认行为 - 调用完立即销毁实例（如高德的
geolocation.stop()），避免内存泄漏和后台定位残留 - 如果只是做一次初始定位，别用
watchPosition，也别在mounted/useEffect里无条件 new 实例
真正难控的不是代码写几行，而是多个模块（基础定位、地图 SDK、业务轮询逻辑）各自悄悄发起请求，叠加之后远超阈值。得把每处调用点都查一遍，确认是否真的必要。
