navigator.wakelock.request() 直接报错主因是缺乏用户手势触发或调用时机不当；必须由 click 等明确交互启动，且需监听 release 事件、主动释放并兼容降级。
现代浏览器中，navigator.wakeLock 是唯一标准、无需插件、原生支持的屏幕常亮方案；但它不是“一调就亮”，必须满足用户交互触发 + 页面可见 + 不被系统策略拦截三个前提，否则会静默失败或抛出 NotAllowedError。
为什么 navigator.wakeLock.request() 直接报错？
绝大多数失败都卡在权限与时机上：该 API 被设计为“用户可感知、可中断”的能力，因此必须由明确的用户手势（如 click、touchstart）触发，且不能在页面加载完成时自动调用。
- ❌ 错误写法：
window.addEventListener('load', () => navigator.wakeLock.request('screen'))—— 无用户手势，直接拒绝 - ✅ 正确写法：绑定到按钮点击事件，例如
document.getElementById('keepAwake').addEventListener('click', async () => { const wl = await navigator.wakeLock.request('screen'); }) - ⚠️ 注意：Chrome 120+ 对后台标签页有更严限制，即使已获得锁，切到其他标签后可能被系统自动释放
如何安全地申请并维持屏幕唤醒锁？
不能只调一次 request() 就完事——锁可能因系统休眠、页面失焦、电源管理策略而意外释放，需监听 release 事件并做好重连准备。
- 保存锁引用：用
let wakeLock = null全局变量持有，避免重复申请或丢失控制权 - 监听释放：
wakeLock?.addEventListener('release', () => console.log('锁已被释放'))，便于日志追踪或 UI 状态同步 - 主动释放是必须的：离开关键流程（如视频播放结束、表单提交完成）时，务必调用
wakeLock?.release()，否则可能被浏览器强制回收，甚至影响后续申请 - 兼容性兜底：检查
'wakeLock' in navigator，不支持时降级为提示用户“请勿锁屏”，而非静默失效
移动端 Safari 和部分国产浏览器为什么不工作？
navigator.wakeLock 在 iOS Safari 完全不可用（截至 iOS 17.5），安卓端则依赖 WebView 内核版本：Chrome WebView 84+、Samsung Internet 14+ 支持，但很多厂商定制浏览器（如华为浏览器、小米浏览器）仍返回 undefined 或抛出 NotSupportedError。
- 不要依赖 UA 判断，应运行时检测：
if (!('wakeLock' in navigator)) { /* 启用备用方案 */ } - 真机测试比模拟器更可靠：Android 模拟器常误报支持，而真机受省电模式、后台限制影响更大
- 替代思路有限：iOS 上只能引导用户手动关闭自动锁屏（无 JS 干预手段），安卓低端机可尝试
setTimeout+ 页面可见性 API 模拟“伪常亮”（如定时滚动空白 div），但效果差且耗电，仅作最后退路
真正难的不是调用那行代码，而是判断“此刻是否允许锁屏”“用户是否还在看这个页面”“系统有没有偷偷把它收走”——这些状态无法靠一次 request() 覆盖，得靠持续监听和防御性释放来兜住。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
