媒体查询必须写在CSS文件或标签内，配合viewport meta标签使用；应采用min-width移动优先策略，按320px/768px/1024px内容驱动设断点；CSS变量需在媒体查询内重定义：root；支持暗色模式、打印等场景。
媒体查询怎么写才生效
媒体查询必须放在 CSS 文件里（或 <style></style> 标签内），不能只靠 HTML 的 viewport meta 标签撑场面。常见失效原因是没加 meta name="viewport"，或者写了但写错了——比如漏了 content="width=device-width, initial-scale=1"。
关键点：
-
@media规则要写在样式规则外层，不能嵌套在类名或 ID 选择器内部（CSS 原生不支持嵌套媒体查询） - 断点值建议用设备实际视口宽度，不是物理像素，优先参考
min-width而非max-width（更利于移动优先） - 避免用
device-width，它匹配的是设备屏幕物理宽度，容易在缩放、横竖屏切换时出错；一律用width或min-width
移动端优先的断点怎么设才合理
别一上来就抄 Bootstrap 的 576px / 768px / 992px。真实项目里，断点应该由内容决定，不是设备决定。比如一个卡片组件在宽度小于 400px 时文字换行难看，那就设 @media (max-width: 399px) 来调字体大小或 padding。
推荐基础三档（单位全用 px，避免 em 或 rem 在媒体查询中引发计算歧义）：
立即学习“前端免费学习笔记（深入）”；
-
@media (min-width: 320px)—— 默认样式，针对小屏手机 -
@media (min-width: 768px)—— 平板横屏/大屏手机，改栅格列数或隐藏次要导航 -
@media (min-width: 1024px)—— 桌面端，启用侧边栏、固定定位、多栏布局
注意：不要为“iPhone 14 Pro Max”单独写媒体查询，它的视口宽度仍是 430px（竖屏），和旧机型逻辑一致。
用 max-width 还是 min-width？
用 min-width 更可靠。因为它是“从窄到宽逐步增强”，符合渐进式适配逻辑，也方便配合 CSS 自定义属性做响应式变量控制。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
反例：@media (max-width: 767px) 容易漏掉边界情况（比如 767.5px 的平板），而且多个 max-width 规则叠加时，优先级和覆盖顺序容易混乱。
正确姿势：
- 默认样式写基础版（小屏）
- 用
@media (min-width: 768px)覆盖中屏 - 再用
@media (min-width: 1024px)覆盖桌面 - 所有规则按升序排列，CSS 解析时自然覆盖，不用手动加
!important
媒体查询里能用 CSS 变量吗？
可以，但变量必须在媒体查询**内部声明或重定义**。外部定义的变量无法被媒体查询动态修改——CSS 变量作用域是静态的，不随媒体条件变化。
例如这样不行：
:root {
--gap: 16px;
}
@media (min-width: 768px) {
/* 这里不会自动把 --gap 改成 24px */
}得这么写：
:root {
--gap: 16px;
}
@media (min-width: 768px) {
:root {
--gap: 24px;
}
}不过要注意：这种写法会触发整个 :root 重新计算，如果页面有大量依赖该变量的组件，可能带来轻微性能抖动。简单布局没问题，复杂 UI 建议直接在选择器里重设属性，比如 .card { margin: var(--gap); } @media (min-width: 768px) { .card { margin: 24px; } }。
真正容易被忽略的是：媒体查询对打印样式、暗色模式、高对比度等场景也适用，但多数人只盯着屏幕尺寸。如果项目需要支持系统级偏好，@media (prefers-color-scheme: dark) 和 @media (print) 同样值得放进响应式策略里。
