@import不能解耦页脚CSS，因它不提供作用域隔离，所有样式仍全局生效；真正解耦需作用域控制，如模块化引入、BEM命名、容器前缀选择器及避免通配符和!important。
页脚CSS解耦 ≠ 用@import就能隔离样式
直接说结论：@import 不解决样式污染问题，反而可能加重耦合。它只是加载顺序的控制手段，所有导入的 CSS 仍会进入全局作用域，.footer-btn 和 #main .footer-btn 冲突照旧发生。
真正解耦的关键是作用域控制，不是文件拆分。你把 footer 样式全写进 footer.css，再用 @import "footer.css" 引入，只要没做作用域处理，它照样能覆盖页面里任意一个 .logo 或 h2。
现代项目该用什么替代 @import 做页脚样式隔离
如果你用的是 Webpack/Vite 等构建工具，@import 应该被替换成模块化引入方式；如果是纯静态页且必须用原生 CSS，则需配合命名约束或属性前缀。
- 用
import（JS 模块）或@use（Sass）代替@import：它们支持作用域和变量私有化，比如 Sass 中@use "footer" as f后，只能通过f.footer-wrapper访问 - 纯 CSS 场景下，强制约定 BEM 命名：所有页脚类名必须带
footer-前缀，如footer-nav、footer-copyright，避免裸名nav或copyright - 避免在
footer.css里写通配符选择器（如h2、button），这类规则会无差别影响全局
@import 的实际坑点：加载时机和性能风险
@import 是 CSS 层面的同步阻塞加载，浏览器必须下载并解析完被导入文件后，才能继续处理后续样式。放在 main.css 底部也没用，它依然会拖慢首屏渲染。
立即学习“前端免费学习笔记（深入）”；
- 错误写法：
@import url("footer.css")放在main.css末尾 → 实际加载顺序仍是“先等 footer.css 下载完，再继续解析 main.css 剩余内容” - 更隐蔽的问题：多个
@import会触发串行请求，@import "a.css"; @import "b.css"不是并发，而是 a 完了才发 b - 现代方案应改为
<link rel="stylesheet" href="footer.css" media="print" onload="this.media='all'">配合 JS 控制加载时机
如果必须用原生 CSS + @import，怎么最小化副作用
前提是你无法改构建流程、也不能加 JS 控制，只能靠纯 CSS。这时唯一可行路径是「物理隔离 + 选择器收束」。
- 页脚 HTML 必须包裹在唯一容器内，比如
<footer class="site-footer">...</footer> - 所有
footer.css中的规则，都以.site-footer为前缀，例如：.site-footer .footer-link { color: #666; }，禁止出现.footer-link这种孤立选择器 - 禁用
!important—— 它会穿透任何前缀约束，让隔离彻底失效 - 检查最终生成的 CSS 文件体积，
@import不会压缩重复代码，若多个入口都@import "footer.css"，打包后可能重复嵌入多份
最常被忽略的一点：HTML 结构决定 CSS 隔离上限。哪怕你把 footer 样式写得再“模块化”，只要页脚内容被直接塞进 且没包裹容器，所有 CSS 隔离手段都会漏气。
