弹窗字体不一致的根本原因是继承“太准”而非失效——它忠实继承弹窗容器的字体设置，而该容器可能未继承body或被高优先级规则覆盖。
弹窗字体样式与主站不一致，根本原因不是继承“失效”，而是继承“太准”——它忠实地继承了弹窗容器（比如 .modal 或 #popup）的字体设置，而这个容器本身可能没继承 body，或被更高优先级规则覆盖了。
弹窗容器未显式继承 body 字体
很多弹窗是动态插入 DOM 的（如通过 JavaScript append 到 document.body），但它自身没有设置 font-family，也不在某个已设字体的语义容器内。此时它直接“裸奔”在 body 下，看似该继承，但实际受两重干扰：
- 浏览器对
dialog、div[role="dialog"]等元素可能有隐式 UA 样式重置（尤其在 Safari/Chrome 新版本中） - 若主站用 CSS 自定义属性（如
--base-font: 'Inter', sans-serif）设在:root，但弹窗组件的样式表没引入或没使用该变量，就会 fallback 到系统默认字体 - 部分 UI 框架（如 Ant Design、Element Plus）会给弹窗根节点加
font-size: 14px等硬编码值，直接切断相对单位链
input / button / select 在弹窗里突然变样
这类表单控件在多数浏览器中**默认不继承 font-family**，哪怕父容器写了 font-family: 'SF Pro Text', system-ui，它们仍可能渲染成系统等宽字体（如 macOS 的 Menlo）或衬线体（Windows 的 Times New Roman）。
必须显式声明：
.modal input,
.modal button,
.modal select {
font-family: inherit;
}
注意：inherit 是关键——它强制从父容器拿值，而不是依赖浏览器 UA 样式或全局 body 设置。
z-index 高但 font-size 却回退到 16px
常见于用 rem 布局的项目：主站 html { font-size: 16px }，但弹窗 JS 插入后，其父级（如 body）若被其他脚本动态改过 font-size（例如适配移动端缩放），而弹窗内部没同步更新根字号，1rem 就会变成非预期值。
- 检查开发者工具里弹窗最外层元素的 computed
font-size，看是否真等于你预期的 rem 基准 - 避免在弹窗样式中混用
px和rem：比如font-size: 1.125rem和line-height: 24px并存，容易因基线错位放大视觉差异 - 更稳妥的做法是给弹窗容器加一层
html[data-modal-open] { font-size: clamp(16px, 1vw, 18px); }，用响应式根字号兜底
字体加载延迟导致 FOIT/FOUT 在弹窗中更明显
主站页面有足够时间加载 Web Font，但弹窗是点击后才创建的，字体资源可能尚未就绪，触发 Flash of Invisible Text（FOIT）或 Flash of Unstyled Text（FOUT）。
- 不要只靠
@font-face声明，加上font-display: swap强制 fallback 显示 - 对弹窗关键文本（如标题），可提前用
<link rel="preload">加载字体文件 - 避免在弹窗 CSS 中写
font-family: 'YourFont', system-ui而不提供可靠 fallback —— 若字体加载失败，system-ui在不同系统下差异极大
真正难调的不是“怎么让弹窗继承”，而是“继承源是否干净”。一个没被 reset 过的 body、一段漏掉 font-family: inherit 的表单规则、一次被忽略的根字号变更，都会在弹窗这个“新上下文”里被急剧放大。动手前，先用开发者工具逐层点开 computed styles，盯住 font-family 和 font-size 的 actual value 来源，比猜更省时间。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
