根本原因是思源黑体与Noto Sans CJK的ascender高度差异大：前者约0.92em，后者可达1.05em；当line-height: 0.75时，后者首字顶部超出行框被裁切，需按字体实测微调line-height（思源黑体0.75，Noto推荐0.8–0.85，苹方0.72–0.76）。
为什么思源黑体下沉正常，Noto Sans CJK却顶部被截
根本原因不是 CSS 写错了，而是中文字体的 ascender（上伸部）高度差异极大：思源黑体 V3 的 ascender 约为 0.92em，而部分 Noto Sans CJK 变体可达 1.05em。当 line-height: 0.75 固定写死时，后者首字顶部直接超出行框被裁切。
实操建议：
-
line-height必须按字体实测微调，不能复用同一值；思源黑体可设0.75，Noto Sans CJK 推荐0.8–0.85，苹方（"PingFang SC"）则常需0.72–0.76 - 上线前必须用最终部署字体做真机测试，本地 fallback 字体（如
serif）渲染结果完全不可信 - 若项目需多字体兜底，可用
@font-face的font-display: swap+document.fonts.load()检测加载完成后再应用首字样式，避免 fallback 阶段错位
::first-letter 对英文字母和中文汉字的 baseline 处理差异
CSS 规范里，::first-letter 渲染为一个内联盒，其垂直对齐依赖父元素的 line-height 和字体自身的基线（baseline）。但英文有明确 ascender/descender，中文没有——浏览器对中文字体的 baseline 推算逻辑不统一，导致同样 line-height: 0.75 下，英文首字母“沉”得稳，中文首字却可能“飘”或“陷”。
关键应对点：
立即学习“前端免费学习笔记（深入）”；
- 禁用
vertical-align：它在浮动上下文中行为不可控，尤其跨字体时 - 优先用
margin-bottom: -0.1em微调下沉深度（比margin-top更安全，不触发新 BFC） - 英文段落可放心用
line-height: 0.82+font-size: 3.2em，中文段落必须单独加 class（如.zh-dropcap）并重置line-height和margin-bottom
中英混排时首字选中逻辑混乱怎么办
当段落以英文单词开头（如 <p>JavaScript 是一门语言</p>），::first-letter 会选中 J；但如果 CMS 输出的是 <p>JavaScript（JavaScript）是…</p>，括号是全角，某些浏览器（特别是 Safari 15.4 之前）会优先选中 （ 而非 J，造成放大后溢出。
稳妥做法：
- 服务端或构建时用正则清洗首字符：
text.replace(/^[\u3000-\u303f\uf900-\uf9fc\uff00-\uffef\u2000-\u206f\uff01-\uff5e]+/, '')，确保真实首字是 ASCII 字母或汉字 - 前端运行时检测：
const firstChar = p.textContent.trim()[0]; if (/[\u4e00-\u9fa5a-zA-Z0-9]/.test(firstChar)) { p.classList.add('valid-dropcap'); } - 绝不依赖
::first-letter自动跳过标点——它没有“跳过”能力，只认 DOM 文本流第一个可见字符
字体加载延迟导致首字位置反复跳动
常见现象：页面刚加载时首字位置偏高，几毫秒后突然下坠；双击缩放后又被裁切。这是字体未就绪时浏览器用 fallback 渲染，line-height 和 font-size 按错误度量计算所致。
必须做的三件事：
- 父
<p>加overflow: hidden：强制浮动锚点稳定，比clear: both更轻量 - 禁用
transform: translateY()调整位置——它会让后续文字 baseline 在字体切换后彻底失准 - 对关键字体启用
@font-face的font-display: optional或block，配合document.fonts.load('3em "Noto Sans CJK") 延迟应用首字样式，直到字体加载完成
line-height 和 margin-bottom，且必须在真实设备、真实字体、真实网络条件下验证。任何想靠一套 CSS 通吃所有中英字体的思路，都会在思源宋体和 Noto Sans CJK 的 ascender 差异前失效。 
