@media内的样式被覆盖是因为媒体查询不提升选择器权重，仅控制规则激活；生效与否取决于内部选择器的特异性（如id、类数量）和定义顺序，需与主样式同级或更高才能胜出。
为什么@media里的样式总被干掉？
媒体查询本身不提升选择器权重，它只控制规则是否激活。一旦激活，里面的选择器照常参与层叠计算——和普通 CSS 规则比权重、比顺序。常见现象是：@media (max-width: 768px) { .btn { padding: 4px; } } 写了，但生效的却是桌面端的 .header-nav .btn（权重更高），因为后者特异性赢了。
- 媒体查询不是“特权区”，
@media 外壳不加分
- 断点匹配成功 ≠ 样式生效，还得看选择器能不能赢
-
!important 在媒体查询里照样被 element.style 覆盖，压不住内联样式
怎么让响应式选择器在权重上赢？
别靠堆 !important，重点是让媒体查询内的选择器和主样式“同级甚至更高”：
- 复用主样式已有结构：主样式是
#app .sidebar .menu-item，响应式就写 @media (max-width: 768px) { #app .sidebar .menu-item { display: block; } }
- 加无副作用属性选择器：比如把
.menu-item 改成 .menu-item[data-responsive]，c 值 +1，DOM 不用动
- 避免低权写法：
@media { div { margin: 0; } } 几乎必输，除非主样式也是纯标签选择器
- Vue/React 项目注意哈希后缀：真实 DOM 是
.menu-item[data-v-abc123]，你写的 .menu-item 匹配不上
检查@media是否真生效的三步法
别翻代码猜，盯死 DevTools 三个位置：
- Elements 面板选中目标元素，Styles 侧边栏里找你的媒体查询规则有没有出现；没出现 → 选择器根本没匹配（检查断点值、父容器 class、data 属性）
- 出现了但带删除线 → 看右下角 specificity 值，对比主样式那条，确认谁的 (b,c,d) 更大
- Computed 面板看最终生效值，点开来源链接，直接跳转到原始 CSS 行——如果显示
<unknown></unknown>，大概率是 CSS-in-JS 或 sourceMap 关闭导致
构建工具里顺序为什么总是乱？
Vite/Webpack 不按 HTML 里的 <link> 顺序打包，而是按 JS 入口的 import 顺序合并 CSS：
- Vite 中若启用了
css.preprocessorOptions 或某些 CSS 注入插件，生成的 <link> 默认插在
- Webpack 用
MiniCssExtractPlugin 时，CSS 合并顺序由 JS 入口里的 import 语句决定
- 动态
import() 加载的 CSS 不保证插入顺序，慎用于关键响应式样式
- 必须检查最终生成的 HTML（不是源
index.html），确认 <link> 实际顺序是否符合语义层级：reset → variables → 组件 → 页面/主题
@media 外壳不加分!important 在媒体查询里照样被 element.style 覆盖，压不住内联样式!important，重点是让媒体查询内的选择器和主样式“同级甚至更高”：
- 复用主样式已有结构：主样式是
#app .sidebar .menu-item，响应式就写@media (max-width: 768px) { #app .sidebar .menu-item { display: block; } } - 加无副作用属性选择器：比如把
.menu-item改成.menu-item[data-responsive]，c 值 +1，DOM 不用动 - 避免低权写法：
@media { div { margin: 0; } }几乎必输，除非主样式也是纯标签选择器 - Vue/React 项目注意哈希后缀：真实 DOM 是
.menu-item[data-v-abc123]，你写的.menu-item匹配不上
检查@media是否真生效的三步法
别翻代码猜，盯死 DevTools 三个位置：
- Elements 面板选中目标元素，Styles 侧边栏里找你的媒体查询规则有没有出现；没出现 → 选择器根本没匹配（检查断点值、父容器 class、data 属性）
- 出现了但带删除线 → 看右下角 specificity 值，对比主样式那条，确认谁的 (b,c,d) 更大
- Computed 面板看最终生效值，点开来源链接，直接跳转到原始 CSS 行——如果显示
<unknown></unknown>，大概率是 CSS-in-JS 或 sourceMap 关闭导致
构建工具里顺序为什么总是乱？
Vite/Webpack 不按 HTML 里的 <link> 顺序打包，而是按 JS 入口的 import 顺序合并 CSS：
- Vite 中若启用了
css.preprocessorOptions 或某些 CSS 注入插件，生成的 <link> 默认插在
- Webpack 用
MiniCssExtractPlugin 时，CSS 合并顺序由 JS 入口里的 import 语句决定
- 动态
import() 加载的 CSS 不保证插入顺序，慎用于关键响应式样式
- 必须检查最终生成的 HTML（不是源
index.html），确认 <link> 实际顺序是否符合语义层级：reset → variables → 组件 → 页面/主题
<unknown></unknown>，大概率是 CSS-in-JS 或 sourceMap 关闭导致<link> 顺序打包，而是按 JS 入口的 import 顺序合并 CSS：
- Vite 中若启用了
css.preprocessorOptions或某些 CSS 注入插件，生成的<link>默认插在末尾 - Webpack 用
MiniCssExtractPlugin时，CSS 合并顺序由 JS 入口里的import语句决定 - 动态
import()加载的 CSS 不保证插入顺序，慎用于关键响应式样式 - 必须检查最终生成的 HTML（不是源
index.html），确认<link>实际顺序是否符合语义层级：reset → variables → 组件 → 页面/主题
真正难的不是调顺序，而是让最终 HTML 的 <link> 顺序、选择器权重、媒体查询断点三者对齐——漏掉任意一环，覆盖就悄无声息地发生。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
