normalize.css不会导致字体发虚，它不修改字体渲染属性；所谓“变糊”实为自定义字体加载、transform非整像素偏移、系统字体平滑关闭或框架重复引入等真因所致。
Normalize.css 本身不会导致字体发虚——它不修改字体渲染逻辑、不设置 font-smoothing、不干预 text-rendering，也不触碰任何与抗锯齿相关的属性。所谓“用了 Normalize 后字体变糊”，是误把共性现象归因于它，实际问题藏在别处。
为什么你会觉得 Normalize 导致字体发虚？
常见错觉来源：
- 你刚引入
Normalize.css，紧接着发现文字在 Safari 或 Chrome 里发虚，就默认归给它——但Normalize.css的全部作用只是重置margin、padding、font-size等基础值，它连body的font-family都不设 - 你同时引入了 Bootstrap（含自己的基础样式）和
Normalize.css，而 Bootstrap 5+ 内部已集成 normalize-like 行为；重复引入会引发 CSS 权重冲突，某些继承链被意外打断，导致表单控件或内联元素意外回退到系统字体或 fallback 字体，视觉上像“变糊” - 你用的是自定义字体（如 Inter、Noto Sans），但没配
font-display: swap或optional，首屏加载时浏览器先用系统字体撑开布局，等自定义字体加载完再重绘——这个切换过程在 macOS + Safari 下极易产生灰边/缩放抖动，被误认为“发虚”
真正触发字体发虚的 CSS 属性和场景
这些才是要盯紧的地方：
-
-webkit-font-smoothing: antialiased：在 Chrome 110+ 和现代 Edge 中已被完全移除解析，写了等于没写；但它在 Safari 中仍有效，且设成antialiased反而会让文字失去子像素抗锯齿，变灰变虚——尤其深色背景上 -
text-rendering: optimizeLegibility：对小字号中英文提升可读性，但若用在图标字体或数字标签上，可能过度启用连字/字距调整，造成笔画粘连、边缘模糊 -
transform: translate(-50%, -50%)类非整数位移：Bootstrap 模态框常用这种居中方式，但 Safari/Chrome GPU 渲染时若计算出非整像素偏移（如-23.3px），就会强制降级为灰阶渲染，文字立刻发虚 -
backdrop-filter: blur()未配rgba()背景：Safari 中毛玻璃失效后，常 fallback 到纯白/纯黑背景，文字与背景对比度骤降，主观感觉“糊”
排查和修复建议（直接可用）
不用改 Normalize，聚焦真实变量：
- 打开 DevTools → Elements → 找到模糊文字的元素 → 看 Computed 面板里
font-family是否是你预期的字体；如果不是，检查是否被@font-face加载失败或 fallback 到了系统字体 - 在模糊元素上临时加
outline: 1px solid red，看 outline 是否清晰——如果 outline 清晰而文字模糊，说明是字体渲染问题；如果 outline 也虚，说明是 transform 或缩放导致的像素对齐失败 - Safari 下确认系统设置：macOS「辅助功能 → 显示 → 字体平滑」必须开启；关掉它，所有浏览器文字都会变灰
- 对模态框等用
transform居中的元素，强制凑整：transform: translate(calc(-50% + 0.5px), calc(-50% + 0.5px))，或改用top: 50%; left: 50%; transform: translate(-50%, -50%)+will-change: transform触发合成（但注意 Safari 对will-change的 backdrop-filter 兼容性）
Normalize 是个清道夫，不是调色师。字体清晰度问题从来不在它职责范围内，盯着它调，只会错过真正该修的 transform 偏移、font-display 策略、或系统级字体平滑开关。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
