hyphens: auto 在现代浏览器中非开箱即用：firefox 默认支持；chrome/edge 自v88起需配合精确lang属性及justify对齐；safari 仅限部分西欧语言且ios 15.4+稳定，对中文完全无效。
hyphens属性在Chrome/Firefox/Safari中的实际支持差异
直接说结论：hyphens 在现代浏览器中并非“开箱即用”，Firefox 默认启用，Chrome（基于Chromium）从v88起才支持hyphens: auto，但**必须配合正确的lang属性**，且仅对部分语言生效；Safari 仅在macOS/iOS原生Webkit中支持，iOS 15.4+ 才稳定启用，且对lang="zh"完全无视——中文断词根本不会触发。
常见错误现象：hyphens: auto 写了但单词/长英文串仍溢出容器，或只在Firefox里生效，其他浏览器毫无反应。
- Firefox：支持
hyphens: auto+lang，无需前缀，但lang值必须匹配其内置断词字典（如lang="en-us"、lang="de"） - Chrome/Edge：需
hyphens: auto+ 有效lang+ 启用text-align: justify（某些版本下是隐式依赖） - Safari：仅支持
lang为en、de、fr等少数西欧语言；lang="zh"或lang="ja"写上去等于没写
lang属性必须精确到子标签层级，不能只设在html根节点
很多项目把lang="zh-CN"写在上就以为全局生效，但hyphens的断词行为只作用于**当前元素及其文本子节点**，且会继承最近的lang。如果一段英文段落嵌套在中文容器里，又没单独声明lang="en"，Chrome和Safari直接跳过断词逻辑。
实操建议：
- 对含英文单词/技术术语的中文段落，在对应
<span></span>或<p></p>上显式加lang="en"，例如：<p lang="zh-CN">请参考<code lang="en">React.memo的用法 - 避免用
lang="zh"期望触发中文断句——CSS标准不定义中文断词规则，浏览器也无实现；中文换行靠word-break: break-all或overflow-wrap: break-word - 多语言混排时，
lang必须按语义块拆分，不能笼统设父级
需要兼容老版Chrome或iOS Safari时的降级方案
当目标用户包含 iOS 14.x 或 Chrome hyphens: auto 实际不可用，强行启用只会让文本渲染异常（如字母间距突变）。此时应主动降级，用word-break或overflow-wrap兜底，同时用@supports做渐进增强。
示例配置：
text {
overflow-wrap: break-word;
word-break: break-word;
}
@supports (hyphens: auto) {
[lang="en"], [lang="de"], [lang="fr"] {
hyphens: auto;
}
}
注意点：
-
word-break: break-word是旧写法，已废弃，应优先用overflow-wrap: break-word -
@supports中的hyphens: auto检测在 Safari 15.4+ 才返回true，iOS 14.x 下该规则块被忽略，自然回退 - 不要给中文元素加
@supports包裹的hyphens——既无效，又增加CSS解析负担
hyphens对性能与可访问性的真实影响
开启hyphens: auto会让浏览器在布局阶段调用系统级断词库（如Hunspell），对长段落或大量列表项有轻微布局延迟，尤其在低端Android WebView中可能引发重排抖动。更关键的是：屏幕阅读器（如VoiceOver、TalkBack）通常**忽略连字符**，把re-act读成react，但若断错位置（如ex-ample），反而造成语义歧义。
因此：
- 仅在明确以西文为主、且排版精度优先的场景启用（如PDF导出、杂志类网页）
- 禁用
hyphens的移动端页面，建议统一用overflow-wrap: anywhere替代——它比break-word更智能，能在任意字符间断行，且不插入连字符，对阅读器友好 - CI流程中可加检测脚本，扫描HTML中
lang值是否在浏览器支持列表内（如排除lang="zh-Hans"用于hyphens）
真正难的不是写对那几行CSS，而是判断哪段文字值得断、在哪种设备上断了反而坏事。连字符不是装饰，是排版契约——浏览器守约，用户才信你。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
