捕获 screen wake lock 的异步错误，核心在于对 navigator.wakelock.request() 返回的 promise 使用 .catch() 或 try...catch 块。由于该 api 在请求锁定时可能因权限被拒、设备不支持或系统中断而失败，必须为调用处提供错误处理逻辑，否则未处理的拒绝会导致控制台报错并影响后续代码执行。
wakeLock.request() 在不同权限状态下的具体表现是什么
当页面尝试获取屏幕常亮锁时，浏览器会根据当前权限策略和上下文环境决定是立即成功、弹出授权请求还是直接拒绝。如果用户未授予权限或设备处于省电模式且不支持唤醒，Promise 会进入拒绝状态，此时需要捕获具体的 SecurityError 或 NotAllowedError 以区分原因。
const wakeLock = await navigator.wakeLock.request('screen').catch((error) => {
console.error('Wake Lock failed:', error.name, error.message);
// 处理失败逻辑，如降级显示提示
});
if (wakeLock) {
console.log('Screen is now kept awake');
}
上述代码展示了最基础的捕获方式。在实际开发中，建议将 request 调用包裹在 try...catch 中，以便更清晰地分离成功与失败路径。例如，当 error.name 为 NotAllowedError 时，通常意味着用户明确拒绝了权限；若为 SecurityError，则可能发生在非安全上下文（如 HTTP）中。通过检查这些属性，开发者可以针对性地调整 UI 反馈或引导用户开启权限。
立即学习“Java免费学习笔记（深入）”；
如何确保 Wake Lock 释放时的错误也能被正确捕获
释放 Wake Lock 同样是一个异步操作，调用 wakeLock.release() 也会返回一个 Promise。虽然释放操作通常不会抛出严重错误，但在某些极端情况下（如对象已被销毁），仍可能触发异常。因此，释放逻辑也应包含错误处理，以防止静默失败导致的状态不一致。
async function releaseWakeLock(lock) {
try {
if (lock) {
await lock.release();
console.log('Wake Lock released successfully');
}
} catch (error) {
console.error('Failed to release Wake Lock:', error);
}
}
releaseWakeLock(wakeLock);
结合前面的请求逻辑，完整的生命周期管理应包含请求、保持和释放三个阶段。在释放阶段，即使没有发生错误，也建议显式地将引用置为 null，以便垃圾回收器能够及时清理资源。此外，监听 visibilitychange 事件并在页面隐藏时自动释放锁，是避免电池耗尽的最佳实践，这一过程同样需要确保错误被妥善记录而非忽略。
当 Wake Lock 因系统中断而失效时程序该如何响应
除了初始请求失败，Wake Lock 还可能在运行期间因系统策略变更（如用户手动关闭省电模式、切换应用或设备休眠）而意外释放。这种“中断”并非通过 Promise 的拒绝来通知，而是通过 release 事件的触发来告知。因此，程序必须监听 wakeLock.onrelease 回调，以便在锁意外丢失时重新申请或更新 UI 状态。
以下代码演示了如何同时处理初始请求错误和运行时中断：
let wakeLock = null;
async function requestWakeLock() {
try {
wakeLock = await navigator.wakeLock.request('screen');
wakeLock.addEventListener('release', () => {
console.log('Wake Lock was released');
wakeLock = null;
// 可选：在此处重新请求或提示用户
});
} catch (err) {
console.error('Initial request failed:', err);
}
}
requestWakeLock();
通过这种方式，程序不仅能应对启动时的权限问题，还能动态适应运行时的环境变化。关键在于区分“请求失败”和“锁已释放”两种状态，前者属于初始化错误，后者属于运行时状态变更，两者需要不同的处理策略。例如，在锁释放后，可以再次尝试请求，但需设置重试限制以避免无限循环。
