优先使用 overflow-wrap: break-word + white-space: normal，再按内容类型微调 word-break；避免直接用 break-all，防止数字串如“123456789”被错误截断。
直接结论：优先用 overflow-wrap: break-word + white-space: normal，再根据内容类型微调 word-break；别一上来就用 break-all，容易把“123456789”切成“123”和“456”，用户根本看不出是同一串数字。
为什么 overflow-wrap: break-word 是默认起点
它只在“非断不可”的时候才切单词，比如容器宽 200px，但里面有个 https://example.com/very-long-path-with-no-spaces，浏览器会等其他换行机会（空格、连字符）都失败后，才在斜杠或点号附近断开。不会影响正常英文段落或中文句子的语义连贯性。
常见错误现象：只设了 width 和 overflow: hidden，没加 overflow-wrap，结果长 URL 撑破卡片、挤掉右侧按钮。
- 必须搭配明确宽度（
width、max-width: 100%或 flex 容器约束）才生效 -
word-wrap是旧名，现在应写overflow-wrap（兼容性足够，Chrome/Firefox/Safari/Edge 均支持） - 不要和
white-space: nowrap同时用——那等于告诉浏览器“不许换行”，overflow-wrap就失效了
word-break: break-all 什么时候该用
适合代码块、日志输出、用户粘贴的无格式长字符串，或者中日韩文本需要严格按字断行的场景。但它对英文数字串太激进：一个订单号 ORD-2026-789012 可能被切成 ORD- 和 2026-，识别成本陡增。
立即学习“前端免费学习笔记（深入）”；
使用场景：
- 后台管理系统的请求 ID、traceID 展示区域
- 终端模拟器类组件（
<pre>+word-break: break-all） - 移动端评论区，用户可能粘贴整段无空格英文或 base64
性能提示：在大量文本节点（如千条评论）中滥用 break-all，可能轻微增加重排计算量，但通常可忽略。
white-space 不只是“要不要换行”
它决定空格、换行符怎么处理，直接影响换行逻辑起点。例如用户提交的评论含手动换行，用 normal 会把所有回车当空格合并掉；而 pre-wrap 能保留原始段落结构，同时允许长单词自动折行。
参数差异：
-
white-space: normal：合并空格、换行符，自动换行 → 适合普通文章段落 -
white-space: pre-wrap：保留空格和换行符，自动换行 → 适合带缩进/分段的用户生成内容 -
white-space: nowrap：合并空格，禁止换行 → 必须配text-overflow: ellipsis才能安全用于单行标题
容易踩的坑：在响应式卡片里对摘要用 nowrap 却没设 max-width，小屏上文字直接溢出到屏幕外，连省略号都不显示。
移动端窄屏下的隐藏陷阱
很多团队加了 overflow-wrap 就以为万事大吉，但 iOS Safari 对 overflow-wrap: anywhere 支持滞后，且某些安卓 WebView 仍把 break-word 当作仅限英文的策略，对中文长段落断行不敏感。
实操建议：
- 中文为主的内容，加
word-break: keep-all防止在不该断的地方（如“中华人民共和国”中间）乱切 - 混合中英文时，组合写法更稳：
overflow-wrap: break-word; word-break: break-word;（注意：后者值已废弃，但部分旧内核仍识别） - 测试真机：用 Safari 的「Responsive Design Mode」可能骗不到真实断行行为，务必在 iPhone SE（2020）这类小屏真机上验证
最常被忽略的一点：父容器如果用了 display: grid 且没设 min-width: 0，子元素的 overflow-wrap 在某些情况下会被 grid track 的隐式最小尺寸压制，导致换行失效——这时候加一句 min-width: 0 就能解。
