768px和1024px断点不合理，因其源自iPad初代物理分辨率而非视口宽度；应基于内容可读性设断点，如320px重排、480px启两列、64rem适配缩放，并优先用clamp()减少依赖。
为什么 768px 和 1024px 这两个断点被用烂了，但实际并不合理
因为它们源自 iPad 第一代的物理分辨率（768×1024），不是视口宽度，更不是用户真实浏览场景。现代移动端浏览器默认缩放、桌面端高 DPR 屏幕、折叠屏、竖屏笔记本都会让这些数值失效。
-
768px在 Chrome 桌面模拟器里常对应「平板横屏」，但在真实 iPad Pro 上，window.innerWidth可能是1024或1366（取决于 Safari 缩放和方向） -
1024px作为「桌面起点」在 125% 缩放的 Windows 笔记本上，1024px视口实际只占屏幕 1/3 宽度，内容早已挤得看不清 - 真正该盯的是内容容器的响应行为，而不是设备型号——比如导航栏是否换行、卡片是否从三列坍缩为两列
怎么用 @media (min-width) 设置真正可用的断点
从内容流出发，用「最小内容可读宽度」代替设备猜估。比如一个带图标+文字的按钮，最小安全宽度是 280px；一段正文段落，行宽超过 80ch 就该分栏。
- 基础移动断点设为
320px（iPhone SE 宽度），但仅用于重排最简结构，不加复杂样式 - 主内容断点建议从
480px开始：足够显示带图标的按钮、两列网格、不换行的标签组 - 大屏断点别硬套
1200px，改用min-width: 64rem（即1024px，但基于16px基准，适配缩放） - 避免嵌套多层
@media，优先用clamp()控制字体和间距，减少断点依赖
遇到 max-width 断点失效，先查这三件事
常见现象是「写了 @media (max-width: 767px)，但手机上看还是桌面样式」，大概率不是媒体查询写错了，而是视口或渲染链路出了问题。
- 确认
<meta name="viewport" content="width=device-width, initial-scale=1">存在且没被 JS 动态覆盖 - 检查父容器是否设置了固定
width或min-width，导致内部元素无法收缩到断点阈值以下 - 留意 CSS 优先级：如果用
!important强制了某条桌面样式，max-width规则可能被跳过（尤其在 Shadow DOM 或框架 scoped 样式中）
用 prefers-reduced-motion 和 prefers-color-scheme 补充断点逻辑
这不是替代屏幕尺寸断点，而是叠加一层用户意图判断。比如动画卡顿用户即使在大屏上也该禁用轮播；深色模式下某些背景色断点需要同步调整。
立即学习“前端免费学习笔记（深入）”；
-
@media (prefers-reduced-motion: reduce)下，把transition改成none，或把animation设为0.01s瞬切 -
@media (prefers-color-scheme: dark)不要只改文字颜色，检查所有用到background-image的地方——CSS 渐变需重写，SVG fill 需加currentColor - 这两个媒体查询支持度已很好（Chrome 76+/Safari 12.1+/Firefox 67+），但 IE 完全不支持，别指望降级 fallback
@media 都该对应一个具体的设计决策，而不是为了“适配所有设备”而堆砌。 
