ruby标签错位或截断的根源是浏览器依赖字体度量值（ascent/descent/line-gap）定位rt，而中文字体间差异大；实操需固定rt字号、预留line-height、禁用SimSun、针对性修正微软雅黑裁剪、统一rt与基字字体、避免vertical-align、font-display: swap防跳动。
ruby标签在不同中文字体下会错位或截断
不是字体本身“不支持ruby”，而是浏览器对rt的垂直定位依赖基字的em-box和baseline，而不同中文字体的度量值（如ascent、descent、line-gap）差异极大。微软雅黑的上行空间大，rt容易被顶部裁剪；思源黑体则偏紧凑，rt可能紧贴基字甚至重叠。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不要用
font-size: 70%这类相对值控制rt——它会随基字字体缩放倍率浮动，导致Chrome和Safari渲染偏差达2px以上 - 统一用固定像素：
rt { font-size: 12px; line-height: 1.2; }，再配合ruby { line-height: 1.8; }预留垂直空间 - 禁用系统默认字体栈里的
"SimSun"——它在macOS/Linux上根本不存在，回退链断裂后浏览器可能强行用无衬线字体撑开rt位置，造成错位 - 测试时必须打开Chrome DevTools的Computed面板，手动检查
rt的top值是否稳定（理想值应在基字baseline上方4–6px区间）
使用“Microsoft YaHei”时ruby拼音被顶部裁剪
这是最典型的字体度量陷阱：微软雅黑的ascent值比多数开源字体高15%～20%，浏览器计算rt上标位置时，把rt的baseline硬顶到容器顶部，结果就是拼音一半被截掉。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 加
ruby { padding-top: 0.2em; }，但仅限font-family明确含"Microsoft YaHei"的上下文，避免影响其他字体 - 更稳妥的是用
@supports (font-variant-east-asian: ruby)做特性检测，再注入修正样式（注意：该特性目前仅Chrome/Safari支持，Firefox不识别） - 别碰
vertical-align——设super会让rt相对于整行line-height偏移，而非相对于基字，反而放大裁剪问题
“PingFang SC”和“Hiragino Sans GB”混用导致拼音左右偏移
当ruby内基字用"PingFang SC"、而rt继承父级"Hiragino Sans GB"时，两个字体的字符宽度和字距算法不一致，rt无法水平居中对齐基字中心。尤其在小字号（12px以下）时，偏移肉眼可见。
实操建议：
立即学习“前端免费学习笔记（深入）”；
-
rt必须显式声明字体：rt { font-family: "PingFang SC", "Hiragino Sans GB", sans-serif; }，且顺序与基字完全一致 - 禁用
rt { text-align: center; }——它只对块级元素有效，rt是内联元素，居中靠的是浏览器内置的ruby布局逻辑 - 若需微调，用
transform: translateX(-1px);而非margin-left，后者会破坏ruby流式排版，导致换行时拼音脱钩
动态注入ruby时字体切换引发注音跳动
Vue/React组件首次渲染用系统默认字体，等自定义字体（如WOFF2）加载完成后再替换，此时rt位置会重算一次，出现明显“上跳”或“下坠”。这不是动画，是浏览器重新布局的结果。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 所有
@font-face规则必须带font-display: swap;，确保字体加载期间基字和rt先用fallback字体占位，避免二次重排 - 给
ruby加will-change: transform;可提前触发GPU合成，减轻跳动感知（但别滥用，仅限高频注音区域） - 服务端渲染时，若已知用户UA倾向macOS，可预置
font-family: -apple-system, BlinkMacSystemFont作为首屏字体，减少字体栈切换次数
