媒体查询样式被主样式覆盖，是因为媒体查询不改变选择器权重，激活后仍按(a,b,c,d)四元组比大小；解决关键是让响应式选择器与主样式同级或更高，如复用#app .sidebar .menu-item结构，或用[data-responsive]提升c值，避免低权选择器单独使用。
为什么媒体查询里的样式总被主样式干掉？
媒体查询本身不改变选择器权重，它只决定规则是否激活。一旦激活，里面的选择器照样按 (a,b,c,d) 四元组比大小。常见现象是：小屏下写好了 @media (max-width: 768px) { .btn { padding: 4px !important; } }，但实际还是用的桌面版的 .header-nav .btn（权重 (0,0,2,1)），因为后者特异性更高。
怎么让响应式样式在权重上赢？
别只改断点值，重点是让媒体查询内的选择器和主样式“同级甚至更高”：
- 复用主样式中已有的高权重结构，比如主样式是
#app .sidebar .menu-item，那响应式里就写@media (max-width: 768px) { #app .sidebar .menu-item { display: block; } } - 加一个无副作用的属性选择器强化，如
.menu-item[data-responsive]→ 权重c+1，且不影响 DOM 结构 - 避免用纯标签或低权类单独写，比如
@media { div { margin: 0; } }几乎必输，除非主样式也是同权甚至更低 - 注意 scoped style 或 CSS Modules 生成的属性选择器（如
.menu-item[data-v-abc123]），你的响应式规则必须匹配这个完整选择器才能命中
run_at 和注入时机对响应式 CSS 有影响吗？
有，而且很关键。如果扩展的 CSS 在 DOM 尚未完成解析时注入（run_at: "document_start"），而目标网站的响应式 JS 后续动态添加了 class 或修改了 style 属性，你的媒体查询可能被覆盖或失效。更稳妥的做法是：
- manifest 中设
run_at: "document_idle"，确保 DOM ready 且框架（如 React）完成首次渲染后再注入 - 若目标站用 JS 动态切换 viewport 或 class（如
document.documentElement.classList.add("mobile")），你的媒体查询无法响应这类逻辑，得配合 JS 注入监听或直接用属性选择器覆盖 - 不要依赖
!important去硬刚 JS 设置的内联样式，它能覆盖 CSS 文件里的规则，但压不住element.style.xxx—— 这时候得用mutationObserver或强制重设
调试响应式样式覆盖失败的三步法
打开开发者工具后，不是直接翻代码，而是盯住三个地方：
立即学习“前端免费学习笔记（深入）”；
- 在 Elements 面板选中目标元素，看 Styles 侧边栏里你写的媒体查询规则有没有出现；没出现 → 选择器根本没匹配上（检查断点值、父容器 class、data 属性）
- 出现了但带删除线 → 查右下角 specificity 值，对比主样式那条，确认谁的
(b,c,d)更大 - Computed 面板里找到最终生效的
padding或display，点开来源链接，直接跳转到那一行 CSS —— 很多时候问题不在你写的媒体查询，而在某处漏掉的全局重置（如all: unset）或 UA 样式干扰
真正难的不是写媒体查询，而是让它的选择器在千变万化的 DOM 结构和 JS 行为里始终稳稳命中。权重算清楚只是第一步，后续还要卡准时机、绕过框架封装、避开 UA 干扰。
