hyphens: auto 跨平台不一致源于系统级断字引擎和字体支持差异：macOS 依赖 ICU 和 San Francisco，Windows 需启用 DirectWrite 词典及含 U+2010 的字体，iOS 仅限部分语言，Android 基本不支持。
hyphens: auto 在不同操作系统下表现不一致，不是 CSS 写错了，而是它根本依赖系统级断字词典和字体支持——macOS、Windows、iOS 各自有一套规则，Android 基本不认。
为什么 macOS Safari 能断字，Windows Chrome 却不行？
这不是浏览器版本问题，而是底层依赖不同：Safari 直接调用 macOS 系统的 ICU 断字引擎和 San Francisco 字体内置的 hyphenation table；Chrome/Edge 在 Windows 上默认用的是 DirectWrite + Segoe UI，但只有部分语言（如 en-US、de）的词典被启用，且需字体显式提供 U+2010 连字符字形。
- macOS：只要
lang="en"+font-family: -apple-system，hyphens 就大概率生效 - Windows：Segoe UI 支持有限，常需降级到
font-family: "Times New Roman", serif才触发（它内嵌了更全的连字符表） - iOS：iOS 15.4+ 开始支持，但只对
lang="en"或lang="fr"等少数语言有效；lang="en-GB"可能被忽略，必须写成en-GB（连字符，非下划线） - Android：WebView 几乎无视
hyphens，连-webkit-hyphens: auto都不响应
如何让 hyphens 在跨平台时“尽量”一致？
别指望完全一致，但可以收窄差异范围。关键不是加前缀，而是控制变量链：语言标记 → 字体 → 容器宽度 → 单词结构。
- 每个使用
hyphens: auto的元素都显式带lang="en"，不靠继承 —— React/Vue 动态渲染时尤其容易漏掉 - 优先用系统字体栈：
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif；避开未内嵌 hyphenation table 的 WebFont（如多数 Google Fonts） - 容器必须设
width或max-width，hyphens在无限宽环境下静默不触发 - 测试单词至少 7 字符且是真实英文词（如
internationalization），URL、Base64、拼接字符串（如XPS139000FHDPLUS）不会被识别为可断词
遇到 hyphens 失效时，哪些兜底方案真正可靠？
hyphens 是排版增强项，不是布局保障。当它在某平台静默失败，别硬扛，换语义更明确的组合。
立即学习“前端免费学习笔记（深入）”；
- 防溢出首选
overflow-wrap: break-word：只在必要时断，不插连字符，兼容性拉满（IE11+、所有移动端） - 中英混排或技术文档场景，用
word-break: break-word（注意：这是旧写法，实际应写overflow-wrap: break-word） - 对品牌词、API 参数等关键术语，改用
hyphens: manual+ HTML 实体（即），它在所有平台都渲染为软连字符，且复制时不带横杠 - 绝对不能对
<code>、<pre>或<textarea>设hyphens: auto——代码里出现连字符会破坏语法高亮和可复制性
最常被忽略的一点：hyphens 对中文、日文、韩文文本完全无效，不是 bug，是规范限定。想优化中日韩长文本换行，得转向 line-break: strict 或实验性 text-wrap: balance，而不是反复调 lang 和字体。
