截至2026年初，Chrome（120+）和Edge（120+）桌面版仍支持但已弃用navigator.getBattery()，移动端已移除；返回的BatteryManager中chargingTime/dischargeTime多为Infinity或NaN，仅level和charging属性基本可用。
不能直接用了，但部分浏览器仍能用，只是得先确认环境是否支持，且行为不可靠。
Chrome 和 Edge 还支持 navigator.getBattery() 吗？
截至 2026 年初，Chrome（120+）和 Edge（120+）在桌面版仍保留该 API，但已标记为“deprecated”，控制台会输出警告：getBattery() is deprecated and will be removed in a future Chrome version。移动端 Chrome（Android）早已移除，调用会直接 reject Promise。
- 桌面端调用成功后返回的
BatteryManager对象，chargingTime和dischargingTime多数情况下是Infinity或NaN，不可用于估算时间 -
level和charging属性在插电/拔电时基本可用，但低电量（如 levelchange 事件 - 无权限弹窗，也不需要用户授权，但受同源策略和 iframe sandbox 限制（
sandbox="allow-scripts"才可能工作）
Firefox 和 Safari 呢？
Firefox 自 2019 年起就彻底禁用该 API，调用 navigator.getBattery() 会直接抛出 TypeError: navigator.getBattery is not a function；Safari 从未实现过，连函数都不存在。
- 这意味着任何依赖
getBattery()的 H5 项目，在 Firefox 和 Safari 上会静默失败，不报错也不触发回调 - 没有降级方案可自动补全数据，只能靠 UA 判断后跳过逻辑，或改用其他信号（比如监听系统暗色模式切换、CPU 负载估算等间接指标）
为什么 W3C 不再推进 Battery Status API？
核心原因是隐私风险：攻击者可通过高频读取 level 变化 + 时间戳，构建用户使用画像（比如判断用户是否夜间活跃、是否常出差），W3C 认为其收益远低于潜在滥用成本。
- Chrome 团队在 2022 年明确表示不再修复该 API 的 bug，仅维持最小兼容
- 当前主流框架（如 React、Vue）的社区插件（如
use-battery）已停止维护，npm 上最新版本停留在 2021 年 - 替代方案不是“另一个标准 API”，而是转向平台原生能力：PWA 可通过
beforeinstallprompt引导用户安装后，用 TWA 或 Capacitor 桥接原生电池接口
现在还能做低电量适配吗？
能，但必须放弃“纯 Web”幻想，接受分层策略：
- 对 PWA 应用：优先使用
Capacitor的@capacitor/device插件，其getBatteryInfo()在 Android/iOS 上稳定返回level和isCharging - 对普通网页：只做轻量响应——检测到
navigator.getBattery存在且 resolve 成功时启用，否则默认按“非低电”处理，不阻断主流程 - 避免在关键路径（如支付页、表单提交）中依赖电池状态，它本就不该是功能开关，最多是体验优化开关
真正容易被忽略的是：即使 API 存在，levelchange 事件的触发频率由浏览器自主控制，Chrome 实际采样间隔常为 30–60 秒，根本无法支撑“电量跌到 15% 立即降级视频码率”这类实时响应需求。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
