CSS Modules 不处理 normalize.css,因为它只作用于 .module.css 等后缀文件,而 normalize.css 是普通 CSS 文件,会被构建工具视为全局样式,不哈希、不封装;若强行改为 .module.css,则 html、button 等基础选择器被哈希重命名导致匹配失效,且破坏其依赖的原生语义和层级关系。

为什么 CSS Modules 不处理 normalize.css?
CSS Modules 只对 .module.css(或 .module.scss 等)后缀文件生效,而 normalize.css 是普通 .css 文件,构建工具默认将其视为全局样式——它不会被哈希重命名,也不会被包裹进 JS 对象。你 import 它,只是让浏览器加载一段全局规则,和 Modules 机制完全无关。
为什么不能把 normalize.css 改成 .module.css?
改后会出严重问题:
- 所有基础标签选择器(
html、body、button)被哈希重命名,比如变成html_abc123,浏览器根本找不到对应元素,重置彻底失效 -
normalize.css依赖原生标签语义和层级关系(如input[type="search"]),哈希后选择器语义断裂,无法匹配 - Vite/Webpack 会把它当模块返回空对象或报错,连编译都过不去
为什么必须在最前面引入?
Normalize.css 的作用不是“兜底”,而是建立样式基线。它靠的是加载顺序优先级,而不是权重:
- 如果
antd/dist/reset.css或element-plus/index.css在它之后加载,里面写的button { margin: 0; }就会覆盖 normalize.css 中更克制的button { margin: 0.5em; } - DevTools 的 Computed 面板里,被划掉的 normalize 规则就是证据
- Vite 中用
import 'normalize.css'时,必须确保这行代码出现在所有 UI 库import之前;Webpack 同理,且不能被抽离到后加载的 chunk 中
真正容易被忽略的点
即使 normalize.css 加载正确,仍有三类隐性覆盖能绕过它:
立即学习“前端免费学习笔记(深入)”;
- 第三方组件渲染时带的
style内联属性(权重 1000),比如<input style="margin: 0"> - ID 选择器(权重 100),某些老库仍用
#modal .btn这类写法 - CSS-in-JS 库(如 Emotion)注入的样式,默认不走 link 顺序,需显式配置
prepend: true
这些都不是 CSS Modules 能管的范畴,得靠加载链路控制和运行时干预。


















