ruby标签仅适用于东亚文字“基字+注音”严格一一对应的场景，对中英混排、含空格/连字符/数字/内联元素等内容普遍失效，浏览器兼容性差且无障碍支持不足。
ruby 标签在多语言混合排版中没有通用优势，它只对「基字+注音」严格一一对应的东亚文字场景有效；混用拉丁字母、数字、标点或中英夹杂时，语义断裂、渲染错位、无障碍失效是常态。
ruby 标签的适用边界非常明确
它不是“多语言排版工具”，而是为日文假名标注（furigana）、中文注音（如拼音、注音符号）这类「单个基字符配一个发音单位」设计的语义容器。一旦出现以下情况，ruby 就开始失能：
- 基字是英文单词（如
JavaScript），无法拆成「J-ava-Script」逐字对应 rt - 基字含空格或连字符（如
user-friendly），浏览器会把整个字符串当一个基字，rt无法对齐 - 中英混排句子（如「点击
Submit按钮」），ruby只能包裹汉字部分，英文部分必须另起逻辑，结构割裂 - 数字或标点参与发音（如「第123页」中的「123」需读作「yī èr sān」），
ruby不解析数值语义，只能硬编码
浏览器对混合内容的 ruby 渲染完全不可靠
Chrome 和 Firefox 会尝试把 ruby 内非文本节点（如 span、code）当作基字处理，但 Safari 和旧版 Edge 直接忽略——尤其当基字里嵌了 <code>Submit 这类内联元素时：
<ruby>点击 <code>Submit</code><rt>diǎn jī</rt></ruby>
这段代码在 Safari 中大概率不渲染 rt，因为 <code> 不是纯文本，且破坏了「一个基字 + 一个 rt」的原子结构。
更麻烦的是：即使渲染出来，不同浏览器对 ruby 内混合节点的 line-height、vertical-align 计算方式完全不同，无法用 CSS 统一修正。
替代方案比硬套 ruby 更实际
面对中英混排、带格式代码、动态内容等真实场景，优先考虑组合方案：
- 纯展示需求：用
span套aria-label（如<span aria-label="diǎn jī">点击</span> <code>Submit），兼顾可访问性和样式自由度 - 需要视觉注音：JS 库（如
pinyin-pro）先将中文转拼音，再按字拆分生成合规ruby结构，绕过手动维护 - 术语表/词典类静态内容：仍可用
ruby，但必须确保每组ruby内只有纯汉字 + 单个rt，英文术语单独处理
真正容易被忽略的一点：很多开发者以为加了 ruby 就自动支持屏幕阅读器朗读拼音，实际上绝大多数读屏软件跳过 rt，除非你额外加 aria-roledescription="pronunciation" 并测试 NVDA/JAWS/VoiceOver 行为——而这又和混合内容的 DOM 结构冲突。语义没对齐，技术再花哨也白搭。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
