绝大多数场景下应优先使用 overflow-wrap: break-word；word-break: break-all 仅适用于无语义的纯展示字段（如 base64、token），因其无视词边界，会破坏中文阅读和链接可点击性。
overflow-wrap: break-word 和 word-break: break-all 到底该用哪个
绝大多数场景下，overflow-wrap: break-word 是更安全的选择；word-break: break-all 只应在无语义、纯展示型字段（如 Base64、API token、日志行）中使用。
区别不在“智能与否”，而在断点规则：overflow-wrap: break-word 仅当整个单词宽度 > 容器宽度时，才在词内断开（比如英文长词、中文无空格串）；而 word-break: break-all 无视词边界，按字符切——中文会切在字中间，URL 会被截断成不可点击的碎片。
常见错误现象：用了 word-break: break-all 后，用户无法复制完整链接，或中文段落阅读节奏被打断。
- 中英文混排标题、用户昵称、文件名 → 优先
overflow-wrap: break-word - 后台返回的
data-token、trace-id字段 → 可用word-break: break-all - 必须配合
width或max-width才生效，否则在块级元素上可能完全不触发换行
hyphens: auto 在 Web UI 中基本不可靠
hyphens: auto 看似理想，但实际落地失败率高：它依赖 lang 属性、字体支持、浏览器内置词典（Firefox 需 hyphenate-resource），且中文几乎无效果。移动端兼容性差，渲染开销也比纯 CSS 换行规则高。
真实项目里，它更适合 PDF 导出或电子书渲染，不适合日常 Web UI。别把它当成“自动优化”的兜底方案。
- 英文段落启用后，仍需手动加
lang="en"，否则多数浏览器忽略 - Chrome / Safari 对
hyphens的支持限于部分语言，且不保证断点合理 - 若真要用，必须搭配
overflow-wrap: break-word，不能只靠hyphens
Less 封装 text-wrap mixin 的关键细节
用参数控制策略比写多个独立 class 更易维护，但必须显式处理兼容性和优先级问题。
IE11 只认 word-wrap，现代浏览器推荐 overflow-wrap，所以得同时写两遍；word-break: normal 也不能省——某些旧版 Chrome 下，缺了它 overflow-wrap 就不生效。
示例 mixin 片段：
.text-wrap(@mode: soft) when (@mode = soft) {
overflow-wrap: break-word;
word-wrap: break-word;
word-break: normal;
}
.text-wrap(@mode: hard) when (@mode = hard) {
word-break: break-all;
overflow-wrap: anywhere; // 现代替代方案，可选
}
- 避免在全局重置或
body上直接调用，防止污染第三方组件 - 父容器必须设
max-width或flex-basis，否则 mixin 生效条件不满足 - 响应式场景下，小屏建议从
hard回退到soft，避免break-all把短 URL 切得太碎
真正容易被忽略的：title 提示和内容感知缺失
所有 CSS 换行策略都是静态规则——它们不看内容长度、不判断是否是可点击链接、也不管用户是否需要复制原文。一个被 overflow-wrap 截断的邮箱地址，视觉上换行了，但鼠标 hover 没提示，用户根本不知道后面还有内容。
所以，只要用了任何换行 mixin，都该顺手加 title 属性（服务端渲染或 JS 注入均可），尤其是字段值明确、长度可控的场景（如用户输入的 description、error message）。
别指望样式自己“懂语义”；CSS 不会帮你做截断逻辑，也不会提醒用户原文被隐藏了。
