HTML函数在低电压环境下自动关机吗？供电不稳影响分析
开门见山地说，HTML压根没有所谓的“函数”能控制关机，更不会因为低电压就自动关机——这其实是一个关于Web技术边界的常见误解。 真正的关机行为，是由硬件电源管理模块（比如PMIC）或者操作系统内核（像Linux的poweroff、Windows的ACPI事件）来响应的，它们负责处理物理电压跌落这类底层事件。浏览器和HTML完全被隔离在这个权限之外，根本碰不到这些核心能力。
为什么 HTML 和 Ja vaScript 无法感知低电压
道理很简单：浏览器运行在一个由操作系统精心打造的“沙箱”环境里。所有涉及硬件的输入输出操作，包括电源状态，都被严格隔离了。想象一下，即便设备因为电压不足已经触发了硬件复位，浏览器里的document对象早就灰飞烟灭了，连window.addEventListener('beforeunload')这种告别事件都来不及执行。
- Web API 没有提供相关接口：你找不到任何能直接读取电池电压、电源状态或者触发关机的Web API。即便是曾经存在的
na vigator.getBattery()也已被废弃，而且它最多只能告诉你充电/放电状态，给不出具体的电压数值。 - 网络请求会无声中断：当断电瞬间，
XMLHttpRequest或fetch这类网络请求会在毫秒级内被掐断，根本不会抛出一个可以让你捕获的“低电压错误”。 - 概念澄清：所谓的“HTML函数”本身就不成立。HTML是标记语言，负责结构描述，它本身不包含可执行的逻辑代码。
实际供电不稳时，前端可能观察到的现象
虽然电压波动不会让你的页面去“调用关机函数”，但它会通过影响整个系统，间接地在前端运行时表现出来，这些现象往往颇具迷惑性：
- 性能卡顿：CPU因供电不足而降频，直接导致
requestAnimationFrame动画掉帧，setTimeout定时器的延迟也会显著增大。 - 进程突然消失：内存供电不稳，可能引发浏览器进程被操作系统的OOM killer（内存溢出杀手）直接终止。用户看到的就是页面突然白屏，然后直接退回桌面，控制台里连条Ja vaScript错误日志都留不下。
- 渲染异常：在使用USB-C/Type-C供电不稳的场景下，外接显示器可能出现闪屏，连带导致Chrome的渲染线程卡死，控制台可能会报出
GPU process crashed这样的错误。 - 状态异常切换：在一些嵌入式设备（比如树莓派运行Chromium信息亭模式）上，当输入电压低于某个阈值（如4.65V）时，
document.visibilityState可能会异常地切换为hidden。但这只是渲染进程崩溃后产生的副产物，并非页面主动检测到了电源状态。
需要监测电源状态时的可行路径
如果你的业务场景确实需要应对供电风险（例如工业HMI界面、车载终端），那就必须跳出浏览器的限制，采用原生集成的方案：
立即学习“前端免费学习笔记（深入）”；
- Linux设备：可以通过轮询
/sys/class/power_supply/目录下的voltage_now文件来获取电压（通常需要root权限）。然后配合systemd服务监听变化，并通过dbus将通知发送到像Electron这样的应用主进程。 - Windows IoT：可以调用
Win32_BatteryWMI类，利用Node.js的win32api这类模块来读取EstimatedVoltage等信息。 - Android WebView：需要自定义
WebViewClient，在Ja va层监听BatteryManager的系统广播，然后通过addJa vascriptInterface将封装好的安全方法暴露给前端Ja vaScript调用。 - 重要提醒：绝对要避免在网页中尝试执行类似
exec('sudo shutdown -h now')这样的命令。浏览器没有shell权限，而且这类命令在容器化环境（如Docker/K8s）中根本不可用。
说到底，真正决定设备是否关机的，是主板上一颗小小的电压监控芯片（比如TI的TPS65912）输出的PWR_GOOD信号。这个信号在电压异常时拉低的速度，比任何Ja vaScript代码的执行都要早上几百微秒。所以，你写的那个onbatterychange回调函数，永远也等不到真正掉电的那一次事件通知。
