移动端 hyphens: auto 极不可靠，需同时满足 lang 属性显式声明（如 lang="en-us"）、ios 15.4+、系统字体且单词≥7字符；否则静默失效，推荐优先使用 overflow-wrap: anywhere 组合 hyphens: auto 并设 max-width。
hyphens: auto 在移动端（尤其 iOS Safari）基本不可靠，除非你同时满足 lang 属性显式声明、iOS 15.4+、系统字体及单词 ≥7 字符——漏掉任一条件就静默失效。
lang 属性必须写在目标元素上，不能靠继承
Chrome 和 Safari 不会向上查找 lang 值，只检查当前元素是否带有效声明。比如页面根节点是 ，但英文段落没加 lang="en"，断字引擎直接跳过。
- ✅ 正确：
<p lang="en">antidisestablishmentarianism</p> - ❌ 错误：
<p>antidisestablishmentarianism</p>（无lang） - ⚠️ 大小写和分隔符敏感：
EN、en_US、en-us全部无效；必须是en或en-US（小写 + 连字符）
字体不带连字符表，hyphens 就是摆设
浏览器调用断字逻辑前，会查字体是否含 Unicode 连字符字形（U+2010 或软连字符 U+00AD）。Google Fonts 的 Inter、Roboto 默认不含 hyphenation data；而 macOS 的 San Francisco、Windows 的 Segoe UI 支持更好。
- 开发阶段可先用系统字体验证：
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif; - 自定义 WebFont 必须确认构建时已内嵌 hyphenation table（如 Fontsource 的
@font-face配置需显式启用） - 别信“字体加载完成就 OK”——要实际检查 computed styles 中
font-family是否最终生效，且未被 UI 框架覆盖
hyphens: auto 和 overflow-wrap: anywhere 必须组合使用
hyphens: auto 是语义化排版增强，不是布局保障；它只在浏览器判定“有空间但词太长”时才介入。若容器宽度未受限，它根本不会触发。
- 必须配
max-width（哪怕max-width: 100%），否则浏览器认为“还能撑”，不走任何断行逻辑 - 推荐组合：
hyphens: auto; overflow-wrap: anywhere;—— 前者优先插-，后者兜底切任意位置（包括 URL 中的/或.） - 避免混用
word-break: break-all：它会完全压制hyphens，且在中文里劈字，破坏可读性
真正能落地的移动端方案，核心是 overflow-wrap
别把 hyphens 当主力。2026 年主流浏览器中，overflow-wrap: anywhere 已稳定支持（Chrome 107+、Firefox 109+、Safari 16.4+），它不依赖词典、不查音节、不插连字符，只在实在塞不下时断，对 URL、token、路径天然友好。
- Flex/Grid 容器中务必加
min-width: 0，否则子项默认min-width: auto会锁死宽度，让overflow-wrap失效 - Safari ≤15.3 可降级为
overflow-wrap: break-word（注意这不是标准值，但实测比break-all更克制） - 服务端预埋零宽连字符（
）比前端 JS 动态处理更可靠，尤其对 SSR 场景
最常被忽略的一点：hyphens 效果无法靠 DevTools 实时验证——它依赖字体渲染管线与系统级 hyphenation engine，改完 CSS 后可能要强刷或切后台再回来才生效；而 overflow-wrap 的行为是确定、可预测、可调试的。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
