css媒体查询是响应式主力，js仅补位；应优先用matchmedia监听断点变化，避免滥用resize；resizeobserver更精准观测元素尺寸变化，提升性能与可靠性。
JavaScript 本身不直接实现响应式设计，CSS 媒体查询才是响应式的主力；JS 的作用是补位——监听视口变化、动态调整 DOM 或触发重绘逻辑，但必须谨慎使用，否则容易破坏可访问性与性能。
用 window.matchMedia 监听媒体查询状态变化
比监听 resize 事件更精准、更语义化，且能避免频繁触发。它直接反映 CSS 媒体查询的匹配结果，支持监听变更。
- 适用于判断断点是否激活（如
"(max-width: 768px)"），而非获取具体像素值 - 必须调用
mql.addListener()（旧版）或mql.addEventListener("change", ...)（新版）才真正监听，仅调用mql.matches只取当前快照 - 注意在组件卸载或销毁时移除监听器，否则造成内存泄漏
const mql = window.matchMedia("(max-width: 768px)");
function handleMobileChange(e) {
if (e.matches) {
document.body.classList.add("mobile");
} else {
document.body.classList.remove("mobile");
}
}
mql.addEventListener("change", handleMobileChange);
handleMobileChange(mql); // 立即执行一次，确保初始状态正确
慎用 resize 事件监听视口尺寸
它会高频触发（尤其拖拽窗口时），直接在里面写 DOM 操作或计算极易卡顿。不是不能用，而是必须节流 + 明确目的。
- 不要在
resize回调里反复读取window.innerWidth或操作样式 —— 浏览器可能尚未完成重排，导致强制同步布局 - 如果只是为了适配 Canvas、SVG 或第三方图表库（如 Chart.js）的容器尺寸，优先用
ResizeObserver - 移动端 Safari 中，
resize在键盘弹出/收起时也会触发，可能误判“视口变小”
用 ResizeObserver 观察元素级尺寸变化
比监听全局视口更合理：响应式常是“某个容器宽了，里面的内容就要换行/隐藏/重排”，而不是整个页面跟着窗口像素跳变。
立即学习“Java免费学习笔记（深入）”；
- 只在目标元素实际发生几何变化时回调，不依赖窗口事件，更可靠
- 不观测滚动或 CSS transform 变化，只响应盒模型尺寸（content-box）改变
- 需兼容处理：IE 完全不支持，Safari 13.1+ 才支持
observe(rootMargin)，旧版本建议降级为setTimeout+ 尺寸轮询（仅必要时）
const ro = new ResizeObserver(entries => {
for (const entry of entries) {
const { inlineSize, blockSize } = entry.contentBoxSize[0] || entry.contentRect;
if (inlineSize < 480) {
entry.target.dataset.layout = "compact";
} else {
entry.target.dataset.layout = "default";
}
}
});
ro.observe(document.querySelector(".card-grid"));
JS 响应式逻辑和 CSS 必须协同，不能割裂
常见错误是 JS 强行设置 style.width 或切换 class，却没在 CSS 中定义对应规则，或者规则被更高优先级的媒体查询覆盖。
- JS 控制的 class（如
.is-collapsed）必须在所有相关断点中明确定义行为，不能只写在@media (min-width: 1024px)下 - 避免用 JS 修改
display、visibility来“替代”媒体查询隐藏元素——这会让屏幕阅读器无法感知，也增加维护成本 - 动画类（如
.fade-in）若由 JS 添加，要确认其 CSS 过渡属性未被媒体查询中的prefers-reduced-motion阻断
真正难的不是监听到变化，而是判断“此刻该做什么”。比如横屏切换时，是重排网格？还是暂停视频？或是加载高清图？这些决策必须基于内容语义，而不是单纯像素阈值。漏掉这一点，JS 响应式就只是视觉抖动的源头。
