真断点是页面内容“撑不住”或“挤不下”的临界宽度，如642px换行错位则取640px；应拖动DevTools滑块观察导航栏重叠、卡片跳列等崩坏现象，记下临界值后向上取整为920px等易维护数。
别照抄 768px、1024px 这些数字——你的页面在 642px 就开始换行错位，那 640px 才是真断点。
怎么找到自己页面该设的断点
断点不是设备参数表里的固定值，是你页面内容“撑不住”或“挤不下”的那一刻。打开 Chrome DevTools 的 Toggle device toolbar，拖动宽度滑块，眼睛盯住：导航栏文字是否重叠、两列卡片是否突然跳成单列、label 和 input 是否压在一起、textarea 高度是否缩到只剩一行。
- 记下那个“崩坏临界宽度”，比如看到侧边栏在 913px 宽时突然卡住不收，就记 913px
- 向上取整到好维护的数：913px →
920px或960px，避开 913px / 914px 这类易冲突边界 - 重点观察区域：导航栏折叠点、表单字段换行点、图片容器溢出点、字体行高突变导致的行距错乱
为什么必须用 min-width 而不是 max-width
用 min-width 是为了移动优先 + 渐进增强，逻辑更稳，也更少出 silent bug。
- 基础样式写在媒体查询外，所有设备兜底；大屏才加覆盖规则，不会漏掉新设备或特殊 UA
-
@media (max-width: 767px)和@media (min-width: 769px)中间空了 768px，这个宽度可能完全没样式管 - 多个
min-width规则天然叠加，后面能覆盖前面，不用靠!important或嵌套来抢权重 - 打印样式、暗色模式、用户缩放等原生上下文，
min-width更兼容
@media 里能不能用 CSS 变量（如 var(--breakpoint-md)）
不能直接用。主流浏览器和构建工具（PostCSS、Vite 默认 CSS 处理）都不支持变量在 @media 条件中展开。
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 写了
@media (min-width: var(--breakpoint-md))，浏览器会直接忽略整条规则，不报错也不生效 - Sass/Less 可以编译时替换，但输出仍是硬编码数字，跟“运行时动态断点”无关
- 真要复用数值，只建议在 JS 中读取（比如初始化轮播图时判断是否启用），别让它参与核心布局逻辑
- 如果非要集中管理，用预处理器变量比 CSS 自定义属性更稳妥
用 em 还是 px 写断点
推荐用 em，但前提是根字体没被 JS 强制重设。它随用户字号变化自适应，对缩放更友好。
- 换算方式：
768px ÷ 16px = 48em，所以写@media (min-width: 48em) -
rem在部分旧版 iOS Safari 有解析 bug，且依赖html根字体，用户缩放时可能让断点提前或延后触发 - 别为了“适配缩放”强行把所有断点转
rem——实际项目中，99% 的缩放问题靠弹性容器（%、max-width）和相对单位字体就能消化 - 如果用了
clamp()控制字体，断点用em会更连贯
最麻烦的从来不是写对语法，而是判断「这里内容到底撑不开还是挤不下」——这个点，设计稿不会标，设备列表里没有，只能靠你拖着滑块，一像素一像素地看。
