断点应基于真实设备分布和内容容器需求选择，优先用min-width实现移动优先渐进增强，通过DevTools观察内容挤压宽度确定具体值，避免硬套设备分类或过时数值，注意JS与CSS媒体查询同步问题。
media query 的断点数值怎么选
断点不是凭感觉填的，得看真实设备分布和内容容器的实际需求。主流框架（比如 Bootstrap）用 768px、992px、1200px 是历史惯性，但你的页面布局撑不开时，768px 可能早该换成了 640px 或 600px。
推荐做法是：先写移动版，等内容开始“挤”或“错位”时，记下此时浏览器宽度（DevTools 里拖动窗口看右上角数字），那个值就是你真正的断点。别硬套“平板”“桌面”这种设备分类——max-width: 640px 比 max-width: 767px 更贴近小屏安卓的真实触发点。
- 避免用
480px、320px这类过时值，现在几乎没有主流设备在这些宽度下还靠 viewport 缩放来显示网页 - 多个断点之间留至少
1px间隔，比如(max-width: 639px)和(min-width: 640px)，防止媒体查询重叠或遗漏 - 如果用 CSS-in-JS 或 PostCSS，确保插件没把
em断点自动转成px后出偏差（1em在根字体变化时会漂移）
用 min-width 还是 max-width
优先用 min-width，它更符合“移动优先”的渐进增强逻辑：基础样式默认适配小屏，再一层层加宽屏规则。用 max-width 容易漏掉中间状态，比如只写了 (max-width: 767px) 和 (max-width: 1199px)，那 1200px 以上反而没样式接管。
-
min-width写法清晰：从窄到宽，每段规则只管“≥某个宽度”的情况 - 混合用会混乱，比如同时存在
(max-width: 767px)和(min-width: 768px)，一旦断点值不一致就留空隙 - 打印样式或特殊场景才考虑
max-width，比如@media print或临时 hack 某个旧版 Safari bug
断点命名要不要抽象成变量
可以，但别过度封装。用 CSS 自定义属性（--breakpoint-sm）比 Sass 变量更灵活，也方便 JS 读取；但直接在 @media 里写 (min-width: var(--breakpoint-md)) 会失效——CSS 不支持在媒体查询中使用变量。
立即学习“前端免费学习笔记（深入）”；
- 正确做法：用预处理器（如 Sass）生成断点，或者用 JS 注入
style标签动态写死媒体查询 - 如果项目用 Tailwind，
sm、md这些名字只是语义占位符，实际值还是得在tailwind.config.js里配成具体像素 - 别为了“可维护”把断点全塞进一个 JSON 文件再通过构建脚本注入——改个
lg值要跑一遍构建，调试成本远高于直接改 CSS
JS 检测断点和 CSS 同步的问题
CSS 媒体查询和 JS 的 window.matchMedia() 不一定实时同步，尤其在 iOS Safari 横竖屏切换、缩放或触发虚拟键盘时，matchMedia 的 matches 属性可能滞后一帧，导致 JS 判断和真实样式不一致。
- 不要用
matchMedia().matches直接控制 class 切换，改用监听change事件 +requestAnimationFrame延迟执行 - 如果只是做简单开关（比如隐藏某按钮），优先用纯 CSS：用
@media (max-width: 639px) { .btn--desktop { display: none; } } - 服务端渲染（SSR）项目更要小心：Node 环境没有
window，matchMedia会报错，必须加typeof window !== 'undefined'守卫
768px 该折叠，但侧边栏觉得 820px 才该收起。这时候得统一用容器宽度（container 元素的 offsetWidth）代替视口宽度判断，而不是盯着 screen.width 或 innerWidth 硬刚。 
