SwiftUI 系列 02｜布局系统入门：VStack、HStack、ZStack、Spacer 和 frame 的真正用法

很多人学 SwiftUI 布局时，最容易陷入一种状态：

• VStack 我会
• HStack 我也会
• Spacer 好像也懂
• frame 也经常在写

但页面一复杂，就开始出现这些熟悉的问题：

• 为什么这个视图没有撑满
• 为什么加了 frame 还是没对齐
• 为什么 Spacer 一放就把别的东西挤乱了
• 为什么嵌套几层之后页面“说不上哪错了，但看着不对”

这说明很多时候我们并不是不会用这些 API，而是没有真正理解 SwiftUI 布局在做什么。

一、SwiftUI 布局最重要的不是容器名字，而是尺寸协商过程

如果只把布局理解成“用哪种 Stack 摆元素”，很快就会卡住。
因为 SwiftUI 布局真正的核心是一个尺寸协商过程，大致可以粗略理解成：

1. 父视图给出一个可用空间或提议尺寸
2. 子视图基于这个提议决定自己想要多大
3. 父容器再根据子视图返回的尺寸做摆放

也就是说，布局不是“父直接把孩子摆死”，而是父子之间不断协商。

一旦你理解了这个前提，很多看似玄学的问题就会变得清楚：

• 为什么有的 frame 只是包一层外壳
• 为什么 Text 和 Spacer 放一起时表现很不一样
• 为什么某些对齐问题本质上不是“对齐错了”，而是尺寸提议阶段就已经偏了

二、VStack、HStack、ZStack 真正区别的不是方向，而是“谁在主导哪种摆放逻辑”

表面上看：

• VStack 竖着排
• HStack 横着排
• ZStack 叠着排

这当然没错，但如果只记到这里，遇到复杂布局还是会迷糊。

更实用的理解是：

• VStack 主要在纵向组织子元素
• HStack 主要在横向组织子元素
• ZStack 主要在同一块区域里叠放多个元素

重点不是方向本身，而是你要想清楚：

• 当前页面最核心的主轴是什么
• 哪一层负责主布局
• 哪一层只是局部对齐和修饰

很多布局写乱，不是容器不会选，而是主次层次没分清。

三、Spacer 的价值不是“占空白”，而是“吃掉剩余空间”

很多人第一次用 Spacer，直觉会把它理解成“加一个空盒子”。

这会导致很多误用。

更准确地说，Spacer 的作用是：

在当前容器主轴方向上，尽可能吃掉剩余空间。

比如在 HStack 里，它吃横向空间；在 VStack 里，它吃纵向空间。

一旦这么理解，你就更容易判断：

• 这里需要的是固定间距，还是剩余空间分配
• 这里该用 padding，还是该用 Spacer
• 为什么 Spacer 放错位置后会把整个布局重心拉偏

很多页面“看起来差一点”，其实就是因为该用固定约束的地方用了 Spacer，结果布局被剩余空间分配逻辑悄悄改变了。

四、frame 最容易被误解：它不一定是在“修改内容大小”，很多时候只是包了一层布局盒子

这是 SwiftUI 初学者最容易卡住的点之一。

很多人写：

Text("Hello")
    .frame(maxWidth: .infinity)

以为自己是在把 Text 拉宽。
更准确地说，很多时候你是在给这个 Text 外面套一个更大的布局区域，而不是改变 Text 本身的内在内容尺寸。

这就解释了很多常见疑惑：

• 为什么看起来宽了，但文字还是没对齐到你想的位置
• 为什么再配合 alignment 才对
• 为什么同样的 frame 对不同视图效果不一样

所以 frame 的关键不在“改尺寸”，而在“你给视图添加了怎样的布局边界”。

五、很多布局问题真正的根源，是“主布局层”和“局部修饰层”混在一起

举个很常见的反模式：

• 外层一个 VStack
• 里面套好几层 HStack
• 每一层都加 frame
• 再混几个 Spacer
• 最后再靠 padding 修到能看

这种写法短期当然能做出结果，但后面一改文案长度、屏幕宽度或者动态字体，布局就开始漂。

问题的根源往往不是某个 API 用错，而是：

• 哪层负责主结构
• 哪层负责局部对齐
• 哪层只是视觉修饰

没有分层。

布局一旦没有层次感，后面就会变成“靠一堆 modifier 临时拽位置”，而不是靠结构自然成立。

六、一个更实用的布局思考方式：先定主轴，再定剩余空间，再定局部对齐

如果我今天要搭一个稍微复杂点的页面，我通常会按这个顺序想：

1. 这块区域是横向主导还是纵向主导。
2. 剩余空间该留给谁吃。
3. 哪些地方需要固定间距，哪些地方需要弹性空间。
4. 哪些地方只是局部对齐，不该反过来影响全局结构。

这个顺序能明显减少“越修越乱”的情况。
因为它逼你先决定结构，再决定修饰，而不是一上来就靠 modifier 堆结果。

七、为什么很多 SwiftUI 页面“看起来总差一点”

很多页面问题其实不是大错，而是结构表达不够清楚。

常见表现包括：

• 信息块之间关系不够稳定
• 文字一长就把别的东西挤歪
• 同样的卡片在不同屏幕下比例怪怪的

这类问题经常不是“少一个参数”，而是：

• 空间分配逻辑没想清
• 主布局轴和局部修饰混了
• 该固定的地方没固定
• 该弹性的地方又被写死了

所以真正学布局，不是学 modifier 列表，而是学会判断空间应该如何被分配。

八、结论：SwiftUI 布局入门真正要学的，是空间协商而不是控件名称

如果只用一句话总结，我会说：

SwiftUI 布局真正要掌握的，不是 VStack、HStack、Spacer 和 frame 分别长什么样，而是父视图如何提议尺寸、子视图如何回应尺寸、容器又如何基于这些结果完成摆放。

一旦这个基础关系立住了，很多布局问题都会从“玄学”变成“可推理”。