第一次写布局的时候，我踩了一个很典型、但又很关键的坑。

当时只是想做一个最简单的左右排布，于是写下了这样一段代码：

ts

Row() {
  Text('左')
  Text('右')
}

预期其实很直觉：两个元素一个靠左，一个靠右。但实际效果却完全不是这么回事——它们紧紧挤在一起，就像两个普通的文本节点顺序排列，没有任何“分布”的概念。

那一刻的反应其实很真实：是不是要加 margin？是不是有某种“自动两端对齐”的属性？还是说这个布局组件本身就有默认行为我没触发？

但继续往下尝试之后，很快意识到一个本质问题：这里不存在“默认帮你排好”的机制，布局结果完全由规则决定，而不是由系统替你做推断。

重新理解 Row 与 Column

当我把 Row 和 Column 当成“容器”去理解的时候，很多行为是解释不通的。直到后来换了一个视角：它们其实更接近一种“布局模型”，类似于 Web 里的 Flexbox，这些现象才开始变得合理。

Row 定义的是一个水平主轴，Column 则定义的是垂直主轴。子元素如何排列、是否分布、是否对齐，本质上都围绕“主轴”和“交叉轴”展开。这一点和 Web 的 Flex 布局几乎是一致的，但又有一个明显差异：它不会替你做任何隐式处理。

换句话说，在这里写布局，更像是在“声明规则”，而不是“描述意图”。

为什么子元素不会自动撑开？

真正让我卡住的，是另一个更隐蔽的问题：为什么子元素不会自动撑开？

直觉上，我们很容易认为子元素会“占满可用空间”，尤其是在横向布局中。但实际情况恰恰相反。默认情况下，子元素只会根据自身内容来确定尺寸。

也就是说，一个 Text('左')，它的宽度就只等于一个“左”字；Text('右') 也是如此。两个元素都非常“克制”，只占自己需要的那一点点空间，自然就紧紧挤在一起。

这背后其实揭示了一个非常关键的设计原则：布局系统不会主动分配空间，除非你明确告诉它要怎么分。

转折点出现在我引入了 layoutWeight 之后。

ts

Row() {
  Text('左')
    .layoutWeight(1)
  Text('右')
    .layoutWeight(1)
}

几乎是立刻，布局行为就发生了变化。两个元素开始分开，并且均匀地占据了整行空间。

这时候可以建立一个非常有用的理解模型：layoutWeight 的作用，本质上类似于 Flexbox 里的 flex-grow。它并不是控制元素“本身大小”，而是在控制“如何分配剩余空间”。

也就是说，在默认情况下，所有子元素都不参与空间竞争；一旦设置了 weight，它们才开始进入“分配体系”。而分配的比例，正是由这个权重决定的。

从这个角度看，布局就不再是一个“排版问题”，而是一个资源分配问题。

分布与对齐的真相

再往后，会遇到两个几乎绕不开的属性：justifyContent 和 alignItems。这两个名字在刚开始看时有点抽象，但一旦放到主轴 / 交叉轴的框架里，就非常清晰。

前者控制的是主轴方向上的分布方式，后者控制的是交叉轴方向上的对齐方式。

比如这样一段代码：

ts

Row() {
  Text('A')
  Text('B')
}
.justifyContent(FlexAlign.SpaceBetween)
.width('100%')

它的效果是让两个元素分别贴到左右两端，中间空间被拉开。这种行为在视觉上很好理解，但这里有一个非常容易忽略的前提：必须存在“多余空间”可以分配。

这个前提，是我在踩坑之后才真正意识到的。

有一次我写了类似的代码，但忘记设置宽度：

ts

Row() {
  Text('A')
  Text('B')
}
.justifyContent(FlexAlign.SpaceBetween)

结果完全没有变化。两个元素依然挤在一起，看起来像是属性“失效”了。

但问题其实不在属性，而在空间本身。父容器的宽度正好被两个子元素“内容尺寸”撑满，没有任何剩余空间。这种情况下，SpaceBetween 根本没有施展的空间，自然也就不会产生任何效果。

当我补上 .width('100%') 之后，一切才恢复正常。

这件事带来的一个非常重要的结论是：对齐策略是否生效，不取决于你有没有写，而取决于有没有空间让它生效。

从踩坑到建立认知模型

回到最初那个“挤在一起”的问题，现在其实可以用一整套逻辑来解释它。

子元素默认按内容尺寸计算，占用空间极小；父容器没有被主动撑开；没有任何 weight 参与空间分配；也没有对齐策略去重新分布已有空间。在这样的前提下，所有元素自然只能堆叠在主轴的起点。

这不是异常行为，而是一个完全符合规则的结果。

如果横向对比一下不同平台，这种差异会更清晰。

在 Android 的 XML 布局体系中，我们习惯使用 match_parent 和 wrap_content 来显式声明尺寸策略。而在这里，这种声明被“隐含”进了规则体系中，变成了一种默认行为。

和 Web 的 Flexbox 相比，两者在模型层面高度一致，但 HarmonyOS 的实现明显更“严格”。它几乎没有 CSS 那种“兜底式”的隐式行为，一切都需要你明确写出来。

这种设计带来的结果是：学习成本更高，但一旦理解之后，控制力也更强。

到目前为止，我对整个布局系统形成了一个相对稳定的认知模型。布局的第一步，是确定主轴方向，也就是选择 Row 还是 Column。接下来，所有子元素默认按照内容尺寸进行布局，不会主动扩展。然后，通过 layoutWeight 去参与剩余空间的分配，最后再用 justifyContent 和 alignItems 去控制分布和对齐。这个过程里，每一步都是显式的，没有任何“系统帮你补齐”的部分。

当然，也还有一些没有完全验证清楚的问题。比如 layoutWeight 在多层嵌套结构中的行为，是否完全等价于 flex-grow；是否存在类似最小尺寸、最大尺寸的约束机制；以及在复杂布局下是否会产生明显的重布局开销。这些都属于更偏底层实现的问题，需要在更复杂的项目中继续观察。

但至少，从那个“两个文本挤在一起”的困惑开始，我已经能够清晰地回答：它为什么是这样的，以及我应该怎样去控制它。 这大概就是理解布局底层逻辑最有价值的地方。