背景与问题现象
在进行国际化适配时，我们常会遇到一些令人迷惑的排版行为。最近在处理一段阿拉伯语（Arabic）短文案时，发现了一个诡异的现象：
- 现象：Text 组件所在的容器空间非常充裕，但文案却莫名其妙地断成两行。
- 尝试 1 ：设置
maxLines = 1。结果：文案不换行了，但在某些长翻译场景下文字会被截断（Ellipsis），治标不治本。 - 尝试 2 ：单独设置
lineBreak = LineBreak.Simple。结果：依然换行，没有任何变化。
最终解决方案
通过组合使用换行策略优化 与最小宽度约束，问题得到了完美解决：
Kotlin
ini
Text(
text = arabicStatusText,
modifier = Modifier.sizeIn(minWidth = 150.dp), // 关键：提供测量保底空间
style = TextStyle(
lineBreak = LineBreak.Simple // 关键：禁用"段落均衡"算法
)
)深度剖析：为什么会这样？
1. 现代排版引擎的"过度设计"
Compose 默认的换行策略通常是 Strategy.HighQuality（对应 LineBreak.Heading 或 Paragraph）。
- 原理 ：它使用类似 Knuth-Plass 的全局优化算法，追求的是段落整体的视觉均衡。
- 副作用 ：算法会极力避免"第一行极长、第二行极短"的情况。如果它判定换行后两行长度更接近（均衡），它会主动切断文字，即使第一行还没排满。这在长文章中很美观，但在 UI 短标签中却是灾难。
2. 阿拉伯语的特殊性
阿拉伯语属于连笔书写系统，其字符簇（Grapheme Clusters）在排版引擎计算宽度时，往往存在较复杂的边距补偿。配合默认的"均衡"策略，极易触发提前换行。
3. 测量阶段的"宽度欺诈"
为什么单纯设置 LineBreak.Simple 没用？
- 在
wrapContent布局下，Compose 会进行多次测量。如果父容器没有明确给出一个"宽松"的宽度约束，Text 在测量阶段得到的可用宽度可能非常局促。 LineBreak.Simple的本质是贪婪算法：只要不撞墙就不换行。但如果"墙"（Constraints）给得太窄，贪婪算法也救不了。
方案对比与评估
我们将三种常见的修复手段进行了对比：
| 方案 | 逻辑原理 | 优点 | 缺点 | 结论 |
|---|---|---|---|---|
| maxLines = 1 | 暴力截断 | 绝对不换行 | 长翻译会丢失信息 | 弃用 |
| fillMaxWidth() | 撑满父空间 | 空间极大，不触发换行 | 在 Row 中会挤掉其他组件 | 慎用 |
| Simple + sizeIn | 贪婪算法 + 保底宽度 | 只有真放不下才换行 | 需要预估一个合理的 minWidth | 推荐 (Best Practice) |
技术总结与最佳实践
针对 UI 中的短状态提示、标签、按钮文案，尤其是涉及多语言（阿拉伯语、德语等）时，建议遵循以下排版准则：
- 策略降级 ：显式设置
lineBreak = LineBreak.Simple。UI 控件追求的是空间利用率，而非文学排版的均衡美感。 - 给足"跑道" ：使用
sizeIn(minWidth = ...)或width(IntrinsicSize.Max)确保测量阶段有足够的空间。 - 禁用软换行（可选） ：如果该位置业务上绝对不允许两行，使用
softWrap = false配合overflow。
一句话总结：LineBreak.Simple 解决了"想不想换行"的问题，而 sizeIn 解决了"能不能不换行"的问题。