多音字必须人工判断语境后显式标注，因ruby仅映射结构不解析语义，无法自动识别读音；错误写法如“cháng/zhǎng”会导致语音合成器误读，正确做法是按实际语境单一定音或并列使用结构。
多音字不能靠ruby自动识别，必须人工判断语境后显式标注——否则屏幕阅读器会读错，CSS 也无法补救。
为什么ruby不支持自动多音识别
HTML 的 ruby 标签只负责结构映射，不解析语义。它不会根据上下文判断“长”该读 cháng 还是 zhǎng，也不会因“和”在句末就改读 hè。浏览器和语音引擎完全依赖你写进 <rt></rt> 里的内容。
- 错误写法：
<ruby>长<rt>cháng/zhǎng</rt></ruby>—— 语音合成器可能跳过斜杠，或随机选一个读 - 正确做法：根据实际语境，只保留一个拼音，如「长度」中用
<ruby>长<rt>cháng</rt></ruby>，「成长」中用<ruby>长<rt>zhǎng</rt></ruby></li> <li>若需展示多音对照（如教学场景），必须用多个 <code><rb></rb>
+<rt></rt>并列，而非塞进同一个<rt></rt>
多音字并列标注的合法 HTML 结构
想在同一位置展示两种读音，不能靠注释或 title，必须用标准嵌套结构，确保每个读音都绑定到明确基字。
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 必须显式包裹
<rb></rb>：<ruby><rb>长</rb><rt>cháng</rt><rb>长</rb><rt>zhǎng</rt></ruby> - 不能省略
<rb></rb>：仅写<ruby>长<rt>cháng</rt>长<rt>zhǎng</rt></ruby>在 Safari 和旧 Edge 中会导致对齐失效 - 避免空格或换行干扰：DOM 中
<rb></rb>和<rt></rt>必须逻辑紧邻，但 HTML 空白符不影响渲染，可适当缩进提升可读性 - 搭配 CSS 控制样式差异（如声调色）：
<rt class="tone2">cháng</rt>，再设.tone2 { color: #27ae60; }
动态生成时最容易漏掉的三个校验点
用 pinyin-pro 或 pypinyin 批量加注时，多音字常因处理链断裂导致结构错位。
立即学习“前端免费学习笔记（深入）”；
- 检查汉字与拼音数量是否严格一致：遇到「一」「不」等变调字，库返回的拼音可能已按语境修正（如「一个」→
["yí", "gè"]），但必须确保每个<rb></rb>对应一个<rt></rt>，不能少也不能多 - 非汉字字符（数字、标点、英文）必须原样保留，且不能被
<ruby></ruby>包裹：正则切分建议用/[\u4e00-\u9fff]+/g提取汉字块，其余部分跳过拼音处理 - 服务端模板（如 Jinja2）或前端框架（React/Vue）中，禁用
v-html或dangerouslySetInnerHTML拼接字符串：易引入 XSS 或解析错误；应封装为组件，props 仅传纯文本，由模板固定结构输出
多音字标注的核心不是技术实现难度，而是语义责任——你写的每个 <rt></rt> 都会直接决定语音朗读结果。浏览器不会替你纠错，CSS 也救不了语义错配。最稳妥的做法，永远是人工确认上下文后再落笔。
