浏览器内置的许多功能其实早已存在，但大多数开发者要么从未接触，要么用过一次便抛之脑后。这次梳理的8个特性，看似不起眼，却在实战中屡次成为救命稻草。它们并不花哨，却能帮你减少大量依赖、少写许多 hack 代码，甚至直接颠覆你对“前端开发究竟该怎么做”的认知。

所以，别急着安装依赖。

先往下看。也许你会发现，这些年自己其实绕了不少弯路。

1. 输入框聚焦时，父元素也能响应变化

图片

为输入框本身添加聚焦样式，任何人都能做到。

难点在于，当你希望父容器也跟随变化时，事情就会变得棘手起来。

你可能会下意识想：“是不是得绑定事件监听？获取焦点时加一个 class，失去焦点时再移除？好像也不算太复杂？”

结果写着写着，几十行 JavaScript 就冒出来了。你只是想高亮一个容器，却突然开始怀疑自己到底在做什么。

其实，浏览器早已给出答案：:focus-within。

它的作用非常直观：只要容器内的任意子元素获得焦点，该容器本身就能被选中并应用样式。

.form-field {
  border: 1px solid #ccc;
  padding: 12px;
}
.form-field:focus-within {
  border-color: hotpink;
}


  

这类场景最常见的地方就是表单 UI。你原本只是想在使用者操作时让整块输入区域更加醒目，结果以前只能靠 JS 实现；现在，一条 CSS 规则就能搞定。

而且兼容性也很稳定，主流浏览器基本都没有问题。

2. 用户断网时，不一定要搭建一套庞大架构

只要你做过 PWA，或者接触过需要离线体验的 Web 应用，就一定思考过这个问题：用户突然失去网络，页面该如何应对？

可能他正在地铁里，可能他刚走进电梯，也可能只是家里的 Wi-Fi 又出了故障。

很多人一遇到这个问题，就容易往复杂的方向考虑：先搭建离线缓存系统，再实现请求重试层，然后补充本地队列，还要考虑失败回放和数据同步……

这些方案当然都有价值。但在你搬出整套重型架构之前，应该先问一个问题：浏览器最基础的能力，你用了吗？

浏览器原生提供了两个事件：online 和 offline。

你可以在网络状态变化时立即感知，并做出相应处理——比如提示用户、暂停请求、把操作临时存储到本地，或者等网络恢复后再同步。

window.addEventListener("offline", () => {
  alert("You are offline. Your internet is gone");
});
window.addEventListener("online", () => {
  alert("You're back. welcome back");
});

这个功能特别适合作为“先别慌”的第一层体验处理。

当然，有一个现实问题需要提醒：浏览器判断“在线”，并不等于你的后端服务一定可用。它只能说明设备看起来已联网。

但即便如此，这两个事件依然非常值得使用。因为在很多场景下，用户需要的并不是一套巨型架构，而是一个及时、明确、足够友好的反馈。

3. 现在别执行，等浏览器空闲时再执行

第一次见到这个 API 时，不少人觉得它有点鸡肋。它的意思大致是：“等浏览器空闲下来，再帮我执行这段代码。”

当时的第一反应往往是：“这有什么意义？代码本来就应该立即执行啊？”

后来慢慢才意识到，并非所有任务都必须马上完成。

有些事情根本不急。比如埋点统计、预加载、不影响首屏的数据处理，或者某些完全可以放在后台慢慢运行逻辑。

说白了，当页面正在渲染、组件正在更新、用户正在交互时，你不该让这些低优先级任务抢占主线程。

这正是 requestIdleCallback 最能发挥价值的场景。

它会把执行时机交给浏览器：什么时候空闲一点，什么时候不影响体验，再执行这段代码。

function showMessage() {
  console.log("? This ran when the browser was idle!");
}
if ("requestIdleCallback" in window) {
  requestIdleCallback(showMessage);
} else {
  setTimeout(showMessage, 0);
}

这类能力特别适合处理：分析和埋点、后台数据整理、可延迟的非关键任务、以及不应阻塞主线程的琐碎工作。

一旦你开始用“高优先级/低优先级”的视角看待前端任务，很多原本混杂在一起的逻辑都会变得清晰。

顺便提醒一句：Safari 目前还不完全支持，最好保留一个 fallback。

4. 动画的节奏，应该交给浏览器掌控

很多人第一次写动画时，都会先想到 setInterval。

比如，让一个盒子向右移动：

setInterval(() => {
  box.style.left = box.offsetLeft + 5 + "px";
}, 16);

它确实能动。而且刚开始看，似乎也没什么问题。

可只要时间一长，你就会慢慢发现：不够流畅，偶尔会卡顿，节奏不稳定，在某些设备上尤为明显。

问题在于，setInterval 根本不关心浏览器什么时候真正重绘。它只是粗暴地按照你设定的时间间隔去“猜测”——大约每 16ms 执行一次。

但浏览器的刷新节奏并非如此工作。

更合适的方式是 requestAnimationFrame。

function moveBox() {
  box.style.left = box.offsetLeft + 5 + "px";
  requestAnimationFrame(moveBox);
}
requestAnimationFrame(moveBox);

这两种写法的差异，表面看不大，实质上却很关键。

前者在说：“你每 16ms 执行一次吧，差不多就行。”后者在说：“当你准备重绘时，再帮我执行。”

而动画这种场景，真正需要的恰恰就是“跟随浏览器节奏”。一旦把执行时机交回给浏览器，流畅度通常会有明显改善。

5. 让组件根据自身容器，而非屏幕，决定如何变化

图片

这些年一提到响应式，大家第一反应基本都是媒体查询。它当然好用，而且过去确实解决了大量问题。

可问题是，媒体查询始终面向整个视口。而现实中的组件，很多时候并非铺满全屏。

比如一个卡片放在大屏幕的窄侧边栏里；又或者它被塞进宽页面的小区域中。这时，屏幕明明很宽，但组件本身却很拥挤。而你却还在根据 viewport 的尺寸做判断。

于是布局开始出现问题。接着你开始补充 hack。再然后，你开始怀疑是不是自己的响应式写法有问题。

其实你真正想表达的，往往不是“如果屏幕足够宽……”，而是“如果这个组件所在的容器足够宽……”

这就是 Container Queries 诞生的意义。它让组件能够根据自身容器的尺寸来响应，而不是永远盯着整个屏幕。

.card-wrapper {
  container-type: inline-size;
}
.card {
  display: grid;
  gap: 10px;
}
@container (min-width: 400px) {
  .card {
    grid-template-columns: 1fr 2fr;
  }
}

这样一来，同一张卡片放在不同位置，就能自然呈现不同的布局：在窄侧边栏里，它自动堆叠；在宽内容区里，它自动并排。无需额外判断，不用写一堆例外情况，也无需再问“为什么 iPad 上偏偏这里出问题了”。

这类能力真正提升的不是炫技程度，而是组件的独立性。你终于可以将组件写得更像组件，而不是“绑定在页面结构上的半成品”。

6. 别再拿 Math.random() 当唯一 ID 生成器了

很多人都写过类似这样的代码：

const uniqueId = Math.random().toString(36).slice(2);

看起来没有毛病。够短，够方便，够像随机，而且跑起来也确实能用。于是你就心安理得地把它放进了项目。

可问题在于，Math.random() 从来就不是为“生成可靠唯一 ID”而设计的。它的隐患不会立刻暴露，但始终存在：不是真正强随机，实现依赖浏览器引擎，可能出现模式性，时间久了碰撞概率会越来越难以忽视。

换句话说，它属于那种“刚开始看起来够用，等真出事时才发现不够”的类型。

浏览器其实早已提供更靠谱的方案：crypto.getRandomValues()

const bytes = new Uint8Array(8);
crypto.getRandomValues(bytes);
const uniqueId = Array.from(bytes)
  .map(b => b.toString(16).padStart(2, "0"))
  .join("");

这种方式更合理的原因在于：随机性更强，熵更高，模式更少，冲突概率更低。本质上，你是将“随机”这项任务交给了浏览器更专业的能力，而不是继续拿一个本不为此而生的函数硬撑。

尤其是当 ID 不只是前端临时使用，而是真正参与状态管理、节点映射、缓存或数据记录时，这种区别很容易成为线上 bug 与稳定系统之间的分界线。

7. 别一提到弹窗就先安装 Modal 库

图片

几乎每个项目都会走到这一步：“我们需要一个弹窗。”然后事情就会迅速失控。

安装库，调整 z-index，补充焦点管理，修复滚动穿透，再顺手处理 ESC 键、点击遮罩关闭、无障碍支持、层级冲突……最后你会发现，自己为了一个弹窗，忙得就像在造操作系统。

但现在，浏览器其实已经明确告诉你：这件事，我可以自己来。它给出的答案就是

Delete Account

  
⚠️ Delete Account
  
This action cannot be undone. Are you sure?
  

    Cancel
    Yes, Delete
  

const SpeechRecognition =
  window.SpeechRecognition || window.webkitSpeechRecognition;
const btn = document.getElementById("startBtn");
const box = document.getElementById("box");

if (SpeechRecognition) {
  const recognition = new SpeechRecognition();
  btn.onclick = () => {
    recognition.start();
  };
  recognition.onresult = (e) => {
    const text = e.results[0][0].transcript.toLowerCase();
    box.textContent = text;
    box.style.background = text;
  };
} else {
  btn.textContent = "Not supported ?";
}