最常见原因是HTTP协议不安全导致浏览器静默拦截，仅HTTPS或localhost可调用；用户授权后仍常触发error回调，需重点处理PERMISSION_DENIED、POSITION_UNAVAILABLE和TIMEOUT等错误，并依据accuracy值判断坐标可信度。
必须用 HTTPS 或 localhost 才能调用 navigator.geolocation.getCurrentPosition，否则静默失败或抛 SecurityError；用户点“允许”不等于拿到坐标，error 回调比 success 更常触发。
为什么调用 getCurrentPosition 没反应、也不报错
最常见原因是协议不安全：HTTP 域名（如 http://example.com）下直接被浏览器拦截，控制台可能只显示 Only secure origins are allowed，甚至完全无日志。本地开发时 http://localhost 和 http://127.0.0.1 是例外，但只要部署到真实 HTTP 域名，就必然失败。
解决办法很简单：
- 检查
location.protocol，非https:时提前禁用定位按钮或提示“请在 HTTPS 环境下使用” - 用
ngrok、localtunnel或 Vercel/Netlify 预览链接做临时 HTTPS 测试 - 老旧安卓 WebView（Android 6–8 系统浏览器）即使 HTTPS 也可能返回
NotSupportedError，需 fallback 到 IP 地理库或手动输入
getCurrentPosition 的 error 回调到底覆盖哪些情况
用户点击“允许”只是授权第一步，后续仍可能失败。error 回调实际处理的是绝大多数真实场景，而非仅“用户拒绝”：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
error.code === error.PERMISSION_DENIED：用户点了“拒绝”，或系统级关闭了网站定位权限（如 iOS 设置里关掉 Safari 的定位） -
error.code === error.POSITION_UNAVAILABLE：GPS 关闭、飞行模式、无网络、室内信号弱导致系统无法生成坐标 -
error.code === error.TIMEOUT：默认超时是 Infinity，不设timeout选项会导致界面卡死，建议强制设为5000（5 秒） - 别依赖
error.message文本——Chrome 返回User denied geolocation prompt，Safari 可能为空字符串，Firefox 又不同
拿到 position.coords 后，怎么判断坐标能不能用
经纬度数字本身没意义，关键看精度字段：position.coords.accuracy 是水平误差半径（单位：米），它决定了结果是否可信：
- 值
<= 20：GPS 开启且开阔地，可直接用于导航或距离计算 - 值在
50–100：WiFi 定位为主，适合“附近商家”类场景，但不宜做路径规划 - 值
> 100：大概率是基站粗略定位，应提示“定位精度较低，结果仅供参考” -
typeof position.coords.accuracy !== 'number'才算真正缺失精度——有些旧版 Firefox 不返回该字段，不能用=== null判断 -
position.coords.altitudeAccuracy大多为null，别拿它做海拔相关逻辑
watchPosition 不是实时轮询，别当 GPS 追踪器用
navigator.geolocation.watchPosition 的行为容易误解：它不会每秒触发，而是由系统底层决定何时通知变化。典型触发条件包括坐标偏移超过 accuracy、精度提升、或设备从室内移到室外。
这意味着：
- 不适合车辆轨迹跟踪、运动计步等高频更新需求
- 重复调用
watchPosition而不存 ID，会导致多个监听器累积，必须用clearWatch主动释放 - 如果需要更高频更新，得结合
DeviceOrientation或加速度计数据做插值，但跨浏览器兼容性极差
真正难的不是调通 API，而是把 accuracy、timeout、maximumAge 和 error 分流揉进业务逻辑里——多数失败不在代码，而在用户手机设置、网络环境、甚至当天天气。
