@import顺序不可靠控制CSS覆盖，因其异步加载且阻塞解析，实际生效取决于最终规则权重和HTML中样式表引入顺序，而非CSS内书写位置。
为什么@import的顺序不能可靠控制CSS覆盖？
因为 @import 的加载是异步且阻塞后续CSS解析的，浏览器会按HTML中link或style标签的顺序解析样式表，但 @import 声明本身不参与这个“层叠上下文”的排序逻辑——它只是把另一个CSS文件的内容“插入”到当前规则块里，实际生效顺序取决于最终解析出的规则权重和位置，不是写在前面就一定优先。
常见错误现象：@import 放在 body 后面、或多个 @import 嵌套时，发现样式没按预期覆盖，甚至出现闪动或延迟生效。
- 使用场景：老项目迁移、第三方UI库强制用
@import引入主题时想“后加载覆盖前加载” - 性能影响：每个
@import都触发一次HTTP请求（除非同域且开启HTTP/2），拖慢渲染 - 兼容性：IE9+支持，但IE中
@import必须在所有其他规则之前，否则被忽略
真正可控的层级覆盖靠什么？
靠CSS层叠规则本身：来源顺序（source order） + 选择器特异性（specificity） + !important（慎用）。
关键点：样式表在HTML中的引入顺序，比 @import 在CSS文件里的位置更权威。也就是说，<link rel="stylesheet" href="a.css"> 在HTML里写在 <link rel="stylesheet" href="b.css"> 前面，那 a.css 里的规则就天然早于 b.css 解析，哪怕 b.css 里 @import 了 c.css，c.css 的规则仍算作 b.css 的一部分，整体晚于 a.css。
立即学习“前端免费学习笔记（深入）”；
- 实操建议：把要“覆盖”的样式表放在HTML的
最后面，而不是靠@import倒腾 - 避免嵌套
@import：比如 a.css@importb.css，b.css 又@importc.css —— 这会让层叠关系彻底不可控 - 检查开发者工具的“Computed”面板，看某条样式到底来自哪个文件、哪一行，比猜顺序靠谱得多
什么时候必须用@import？
基本不用。现代项目中，@import 几乎只剩两个合理用途：条件媒体查询导入 和 CSS-in-JS环境下的动态注入（如 styled-components 的 injectGlobal 底层可能用到）。
示例（合法且可控）：
@import url("print.css") print;
@import url("mobile.css") screen and (max-width: 768px);
这种写法不会干扰主样式层叠流，因为它只在匹配媒体类型时才加载。
- 错误用法：在普通
main.css开头写@import "reset.css"; @import "theme.css";—— 等价于把 reset 写在 theme 前面，但失去对HTML加载顺序的掌控 - 构建工具（如Webpack/Vite）中，
@import会被预处理为内联内容，此时顺序由打包配置决定，和原始CSS文件位置无关 - 如果用PostCSS，
@import插件（如postcss-import）默认会把所有@import提前合并，反而更容易误判“谁覆盖谁”
调试覆盖失效时先查什么？
别急着改 @import 顺序，先打开DevTools，盯着“Styles”面板右上角那个小箭头点开，看当前样式是否被划掉（strikethrough）—— 如果被划掉，说明有更高权重的规则赢了；如果没被划掉但没生效，大概率是选择器没匹配上，或者被 display: none / visibility: hidden 搞掉了。
- 检查特异性：用浏览器计算出的 specificity 值（比如
0,1,1,1）对比冲突规则，比肉眼看“谁写了后面”准得多 - 注意继承：某些属性（如
color、font-size）会继承，覆盖的是父元素，不是目标元素本身 - 留意 Shadow DOM：如果样式在自定义元素内部，外部CSS默认无法穿透，
@import更不管用
