ruby标签不能解决多音字问题，它仅保证一对一映射；读音准确性取决于rt内容是否正确及上下文是否可推断，浏览器和屏幕阅读器不进行语义分析或自动切换。
ruby 标签本身不解决多音字问题，它只保证“一对一”结构；真正决定读音的是你塞进 rt 里的内容是否准确、上下文是否可推断——写错或模糊，屏幕阅读器就念错，且无法纠正。
为什么ruby不能自动识别多音字
浏览器和屏幕阅读器（如 NVDA、VoiceOver）对 ruby 的处理是机械的：它把每个 rt 内容当作该汉字的唯一发音，不做语义分析，也不查词典。输入“长”，<rt>cháng</rt> 就读 cháng，<rt>zhǎng</rt> 就读 zhǎng，没有中间态。
- 不存在“根据前后字自动切换读音”的浏览器行为
-
ruby不支持在同一个标签内写多个拼音（如<rt>cháng/zhǎng</rt>），这会导致语音合成器卡顿或静音 - 若用 JavaScript 动态替换
rt文本，必须同步触发aria-live，否则读屏器不会重读
多音字必须靠人工判读+上下文辅助
“否极泰来”的“否”读 pǐ，“否决”读 fǒu，这种差异只能由人判断后硬编码。但纯靠 ruby 易遗漏，建议组合使用：
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 主标注用
ruby，确保基础可访问性：<ruby>否<rt>pǐ</rt></ruby> - 为开发者和机器可读，加
data-pinyin属性备用：<span data-pinyin="pǐ"><ruby>否<rt>pǐ</rt></ruby></span> - 关键术语首次出现时，在旁边加简短说明（如“否（pǐ），意为‘坏、恶’”），这对听障+认知障碍用户更友好
- 避免在
ruby外再套aria-label—— 它会覆盖rt内容，导致读屏器只读 label，不读拼音
多音字连读与轻声处理的实操边界
中文口语中存在变调、轻声（如“我们”的“们”读 men 而非 mén），ruby 应反映实际读音，而非字典原调：
立即学习“前端免费学习笔记（深入）”；
- “一”在去声前变“yì”（如“一切”），应标为
<ruby>一<rt>yì</rt></ruby>，不是 “yī” - “了”作句末助词读轻声 “le”，标
<ruby>了<rt>le</rt></ruby>，而非 “liǎo” - 儿化音（如“花儿”）需完整写出“huār”，不能省略“r”或写成“huā ér”
- 禁止用 CSS 或 JS 隐藏某部分拼音来“模拟变调”——破坏结构即破坏可访问性
最易被忽略的一点：多音字标注一旦写进生产 HTML，就固化为语音输出依据；后续改文案不检查 ruby，就会造成“文字对、拼音错”的静默缺陷——这类问题在 axe 或 WAVE 扫描中根本不会报错，只能靠人工逐字核对上下文。
