hyphens: auto 仅在显式 lang、真实英文词、受限宽度、含连字符字形的字体四条件同时满足时才生效；否则静默失效，需用 overflow-wrap: break-word 兜底。
直接说结论：hyphens: auto 本身不保证出现连字符，它只在满足语言、字体、宽度、浏览器四重条件时才可能生效；多数实际项目中，它静默失败比成功更常见。
为什么写了 hyphens: auto 却没看到连字符
不是 CSS 写错了，是浏览器压根没启动断字引擎。它需要同时满足：
-
lang="en"必须显式写在目标元素上（比如<p lang="en">），靠<html lang="en">继承在 Chrome/Safari 中大概率失效 - 单词得是真实英文词（如
antidisestablishmentarianism），不是拼接字符串（如XPS13900FHDPLUS）或邮箱（verylongemail@example.com） - 容器宽度必须受限（
max-width或固定width），否则浏览器认为“不需要断” - 字体必须包含连字符字形（U+2010 或软连字符 U+00AD）：系统字体如
system-ui、-apple-system通常支持；自定义 Web Font 若未内嵌该字形，hyphens直接跳过
hyphens: auto 在移动端（尤其 iOS Safari）为何基本不可靠
iOS Safari 对 hyphens: auto 的启用门槛极高：
- 仅 iOS 15.4+ 开始有基础支持，更早版本完全忽略（连
-webkit-hyphens: auto都无效） - 必须用系统字体（如 San Francisco），
@font-face引入的字体若缺连字符表，即刻失效 - 单词长度通常需 ≥7 字符，
testing这类短词不会触发 - React/Vue 动态渲染时，
lang属性容易被覆盖或延迟挂载，导致断字逻辑错过 DOM 初始化时机
怎么写才真正起作用（含兼容兜底）
别把 hyphens: auto 当主力，它是锦上添花，不是排版保障。真正能落地的写法是组合策略：
立即学习“前端免费学习笔记（深入）”；
- 优先加兜底：
overflow-wrap: break-word（或旧名word-wrap: break-word），它不依赖语言/字体，只在溢出时断行，100% 生效 - 再叠加语义化尝试：
hyphens: auto+ 显式lang="en"，仅对支持环境生效，不影响降级逻辑 - Tailwind 用户：用
class="hyphens-auto break-words"，其中break-words是overflow-wrap: break-word的封装 - 绝对不要混用
word-break: break-all—— 它会彻底绕过hyphens，浏览器解析时直接忽略连字符逻辑
当 hyphens 完全失效时，更可控的替代方案
服务端预埋零宽连字符（）比纯 CSS 更可靠：
- 把
supercalifragilisticexpialidocious改成supercalifragilisticexpialidocious - 所有浏览器都识别，复制文本时不带连字符，渲染时在换行点显示短横
- 适合品牌词、技术术语、API 返回的长英文字段，避免前端动态判断语言上下文
- 注意别插在
<code>或<pre>里——代码可读性会受损
最常被忽略的一点：hyphens 不是开关，它是浏览器调用本地词典和字体字形的 API；一旦某环缺失，就静默跳过，连 warning 都不抛。所以调试时第一眼先看 computed styles 里 hyphens 是否真被计算为 auto，再检查 lang 和字体声明是否到位。
