屏幕该亮的时候黑了，你以前只能写原生代码——今天浏览器自己会管了

你有没有遇到过这种情况：在厨房里照着手机屏幕做菜，手沾满了面粉，屏幕黑了；视频会议到一半切出去查资料，回来发现会议已经自动结束了；展示二维码让对方扫，屏幕突然息屏。这些场景的共同点是——你不想让屏幕变暗，但以前除了装一个原生 App，似乎没有别的办法。

这件事，浏览器自己会做了。

Screen Wake Lock API 从 Chrome 84 开始支持，到 2026 年已经覆盖全球 94% 以上的设备。Chrome、Edge、Opera 从 84 版本就支持，Safari 从 16.4 开始支持，Firefox 从 126 版本支持，移动端 Chrome 从 84 开始支持，iOS Safari 从 16.4 开始支持。这意味着，只要用户使用近两年内更新过的手机浏览器，你就可以用几行 JavaScript 实现「屏幕永不息屏」的功能。

它的用法非常简单：

// 请求屏幕常亮
const wakeLock = await navigator.wakeLock.request("screen");

// 监听释放事件（比如页面切换到后台时自动释放）
wakeLock.addEventListener("release", () => {
  console.log("屏幕常亮已释放");
});

// 需要时手动释放
wakeLock.release();

一个典型的场景是在页面可见性变化时自动重新请求常亮：

document.addEventListener("visibilitychange", async () => {
  if (document.visibilityState === "visible") {
    await navigator.wakeLock.request("screen");
  }
});

这样做的好处是：用户切到其他标签页再切回来，屏幕常亮会自动恢复，不需要你手动管理状态。

实际落地场景有哪些？最典型的是厨房菜谱应用——用户在照着步骤做饭，手是湿的或者沾了面粉，根本没法触碰屏幕，屏幕变暗非常烦人，加一段 Wake Lock 代码，用户进入菜谱页面后屏幕保持常亮，离开页面自动释放。

视频会议网页版也是常见场景。用户在开会时通常会同时开着笔记或者参考资料应用，当切换出去再回来时，会议可能已经因为屏幕息屏被系统中断了。接入 Wake Lock 可以让用户在切换标签页期间也能保持会议页面活跃。

展示二维码、演示 PPT、支付页面倒计时——这些场景都可以用 Wake Lock 来提升体验。

很多人会担心：这样不是会让手机非常耗电吗？这里有一个关键区别：Screen Wake Lock API 只阻止屏幕变暗和系统锁屏，不会阻止 CPU 进入休眠，也不会阻止页面被系统回收。Google 2026 年 3 月推出的 Play 商店新规重点打击的是原生 App 在屏幕关闭后继续持有唤醒锁、在后台持续消耗电量的行为——这和 Screen Wake Lock API 的机制完全不同。浏览器提供的这个 API 是为前台场景设计的，用户当前正在看的页面需要保持屏幕常亮，退出页面或者切换到后台时浏览器会自动释放这个锁，不会造成额外的电量消耗。

最后，有一个渐进增强的写法，让不支持的浏览器也能正常工作：

async function keepScreenAwake() {
  if ("wakeLock" in navigator) {
    const wakeLock = await navigator.wakeLock.request("screen");
    return wakeLock;
  }
  // 不支持的浏览器静默降级，不影响主流程
  return null;
}

对于绝大多数用户来说，这段代码不会运行到 return null 分支。但在极少数使用老版本浏览器的用户手机上，页面会正常工作，只是屏幕会按系统设置息屏——完全可接受的降级体验。

下一步：打开你的页面，找到用户最需要屏幕常亮的那个场景，加一行 navigator.wakeLock.request(“screen”)，把这件事收了。