标签不能直接用于输入框，需配合 js 动态操作 dom 实现拼音输入；嵌入 或 无效，contenteditable 方案破坏可访问性与 ime 兼容性；实时渲染须避免 innerhtml 和 v-html。
ruby 标签本身不参与拼音输入，也不能响应用户键盘输入或光标位置；它只是静态语义容器，用在输入辅助系统里必须配合 JS 控制流与 DOM 操作，否则会破坏可访问性或导致输入框失焦。
ruby 不能直接嵌入 <input> 或 <textarea></textarea> 中
浏览器禁止在表单控件内使用 ruby——<input type="text"> 的 value 是纯字符串，不解析 HTML；<textarea></textarea> 同理，写入 <ruby>你<rt>nǐ</rt></ruby> 只会显示为原文本，不会渲染拼音。强行用 contenteditable + ruby 模拟输入框，会导致：
- 屏幕阅读器无法正确播报编辑状态（如“正在编辑，输入模式”）
- 移动端 iOS Safari 会禁用长按菜单（复制/粘贴/选择全部失效）
- 拼音
rt被当作不可编辑内容，光标无法定位到拼音下方 - IME（中文输入法）候选栏与
ruby渲染层冲突，常出现遮挡或错位
输入过程中动态生成 ruby 需绕过 innerHTML 直接操作 DOM
若要在用户打字时实时显示拼音（如教育类输入练习），不能用 v-html、innerHTML = str 或模板字符串拼接，否则：
- 汉字含
&、、<code>"时会破坏结构（如 “AT&T” →&被转义后rt闭合失败） - 未过滤的用户输入可能触发 XSS（
rt内插入<script></script>） - 连续快速输入时，DOM 重绘滞后，出现拼音错位或残留旧
rt
正确做法是：逐字符创建 ruby 元素，用 document.createElement() + appendChild() 构建，再用 Text 节点包裹汉字，Element 包裹 rt，确保每个节点干净独立。
拼音输入辅助必须区分「展示态」和「编辑态」
用户聚焦输入框时，应隐藏所有 ruby 结构，只保留纯文本供编辑；失焦或提交后，再用 JS 批量转换为 ruby 注音。否则：
- Chrome 会把
rt当作可选中文字符，触发错误的输入法候选（如输入“n”后弹出“nǐ”而非“你”） - Firefox 在
contenteditable中对ruby的 selection API 支持不稳定，getSelection().getRangeAt(0)可能返回错误偏移 - 语音输入（Speech Recognition API）返回的
transcript是 plain text，无法自动映射到已有ruby结构中对应字
关键判断点：ruby 只应在「只读展示」场景下存在；输入辅助系统的核心逻辑必须跑在 JS 层，而非依赖标签原生行为。
最易被忽略的是：拼音输入辅助 ≠ 拼音标注。前者要响应实时交互、兼容 IME 和无障碍 API；后者只需静态语义和 CSS。混用二者，轻则光标乱跳，重则整段文字无法被 VoiceOver 正确朗读。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
