hyphens: auto 非纯 CSS 行为，依赖系统词典、lang 属性严格匹配、字体含连字符字形，且 iOS Safari 支持有限；推荐优先使用 overflow-wrap: anywhere 作为底线方案。
hyphens: auto 依赖浏览器内置词典，不是纯 CSS 渲染行为
它本质是调用系统级断字引擎（如 ICU 或 Apple 的 Core Text），不是靠 CSS 解析器算出来的。Chrome/Edge 用的是 Blink 内置词典，Firefox 用的是系统词典（Linux 下常缺 en-US），Safari 完全绑定 iOS/macOS 系统版本和语言包安装状态。所以即使写了 hyphens: auto，浏览器也可能直接跳过——不是 bug，是“没词典可查”。
lang 属性必须写在目标元素上，且格式严格
Safari 和 Chrome 都不会向上查找 lang 值，只检查当前元素是否带有效声明。漏掉或写错就会静默失效：
-
lang="en"✅ 有效 -
lang="en-US"✅ 有效（小写 + 连字符） -
lang="EN"❌ 大写无效 -
lang="en_us"❌ 下划线无效 -
lang="zh"下的英文段落 ❌ 不会继承生效
字体必须含 Unicode 连字符字形（U+2010 或 U+00AD）
Google Fonts 的 Inter、Roboto 默认不带 hyphenation table；而 -apple-system、"Segoe UI" 等系统字体才真正支持。你用 @font-face 引入 WebFont 时，得确认构建工具（如 Fontsource）已显式启用连字符表，否则 hyphens: auto 就是摆设。
iOS Safari 是最大变量：iOS 15.4+ 才开始有限支持
低于这个版本，-webkit-hyphens: auto 也完全不触发；即使满足所有条件，Safari 还要求单词 ≥7 字符（如 antidisestablishmentarianism 可能断，testing 就不行），且只对系统字体生效。更麻烦的是：改完 CSS 后可能要强刷页面或切后台再回来，才能看到效果——这是已知的 WKWebView 缓存 bug。
立即学习“前端免费学习笔记（深入）”；
真正落地时，别指望hyphens 主导换行逻辑。它太脆弱，一个条件不满足就归零；而 overflow-wrap: anywhere 在 Chrome 107+、Firefox 109+、Safari 16.4+ 已稳定可用，不查词典、不插连字符、对 URL 和路径天然友好——这才是你应该默认开启的底线方案。 
