word-break: break-all 在各浏览器中表现不一致，Chrome/Firefox 优先在标点处断行，Safari 更激进地在大写字母间切断；keep-all 对CJK文本支持不稳定；混用 overflow-wrap 与 word-break 会引发优先级冲突。
不一致。特别是 word-break: break-all 在 Safari、Firefox 和 Chrome 中对英文和混合文本的断行位置、是否尊重词边界、甚至像素级渲染都有可观察差异。
word-break: break-all 在非CJK文本中的浏览器差异
这个值本意是“允许在任意字符间断行”，但实际执行时浏览器会偷偷参考语言规则：
- Chrome 和 Firefox 通常会在连字符
-、下划线_或斜杠/处优先断行，而不是真正在任意字母间切开 - Safari（尤其是 iOS 16–17）更激进，可能在连续大写字母（如
XMLHTTPREQUEST）中间直接切断，导致语义断裂 - Edge（基于 Chromium）行为基本跟随 Chrome，但旧版 EdgeHTML 对
break-all的标点处理有额外偏移
示例：<div style="width:120px; word-break: break-all">this-is-a-long-hyphenated-word</div> —— Safari 可能断成 this- + is-a-long-，而 Chrome 更倾向 this-is- + a-long-hyphenated-。
word-break: keep-all 对 CJK 文本的兼容风险
keep-all 理论上应禁止中文/日文/韩文在字间换行，但现实没那么干净：
立即学习“前端免费学习笔记（深入）”；
使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
- Chrome 和 Firefox 在简体中文中基本可靠，但遇到全角标点（如「，」、「。」）仍可能在标点后换行
- Safari（macOS 14 / iOS 17）对日语假名连写（如「こんにちは」）支持不稳定，偶尔在拗音处（「きょ」）错误断开
- 旧版 Android WebView（Android 10 及以下）完全忽略
keep-all，回退到normal
真正保险的做法是：对纯 CJK 内容加 white-space: nowrap 作兜底，或用 lang="zh" + unicode-bidi: plaintext 辅助识别。
overflow-wrap: break-word 和 word-break 混用时的优先级陷阱
很多人同时写 overflow-wrap: break-word 和 word-break: break-all 以为更保险，但实际会触发隐式优先级冲突：
- Chrome/Firefox：以
word-break为准，overflow-wrap被忽略 - Safari：当两者共存时，
overflow-wrap有时会覆盖word-break行为，尤其在 flex 容器内 - IE11：只认
word-wrap: break-word，word-break若未声明break-all则无效
建议明确取舍：长 URL 用 overflow-wrap: break-word；代码片段或紧凑表格用 word-break: break-all；不要叠用。
最易被忽略的是移动端 Safari 的渲染延迟——word-break 规则在动态插入内容后可能需要一次 layout 强制刷新（比如改 display 或触发布局重排），否则首次渲染仍按 normal 行为显示。
