移动端多音字拼音必须逐字拆开写，每个汉字单独套标签，且内只能写单一读音；需显式声明ruby-align: center并用固定像素设置字体大小，真机测试生僻字对齐。
移动端多音字拼音必须逐字拆开写
移动端 Safari 和 Chrome for Android 对 的解析更严格，把「否极泰来」写成 否极泰来 会导致拼音整体偏左、声调错位，甚至被语音引擎跳过。根本原因是浏览器需要每个 有唯一对应的基字锚点，而移动端排版引擎不支持“一对多”映射的降级处理。
实操建议：
- 每个汉字单独套
，哪怕词很短也要拆：正确写法是<ruby><rb>否</rb><rt>pǐ</rt><rb>极</rb><rt>jí</rt><rb>泰</rb><rt>tài</rt><rb>来</rb><rt>lái</rt></ruby>
- 多音字如「长」在「生长」中读
zhǎng，在「长度」中读cháng，不能靠 JS 动态切换——lang属性和屏幕阅读器只在首屏 HTML 解析时读取一次，JS 后期改innerHTML不触发重读 - 避免用
title或伪元素（::before）模拟拼音：它们不属于可访问树，VoiceOver 和 TalkBack 都不会朗读
ruby-align: center 在 iOS Safari 必须显式声明
iOS Safari 17.4 之前版本（包括所有 iPadOS 16 及更早）默认不实现 ruby-align: center，会退回到 start，导致拼音紧贴汉字左侧，在窄屏手机上尤其明显。这不是 bug，是规范实现差异。
实操建议：
- CSS 中全局加
ruby { ruby-align: center; -webkit-ruby-align: center; }，别只作用于某个 class - 如果用了
text-align: right或 RTL 布局（比如阿拉伯语混排），不声明ruby-align会被父级样式覆盖，拼音直接右飘出屏幕 - 别依赖
line-height撑开对齐——它只影响垂直空间，不解决水平锚点问题
移动端语音合成（TTS）只认
当用户开启 VoiceOver 或 TalkBack，系统 TTS 引擎只会朗读 里的字符串，完全忽略 surrounding text。所以写 会让读屏软件念成 “fou pi”，而不是 “pi”。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
实操建议：
- 多音字必须靠上下文+
单一值配合：例如「否」在「否定」中标为，在「否极泰来」中标为，不能混写 - 可在外层加
data-pinyin="pǐ"供 JS 辅助逻辑用，但不要替代 - 轻声、儿化音要写全：「我们」标
wǒ men，不是wǒ mén；「花儿」标huā ér，不是huār
字体 fallback 和缩放容易让拼音错位
移动端默认启用 pinch-zoom，而部分安卓 WebView 对 em 单位缩放不一致，若只设 rt { font-size: 0.6em; }，放大后拼音可能压住汉字或上下浮动。
实操建议：
- 用固定像素值控制拼音大小：
rt { font-size: 12px; line-height: 1; }，再配合ruby { line-height: 1.3; }锁定基线间距 - 避免用
vw或百分比设font-size，它们在 zoom 下行为不可控 - 测试真机：Chrome DevTools 的 device emulation 无法复现 iOS Safari 的字体回退链（如 PingFang → Heiti → sans-serif），需实机验证「饕餮」「耄耋」等生僻字是否仍对齐
真正麻烦的是：你得在写 HTML 时就决定每个字的读音，不能靠运行时判断语境——因为可访问性链路在 DOM 初始渲染那一刻就锁死了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
