媒体查询的width指视口宽度而非容器宽度，@media(width:300px)无法响应div尺寸变化；应基于视口断点设计，优先使用移动优先和min-width，避免混用min/max-width，容器查询才适用于组件级响应式。
媒体查询中的 width 是视口宽度，不是页面容器宽度
很多人写 @media (width: 768px) 期望匹配某个 div 的宽度，结果完全不生效——因为 CSS 媒体查询的 width 指的是 viewport 的宽度（即浏览器可视区域），和 DOM 元素无关。它等价于 min-width / max-width 的断点判断，但不能响应式监听某个组件的尺寸变化。
常见错误现象：
- 在
div#sidebar上设了width: 300px，却用@media (width: 300px)试图触发样式 —— 不会触发 - 用
window.innerWidth测出 768，但媒体查询没生效 —— 可能是缩放、设备像素比或 meta viewport 缺失导致视口实际宽度不符
正确做法是明确基于视口断点设计布局流：
@media (max-width: 767px) {
.header { display: none; }
.nav-mobile { display: block; }
}
min-width 和 max-width 的优先级与书写顺序有关
CSS 媒体查询本身没有“覆盖优先级”，但规则生效取决于选择器权重 + 书写顺序。当多个媒体查询同时满足时，后写的规则会覆盖先写的（同权重下）。
使用场景建议：
立即学习“前端免费学习笔记（深入）”；
- 用移动优先：先写基础样式（小屏），再用
@media (min-width: 768px)逐级增强 - 避免混用
min-width和max-width在同一断点区间（如同时写(min-width: 768px)和(max-width: 767px)），容易因四舍五入或缩放导致空隙或重叠 - 断点值建议统一用 rem 或 px，别混用；
48em≈768px（假设 base font-size=16px），但需确认根字体是否被修改
动态调整布局时，别只靠媒体查询 —— 容器查询更精准
如果目标是“当侧边栏容器变窄时隐藏子项”，媒体查询无能为力，必须换方案：
-
@container（需启用实验性支持或现代浏览器）：直接监听父容器宽度@container (width < 300px) { .sidebar-item { display: none; } } - JavaScript +
ResizeObserver：监听元素尺寸变化，动态加 classconst ro = new ResizeObserver(entries => { entries.forEach(entry => { entry.target.classList.toggle('narrow', entry.contentRect.width < 300); }); }); ro.observe(document.querySelector('.sidebar')); - Flex/Grid 内置响应能力：用
flex-wrap、minmax()、auto-fit等减少对媒体查询的依赖
移动端适配常被忽略的三个硬性前提
媒体查询能否正常工作，依赖底层环境是否就绪：
-
必须存在，否则 iOS Safari 会以 980px 视口渲染，max-width: 768px永远不匹配 - PC 浏览器缩放会影响
width媒体查询判断（如缩放到 125%，原本 1200px 视口变成 960px），测试时务必重置缩放（Ctrl+0） - 部分安卓 WebView 或旧版 UC 浏览器不支持
@container或某些单位（如vh在微信内置浏览器中可能异常），需降级 fallback
复杂点在于：视口宽度 ≠ 设备宽度 ≠ 逻辑像素宽度 ≠ CSS 像素宽度。调试时优先用浏览器开发者工具的「Toggle device toolbar」并选中「Responsive」模式，手动拖动宽度看断点是否准确触发。
