应使用模拟结构而非原生，因其支持clamp()响应式缩放、兼容IE11+且避免浏览器对的样式限制；多音字必须人工校验，自动识别不可靠。
多音字标注用
直接用 是语义正确但缩放不可控的根源。浏览器对 的字体大小、行高、间距有强默认约束，font-size: clamp() 或 vw 单位在多数浏览器里对 子元素无效，尤其在 Safari 和旧版 Chrome 中表现不一致。
更可靠的做法是放弃原生 ，改用嵌套 模拟结构，手动控制样式：
<span class="ruby"> <span class="rb">长</span> <span class="rt">zhǎng</span> </span>
这样所有子元素都能响应式缩放，且兼容性覆盖到 IE11+。
font-size 缩放该用 clamp() 还是 vw？
clamp() 更稳妥——它能设定最小、首选、最大三档尺寸，避免小屏下拼音过小看不清，或大屏下过度撑开行高。而纯 vw 在超宽屏（如 3840px）上会让拼音大得离谱，破坏阅读节奏。
推荐写法（以根字号为基准）：
.ruby { font-size: clamp(12px, 2.5vw, 16px); }
.rb { display: inline-block; }
.rt {
display: inline-block;
font-size: clamp(8px, 1.6vw, 11px);
line-height: 1;
vertical-align: top;
margin-left: -0.1em;
}
注意点：
-
.rt的font-size必须显式设置，不能依赖继承，否则部分安卓 WebView 不触发缩放 -
margin-left: -0.1em是为了抵消.rt宽度带来的额外空隙，让拼音紧贴汉字右上角 - 避免用
%或em设.rt字号，它们会随父级缩放二次计算，导致比例失真
小屏下拼音重叠或截断怎么防？
常见现象：iPhone SE 等窄屏设备中，汉字+拼音总宽度超容器，.rt 被换行或溢出隐藏。这不是缩放逻辑错了，而是布局没做弹性兜底。
关键处理项：
- 给
.ruby加white-space: nowrap防止内部换行 - 用
overflow: hidden+text-overflow: ellipsis仅对汉字生效（.rb），拼音始终显示全称 - 对极窄视口（
max-width: 320px），降级为「汉字（拼音）」括号格式，用媒体查询切换：
@media (max-width: 320px) {
.ruby { font-size: 12px; }
.rb::after { content: "（" attr(data-pinyin) "）"; }
.rt { display: none; }
}
其中 data-pinyin 是预置在 HTML 中的属性，比 JS 动态注入更稳定。
为什么 JS 动态计算缩放反而更难搞？
有人想用 window.addEventListener('resize', ...) 获取 clientWidth 后算比例设 style.fontSize，但实际踩坑密集：
- 滚动时频繁触发 resize（尤其 iOS Safari），造成样式抖动
- 横竖屏切换瞬间，
clientWidth返回的是旧尺寸，需加setTimeout延迟读取，引入不确定性 - SSR 渲染时无
window，服务端无法生成初始尺寸，首屏可能错乱
CSS 原生缩放方案（clamp / vw）天然规避这些，只要确保根元素 font-size 不被其他样式意外覆盖，就足够健壮。
真正要注意的，是拼音标注必须提前人工校验——自动分词+多音识别准确率远不够，zhǎng 和 cháng 写错一个字母，缩放再完美也没用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
