Chrome中hyphens: auto需同时满足lang="en"、支持连字符的字体及-webkit-hyphens前缀，缺一不可；iOS 15.3及更早版本Safari完全不支持英文连字符。
hyphens: auto 在 Chrome 里不显示连字符，基本就是 lang 属性没生效
Chrome（v120+）对 hyphens: auto 的英文断词支持是“有条件启用”的：它不会主动推断语言，必须看到明确的 lang="en"（或 lang="en-US" 等）才启动连字符分析。框架渲染、动态插入、服务端模板漏写，都可能导致 DOM 节点上根本没有这个属性，或者被覆盖掉。
别指望在 上设一次就全局生效——React/Vue 组件内生成的文本节点如果没继承或没显式挂载，浏览器压根不认。最稳妥的做法是：在具体承载英文长单词的容器上硬编码 lang="en"，比如：
<div class="text-block" lang="en"> supercalifragilisticexpialidocious </div>
- 检查 DevTools 的 Elements 面板，确认目标元素节点确实有
lang="en"属性，不是靠 CSS 伪类或 JS 动态加的（后者可能错过解析时机） - 避免用
dangerouslySetInnerHTML或v-html注入纯文本，这类方式绕过框架的语言上下文，lang属性即使存在也常被忽略 - 服务端返回的英文内容，如果前端异步插入，确保插入前已把
lang="en"写进父容器，而不是等插入后再补
字体不支持连字符表，hyphens 就是摆设
就算 lang 正确，Chrome 和 Safari 仍需要字体提供 Unicode 连字符信息（U+2010 或软连字符 U+00AD），否则 hyphens: auto 会静默失败。系统字体如 San Francisco（macOS/iOS）、Segoe UI（Windows）自带连字符表；但自定义字体（@font-face 引入）若未内嵌，就完全不工作。
验证方式很简单：在 DevTools 的 computed 样式中看 hyphens 是否为 auto，再点开 font-family 对应的字体详情，找 “hyphenation” 或 “Unicode ranges” 字段。没有相关支持项，就得换字体或让字体工程师补连字符表。
立即学习“前端免费学习笔记（深入）”；
- 临时验证可先切回
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI"，看是否立刻出现连字符 - Webfont 工具如 Font Squirrel 的 Webfont Generator 提供“Include hyphenation support”选项，导出时务必勾选
- 不要依赖 CSS 的
unicode-range来“模拟”支持——它控制字形加载范围，不等于连字符逻辑
iOS Safari 和旧版 Chrome 对英文 hyphens 支持极弱
iOS 15.4 是分水岭：此前所有版本 Safari（包括 iOS 15.3 及更早）对英文 hyphens: auto 完全无视，写了也等于没写。Chrome 桌面版虽从 v55 开始支持，但对英文生效仍要求单词 ≥ 7 字符，且需配合 -webkit-hyphens: auto 前缀（Safari 必须）。
这意味着你写的这段 CSS 在很多真实设备上根本不会触发：
.text { hyphens: auto; }
得补上前缀并接受兼容性现实：
.text {
-webkit-hyphens: auto;
-ms-hyphens: auto;
hyphens: auto;
}
- iOS hyphens；得用
overflow-wrap: anywhere或零宽空格兜底 - Chrome Android 版本碎片化严重，v110–v119 对
hyphens英文支持不稳定，建议用overflow-wrap: break-word作为降级方案 - 测试时必须真机跑 iOS 15.3 和 Android Chrome v115，不能只信桌面版模拟器
长单词来自 API 时，后端插零宽空格比前端硬扛更可靠
当超长英文单词（如 JWT token、Base64 片段、API 错误码）由后端吐出，前端几乎无法控制 lang、字体、浏览器版本，此时依赖 hyphens 风险极高。更务实的做法是：后端在生成这类字符串时，按规则插入零宽空格 （U+200B），位置可设为每 7–10 字符一次。
例如把 "supercalifragilisticexpialidocious" 处理成：
supercalifragilisticexpialidocious
这样无论浏览器是否支持 hyphens，只要 white-space: normal，就能自然断行。
- 前端 JS 做同样处理容易出错（比如破坏 URL 编码、影响复制粘贴），交给后端统一做更可控
- 零宽空格不影响语义和可访问性（screen reader 会跳过），也不改变字符串长度计算
- 注意不要插在 URL 协议头（
https://）中间，否则可能被解析为非法协议
真正难的从来不是写对 hyphens: auto，而是让浏览器在正确的时间、用正确的字体、对着正确的语言标记，去执行那个本该自动发生的连字符逻辑——这三个条件缺一不可，而其中任意一个，在现代前端工程里都可能被框架、构建链、CDN 或旧设备悄悄绕过。
