当手机只剩 10% 电量，你的网页还在烧用户电量吗？

想象一个场景，用户在地铁上用手机浏览你的电商页面，突然屏幕变暗，系统弹出低电量警告。这时候如果你的网页还在疯狂加载高清大图、播放自动背景视频，恐怕下一秒用户就会关掉标签页，甚至产生抵触情绪。为了提升这种极端场景下的体验，很多开发者曾寄希望于 JS 电池状态 API。

这个接口允许前端获取设备的剩余电量百分比、是否正在充电以及充电速率等数据。听起来很美好，代码实现也不复杂。在兼容的浏览器环境中，我们只需要调用 navigator.getBattery() 方法，它会返回一个 Promise 对象。拿到返回值后，就能订阅 levelchange（电量变化）或 chargingchange（充电状态变化）事件。

基于这些数据，我们可以设计一些巧妙的交互。例如检测到电量低于 20% 时，自动暂停所有非必要的后台动画脚本；或者引导内容流切换为灰度显示，适配 OLED 屏幕的像素级熄屏特性以达到物理省电目的。在充电状态下，甚至可以适当提升加载质量，给用户更丰富的视觉反馈。

但是，作为实际开发中踩过坑的人，必须严肃提醒一句：千万别把核心业务逻辑完全绑定在这个功能上。浏览器生态对隐私保护的收紧，直接动摇了它的根基。从 Chrome 89 版本开始，谷歌出于防止设备指纹追踪的考量，正式移除了对该 API 的支持。目前市面上主流的 Chromium 内核浏览器基本都屏蔽了这项能力，Firefox 保留支持但也做了诸多限制，Safari 则从未真正跟进。这意味着，如果你写的代码没有做完善的降级处理，大部分安卓和 PC 用户根本拿不到这些敏感信息，前端控制台甚至会直接报错。

面对这种情况该怎么破局？与其执着于获取精确电量，不如转向更通用的性能优化策略。比如利用 window.navigator.connection 来感知网络状况，网速差时默认减少资源请求。对于省电需求，可以在设置栏提供一个显性的“低功耗模式”开关，由用户主动触发。这样既规避了隐私权限风险，又给了用户掌控感。

如果团队评估后依然决定尝试电池检测，务必加上严格的特性检测：检查 if ('getBattery' in navigator)，确保在不支持的浏览器上不会抛出异常中断执行。同时要注意，频繁监听电池变化事件其实也会消耗 CPU 资源。正确的做法是在页面可见性改变（visibilitychange）时重置监听，或者设置合理的去抖间隔。毕竟，我们优化的初衷是为用户省电，不能因为检测手段让用户手机热得更快。

技术没有绝对的对错，只有适不适合的场景。电池状态 API 曾经是个好东西，但在隐私合规大环境下，它更像是一个特定环境下的补充方案，而非通用标准。真正的用户体验优化，往往不需要窥探用户的硬件细节，而是做好基础的性能兜底、响应式图片加载和交互减负。当用户发现不用特殊设置也能流畅使用，那才是最高级的省电方案。