记一次 Compose 文本排版填坑：为什么阿拉伯文案明明空间足够却强行换行？

背景与问题现象

在进行国际化适配时，我们常会遇到一些令人迷惑的排版行为。最近在处理一段阿拉伯语（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 解决了"能不能不换行"的问题。