配了三年地理位置，每次弹权限都被用户直接关掉——今天 Chrome 把这件事从根上解了

每次做地理位置功能，用户一看到弹窗就直接点拒绝——这个坑我踩了三年，今天发现浏览器自己把它从根上解了。

navigator.geolocation.getCurrentPosition() 这个 API 是”命令式”的：你的 JS 调用它，浏览器决定弹不弹权限窗，用户莫名其妙就被要求交出位置。如果用户之前关过几次，Chrome 会静默拦截，根本不弹窗——你的代码拿到的只有一块空白，什么 error 都拿不到。

这个静默拦截的坑，Google 自己测出来的数据是：被拦截过的用户，靠传统 JS API 基本找不回来。

Chrome 144 给了一个完全不同的思路：一个 HTML 标签，<geolocation>，它自己就是个按钮，用户点它，这件事本身就是权限信号。

<geolocation accuracy-mode="precise">
  获取我的位置
</geolocation>

<script>
  document.querySelector('geolocation').addEventListener('location', e => {
    const { latitude, longitude } = e.target.position.coords;
    console.log(latitude, longitude);
  });
</script>

用户点这个按钮 → 浏览器知道用户有明确意图 → 权限窗口出现。这个顺序是天然的，意图是清晰的，静默拦截的概率大幅降低。

具体来说，这个元素有几个关键属性：

• accuracy-mode="precise" 拿精确坐标，="approximate" 拿城市级模糊位置，用户自己选，对隐私敏感场景更友好
• watch 属性持续跟踪位置，等价于 watchPosition()
• autolocate 如果用户之前已经授权过，页面加载完直接触发 location 事件，不需要再点一次
• onpromptaction / onpromptdismiss 事件让你知道权限窗口什么时候弹、什么时候被用户关掉——这是传统 API 完全拿不到的信息
• CSS 伪类 :granted 可以直接用 CSS 控制授权后的样式，完全不需要 JS

实际数据怎么样？

Google 在 Chrome 126~143 期间做了大规模灰度测试，对比传统 JS API：

• Zoom（摄像头/麦克风场景）：错误率下降 46.9%，用户卡在”系统级拦截”的情况大幅减少
• Immobiliare.it（房产网站）：地理位置流程成功率提升 20%
• ZapImóveis（巴西房产平台）：被之前拒绝过的用户，用新元素后 54.4% 成功恢复授权

这几个数字说明一件事：不是用户不想给位置，是传统弹窗的体验让用户本能拒绝。换了按钮之后，同样的用户，愿意给了。

生产怎么用？

注意，目前只有 Chrome 144+ 支持，其他浏览器还没跟。所以要写 fallback：

<geolocation accuracy-mode="precise" id="loc-btn">
  获取我的位置
</geolocation>

<script>
  const geoEl = document.getElementById('loc-btn');

  if ('geolocation' in HTML Elements) {
    geoEl.addEventListener('location', e => {
      const { latitude, longitude } = e.target.position.coords;
      renderMap(latitude, longitude);
    });
    geoEl.addEventListener('error', e => {
      console.error(e.target.error.message);
    });
  } else {
    navigator.geolocation.getCurrentPosition(
      pos => renderMap(pos.coords.latitude, pos.coords.longitude),
      err => console.error(err.message)
    );
  }
</script>

一个重要限制：每个页面最多三个 <geolocation> 元素，超过的话全部停止工作。多个位置需求建议合并到一个按钮内。

这件事的格局

2022 年的 <dialog>，2024 年的 <popover>，2025 年的 <details> 分组，再到今年的 <geolocation> —— HTML 正在系统性地把”本来需要 JS 来触发权限或交互”的场景，一件一件收回去。

这不是某个框架的特性，是浏览器自己在变。对跨端开发者来说，以前要在 Web、iOS、Android 上各自实现一套地理位置逻辑，现在 Web 这边的体验终于可以原生、不尴尬了。

下一步：如果你的应用里有地理位置功能，把 <geolocation> 元素加进去，同时保留 JS API 兜底。渐进增强，慢慢切——用户体验的提升，值这个迁移成本。