题干与适用场景
国际化内容站的卡片标题在窄屏上只剩一个词，长段落末尾也经常出现孤行。设计团队希望统一使用一行 CSS 修复，但页面还要支持用户编辑、旧浏览器和动态字体。请比较 text-wrap: balance、text-wrap: pretty、普通 wrap 与 stable，给出选择依据和落地方案。
这道题适合前端、设计系统和内容平台岗位。重点是理解文本换行是布局行为，不能把视觉偏好误当成固定宽度或 JS 测量结果。
面试官考察点
强回答会把 balance 用在短标题、引用等少量行数的文本，把 pretty 留给更长的正文并承认其更高计算成本；会说明两者都不改变元素的内联尺寸，也不会自动解决 white-space: nowrap。还应覆盖 stable 对 contenteditable 编辑体验的价值、国际化测试、旧浏览器静态降级和可访问性。
回答前需要澄清的问题
- 文本是标题、卡片摘要、正文还是可编辑输入区？预期最多多少行？
- 需要避免孤行，还是需要让每行视觉长度更均衡？
- 容器是否已有
white-space、固定高度、截断或line-clamp？ - 目标语言、字体加载时机和浏览器支持矩阵是什么？
- 旧浏览器必须保持相同断行，还是可接受普通换行的渐进降级？
30 秒回答框架
“我会先按内容类型选策略：短标题用 text-wrap: balance，正文若确实需要减少孤行再评估 pretty，普通内容维持 wrap，可编辑区域考虑 stable。这些属性改变软换行，不改变元素宽度；white-space: nowrap、固定高度和截断仍需单独处理。先保留可读的默认样式，再在支持的浏览器启用增强，并用多语言、字体加载、响应式和编辑场景做视觉与性能验证。”
分步骤深入解答
第一步：区分四种策略
wrap 允许浏览器按正常断行规则换行；nowrap 则关闭软换行。balance 尝试让短文本的各行长度更均衡，适合标题和引用。pretty 使用更慢的算法改善较长文本的换行，并重点减少孤行。stable 面向 contenteditable，让光标附近编辑时之前的行尽量保持稳定。
第二步：给标题设定可控的边界
平衡算法需要文本真的有机会换行。为标题设置 max-inline-size 或合理的容器宽度，再应用 text-wrap: balance；否则一行文本没有可平衡的候选。不要用手工 br 标签 固定英文或中文断行，因为翻译、字体和屏幕宽度会改变结果。
.card-title {
max-inline-size: 24ch;
text-wrap: balance;
}第三步：谨慎使用 pretty
pretty 适合正文、说明和较长引用，但它比普通换行需要更多计算。只在文字质量确实重要且文本长度足够时启用，避免把它写在全局通配选择器上。对于只有一两行的标题，balance 更直接。
第四步：处理 white-space 和截断冲突
white-space: nowrap 明确要求不换行，与 balance 的目标相冲突。要启用平衡换行，先移除或覆盖 nowrap。固定高度、overflow: hidden 和 line-clamp 仍会裁切内容，需在设计上决定是允许高度增长、显示省略号，还是提供完整文本。
第五步：理解性能边界
浏览器需要尝试不同断行方案。MDN 和 Chrome 文档都建议把 balance 限制在短文本，较长正文才考虑 pretty；不要假设属性本身免费，也不要凭感觉声称它一定比 JS 更快。用真实页面测量布局、字体加载和长列表渲染。
第六步：覆盖国际化和字体变化
同一标题在中文、英文、德文和阿拉伯文中会有不同断行机会。测试应覆盖语言切换、字体回退、字号放大、窄屏和宽屏。不要以某一种语言的快照断行作为契约；契约应是不溢出、可读、层级稳定和内容完整。
第七步：为可编辑内容选择 stable
contenteditable 中用户修改中间文字时，整段文本重排会让光标附近的行跳动。text-wrap: stable 可让编辑位置之前的行保持稳定，但它不是标题美化策略，也不会替代输入框的高度管理。只在确实存在编辑体验问题的区域启用。
第八步：设计渐进增强和验证
默认样式使用普通 wrap 与可增长高度，支持的浏览器再添加 balance 或 pretty。使用能力检测或 CSS 规则分层，不要让关键内容依赖增强属性。验证计算样式、溢出、CLS、长列表耗时、减少动效无关的字体路径以及读屏顺序。
设计取舍与边界
balance 改善短文本的视觉节奏，但不会缩小元素宽度；卡片边框、阴影和对齐仍由容器决定。pretty 可能提升正文排版，也可能增加布局成本。两者都不替代内容编辑、断词规则、overflow-wrap 或可访问的全文展开。
不要把浏览器当前支持情况写成永久保证。CSS Text Level 4 仍有实现差异，必须按产品支持矩阵验证。对关键标题保留普通换行可用路径，对不可见或裁切的文字提供可访问名称和展开方式。
落地计划与证据
先挑选标题、摘要和正文各一个组件，记录语言、最大行数、容器尺寸和字体状态。标题试点使用 balance，正文只在孤行问题可复现时试用 pretty，编辑器单独评估 stable。在 Chromium、Firefox、Safari 和目标旧版浏览器中检查溢出、布局偏移和输入光标稳定性。
把规则写入组件文档：内容类型、最大行数、white-space 前置条件、降级样式和测量指标。每次修改字体、容器宽度或翻译都运行视觉回归，避免以单一快照掩盖多语言断行回归。
常见误区与追问
对所有元素使用 balance
全局应用会浪费计算，也无法改善长正文。把它限制在标题、引用和确实需要平衡的短文本。
以为 balance 会改变元素宽度
它只改变软换行，不会让盒子自动收缩。卡片的内联尺寸仍应由布局和 max-inline-size 决定。
忽略 nowrap 或固定高度
这些规则可能让文本继续溢出或被裁切。先检查计算样式，再决定是否允许换行和高度增长。
把 pretty 当成无成本的孤行修复
更好的换行需要额外计算。应以真实长列表和低端设备测量，而不是只看单个示例。
可编辑区域为什么不用 balance？
编辑时重排可能让光标附近跳动。若问题是编辑稳定性，应评估 stable；若问题是标题视觉，应在只读展示层使用 balance。