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 能管的范畴，得靠加载链路控制和运行时干预。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
