多音字注音必须人工指定读音并严格遵循HTML规范：用锁定基字、标注唯一正确读音、保障旧浏览器兼容，同时CSS需固定font-size和line-height以防裁切。
多音字必须人工指定，<ruby></ruby> 不会自动判断
浏览器和屏幕阅读器完全依赖你写的 <rt></rt> 内容，不会查词典、不看上下文。“长”在“长度”里是 cháng，在“成长”里是 zhǎng，写错就朗读错。常见错误是把两个读音都塞进一个 <rt></rt> 里，比如 <ruby>长<rt>cháng/zhǎng</rt></ruby>——这会让语音引擎卡住，也违反语义规范。
正确做法只选一个上下文确定的读音，用单个 <rt></rt> 标注：
- 按实际语境手动查证（推荐《现代汉语词典》App 或 pypinyin 的
lazy_pinyin(text, strict=True)） - 避免用斜杠、顿号、空格分隔多个读音
- 若需提示多音可能，用
title属性补充：<ruby title="也可读 zhǎng">长<rt>cháng</rt></ruby>
<rb></rb> 显式包裹能防错位，尤其对多音字组合
像“重”“行”“发”这类高频多音字，单独出现时容易被误判为词级单位。如果直接写 <ruby>重庆<rt>Chóngqìng</rt></ruby>，拼音会浮在两个字整体上方，视觉上无法对应到“重”字本身。而 <ruby>重<rt>chóng</rt>庆<rt>qìng</rt></ruby> 又可能被误拆成“重-庆”两字本音，忽略地名特殊读法。
稳妥解法是显式用 <rb></rb> 锁定基字范围：
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
-
<ruby><rb>重</rb><rt>Chóng</rt><rb>庆</rb><rt>qìng</rt></ruby>——明确“重”标Chóng，“庆”标qìng - 即使单字，也建议加
<rb></rb>：语义更清晰，CSS 控制更稳，旧版 Safari 渲染更可靠 - 注意
<rb></rb>和<rt></rt>必须严格一对一，不能跳过或重复
兼容老浏览器时，<rp></rp> 不是可选项，而是安全底线
iOS Safari 15.4 之前、部分 Android WebView、以及所有 IE 版本，压根不识别 <ruby></ruby> 结构。如果你只写 <ruby>否<rt>pǐ</rt></ruby>，这些环境会把 pǐ 当普通文本直接显示在“否”后面，破坏排版和可读性。
加上 <rp></rp> 后，它们会渲染成“否(pǐ)”，既保语义又保格式：
- 标准写法：
<ruby><rb>否</rb><rp>(</rp><rt>pǐ</rt><rp>)</rp></ruby> -
<rp></rp>必须成对出现，且内容只能是括号字符（(和)），不能是中文括号或空格 - 现代浏览器会自动隐藏
<rp></rp>，只显示拼音；老浏览器则隐藏<rt></rt>，只显示括号内容
CSS 不设 font-size 和 line-height，多音字注音大概率被裁掉
默认情况下，<rt></rt> 的字体大小由浏览器自行缩放（通常 50%～60%），但不同内核计算方式不一致。加上多音字常出现在小字号段落中，很容易导致拼音顶部被父容器 overflow: hidden 截断，或与下一行文字重叠。
最简可控方案是固定像素值：
- 给
<rt></rt>设font-size: 12px（别用70%或0.7em） - 给
<ruby></ruby>设line-height: 1.8，留出足够垂直空间 - 避免对
<rt></rt>使用position: absolute——它会破坏屏幕阅读器遍历顺序
真正难的不是写对标签，而是每个字都得确认读音、每个 <rt></rt> 都得人工校验、每处 <rp></rp> 都得检查括号是否闭合。自动化工具（如 pypinyin）能省力，但永远替代不了上下文判断。
