浏览器能读电量：便利与隐私的拉锯战

一个开发者在周末随手写了个 demo——用浏览器电量显示皮卡丘进化形态。这背后藏着个被大多数前端忽略的 API，以及一场关于"功能优先还是隐私优先"的浏览器战争。

四行代码就能拿到设备电量

这位叫 Bueno 的开发者想展示 Web API 的潜力。他选了个冷门的切入点：电池状态接口（Battery Status API，电池状态应用程序接口）。

代码极简。调用 navigator.getBattery() 返回一个 Promise（异步操作对象），解析后得到 BatteryManager（电池管理器）对象。四个属性：电量百分比、是否充电、充满剩余时间、耗尽剩余时间。四个事件监听：电量变化、充电状态变化、两个时间估算变化。

「没有库，没有框架，浏览器主动推送更新，你的函数只在真实变化时执行。」Bueno 这样总结。

这意味着什么？网页能根据用户电量自动切换主题、暂停后台任务、或者像这个 demo 一样——低电量时显示皮卡丘的疲惫形态。硬件能力直接暴露给前端，零依赖、零认证、零网络请求。

Firefox 和 Safari 为什么故意禁用

但打开 Firefox 或 Safari，这个 demo 直接失效。不是技术做不到，是故意不做。

Mozilla 的决策有篇论文支撑。研究人员发现，电池读数组合起来是极稳定的设备指纹：电量百分比 + 充放电时间，足以在同一设备的多个浏览器间追踪用户，无需 Cookie、无需本地存储。Bueno 转述了 Mozilla 的立场：「真正的两难——有用的设备数据 vs 被动指纹攻击向量。Mozilla 优先隐私，Chromium 优先功能。」

这是个罕见的公开分歧。通常浏览器兼容性差异源于实现进度，这次是故意的价值排序不同。Chromium 系（Chrome、Edge、Opera 等）选择保留能力，Firefox 和 Safari 选择切断风险。

Bueno 的应对很务实：「如果你用这个 API 开发，必须做降级处理。」他的代码里加了检测——if (!('getBattery' in navigator)) 时显示备用界面。不是优雅降级，是硬中断。

产品视角：为什么这个 API 值得关注

对做 Web 应用的人来说，这是个被低估的交互维度。

想象几个场景：视频会议软件检测到用户电量低于 20% 且未充电，自动关闭视频只保留音频；PWA（渐进式网页应用，一种可离线运行的网页技术）在电量危急时暂停同步任务；阅读类应用在低电量时预加载下一章而非整本。这些都不需要用户手动设置，是系统级的体贴。

但代价是真实的。指纹攻击不是理论威胁，是已验证的研究成果。Bueno 提到的论文显示，电池读数足以跨会话、跨浏览器识别同一设备。对广告追踪行业来说，这是比 Cookie 更顽固的标识符——用户清不掉，因为不是存的，是算的。

这就解释了为什么苹果和 Mozilla 宁可牺牲功能完整性也要封禁。它们的用户画像里，隐私敏感型用户占比更高，功能缺口是可接受的代价。

Chromium 的保留则反映了另一套计算：开发者生态的吸引力、Web 平台与原生应用的能力差距、以及 Google 自身的商业利益（广告业务需要追踪能力，尽管官方理由是功能完整性）。

给开发者的实际建议

如果你考虑在生产环境用这个 API，有几件事必须做。

第一，检测存在性。Bueno 的代码模板是对的——不要假设 API 可用，约 30% 的用户浏览器会走进 else 分支。

第二，设计有意义的降级。不是隐藏功能，而是替换为等效体验。电量未知时，默认保守策略：假设低电量，关闭耗电功能，让用户手动开启。

第三，评估业务场景是否真的需要。如果只是为了"酷炫"，成本收益不成正比。如果涉及离线能力、关键任务续航管理，这个 API 是原生应用之外唯一的选择。

最后，关注标准动向。Battery Status API 目前处于不稳定状态，W3C（万维网联盟，网页技术标准组织）的规范文档有弃用警告。Chromium 的坚持可能是暂时的，如果隐私压力持续，全面封禁并非不可能。

Bueno 的皮卡丘 demo 是个轻巧的引子，但它戳中了一个核心张力：Web 平台的能力扩张与隐私保护之间的永恒博弈。每个新 API 都在重新定义这条边界，而开发者的选择——用或不用、怎么用——会累积成平台的最终形态。

去 Bueno 的 GitHub 仓库看看代码，或者直接在 Chrome 里打开他的 demo。亲手试一次，比读十篇分析更能理解这个 API 的边界在哪里。