做 Flutter 开发这几年，我最大的感受就是布局这件事，看着简单，写起来全是细节。Flex 往哪嵌、间距放在哪一层、宽度到底用 double.infinity 还是 MediaQuery.of(context).size.width，稍有偏差，真机上一跑就是满屏的 overflow 警告，更别提不同屏幕尺寸下的布局重叠和间距错乱。今天这篇东西不聊虚的，就把 Flutter 布局里跟间距精细化控制、响应式设计相关的实操细节一次讲透，内容既适合刚入门想搞懂 Flex 布局的初学者，也适合已经做了几个项目但总觉得布局代码越写越乱的同学。我会结合大量的实际案例、排坑经验和可复用的代码范式，争取让你读完就能直接在自己的项目里落地。
1. 布局的本质：先把约束和尺寸模型搞明白
1.1 约束向下传递，尺寸向上回报
很多人在布局上反复踩坑，根本原因是没吃透 Flutter 的两段式布局模型。父组件会给子组件一个 BoxConstraints，这个约束里写了“你最大能多大、最小能多小”；子组件在接收到约束后，根据自身内容算出一个实际尺寸，再把这个尺寸告诉父组件；父组件拿到尺寸后决定子组件放在哪里。整个过程就是“约束向下传递，尺寸向上回报”，你写的每一层布局都在这个模型里运行。
打个比方，这就像老师给学生安排座位：老师（父组件）先划定一片区域，说“这个桌子的宽度可以在 50 到 100 之间”，学生（子组件）根据自己要放的东西决定最终占多大，然后举手告诉老师“我要 80 宽”。老师再根据一排有几个学生、要不要留过道，去安排每个学生的位置。Flutter 的 Row、Column、Stack、Container 这些组件，本质上都在干这件事。
理解了这一点，你就会明白为什么很多布局问题不是“多写一个 SizedBox 就能解决”的。比如你有一个 Column，里面放了一个很长的文本，Column 从父级拿到了一个有限的最大高度约束，文本在垂直方向上放不下，于是报出 RenderFlex overflowed。你光在那里调间距、改 padding 是没有用的，正确思路是判断是否给文本加了 Flexible/Expanded，或者是否限制了最大行数。布局问题的根源往往在约束链路上，而不是某个具体属性的数值。
1.2 间距的三种实现路径，别一把梭
Flutter 里控制间距的主要手段有三种：Padding、SizedBox、Container 的 margin。三种方式都能实现视觉效果上的“留白”，但语义和适用场景差别很大，很多人从来不分，导致后期维护非常痛苦。
Padding 是给某个组件内部增加留白。比如一个按钮的文字离边框太近，你给按钮包一层 Padding，或者直接给按钮的 padding 属性设值，这是“内容与容器边缘的距离”。SizedBox 则是直接开辟一块指定宽度或高度的空间，最常见的就是 SizedBox(height: 12) 放在两个组件中间，或者 SizedBox(width: 8) 放在 Row 的两个子组件之间，这句代码只做一件事：隔开 12 个逻辑像素。Container 的 margin 则表示“这个组件与外部其他组件之间的距离”，语义上属于外围间距，比如卡片与卡片之间的间距，就很适合用 margin。
我的习惯是：同一排内的元素间距优先用 SizedBox(width: x)，上下两个元素之间的间距优先用 SizedBox(height: x)，一个容器内部的内容留白优先用 Padding，卡片之间的间隙优先用 Container 的 margin。这样做的好处是，代码一读就能知道这个间距是“内部留白”还是“外部间隔”，后续要调整，查找定位也快。最怕的就是有人为了让布局缩得更短，把间距全都塞进 Container 的 padding 里，结果视觉上是通了的，但实际上破坏了结构语义，后面接手的同事想改间距，得一层层拆开猜。
1.3 为什么零散间距会变成维护灾难
很多 Flutter 项目跑了一年半载之后，布局代码里到处都是 SizedBox(height: 8)、SizedBox(height: 12)、SizedBox(height: 16) 这种散装间距。单看每一处都没问题，但放在整个项目里会发现间距毫无规律，有的地方 8，有的地方 9（对，有人会因为像素微调写出 9 这种数），有的地方 12，有的地方 14，视觉上非常不统一。而且设计师改一版规范之后，你没法全局替换，只能一个一个点开改，改着改着就漏了，最终线上出现各种“对齐了又好像没对齐”的界面。
这不是 Flutter 的问题，而是项目里缺少“间距设计体系”。在 Web 端，我们习惯用 CSS 变量定义 spacing-1、spacing-2 这类语义化令牌；在 Flutter 里，同样可以把间距收拢成一组常量，布局代码里不再直接写数字，而是引用常量名。这样做的最大价值不是省几个字符，而是让“间距”成为可维护的设计资源，设计师改规范的时候，你只需要改一个文件。
2. 精细化间距控制：建立自己的 spacing 体系
2.1 从设计稿到代码，间隔要遵循 8pt 网格
先说一个基础共识：绝大多数设计系统（包括 Material Design）都推荐 8pt 网格。也就是说，界面里的间距、组件尺寸、圆角这些值尽量是 8 的倍数：8、16、24、32、48。当然也会用到 4 作为细分粒度，比如 4、12、20，但极少出现 6、14、18 这种半吊子数值。我之前接过一个项目，原始的設計稿里按钮高度是 47、间距是 13，接手的人每次还原都痛苦得要死，后来跟设计师沟通改成 48 和 16，视觉效果几乎没差别，但所有布局都清爽了。
在 Flutter 里落实 8pt 网格，我建议定义一套间距常量，从 2 到 48 都能覆盖。粒度小一点没关系，关键是命名要有语义，不要叫 sp1、sp2，至少要叫 spaceXXS、spaceXS、spaceS、spaceM、spaceL、spaceXL，这样代码里写 SIZEDBOX 的时候，光看名字就知道这个间距是“很小”还是“较大”。
当然，不是所有场景都必须机械地按 8 来。比如两个图标之间的视觉间距，因为图标本身有透明区域，2 或 4 的间距反而更接近设计稿的实际观感。所以这套体系的粒度要做到 2、4、8、12、16、24、32、48，既能满足常规节奏，又能应付细节微调。
2.2 用 Dart 扩展或常量类统一管理间距
接下来上硬货，我提供两种主流做法，你可以根据自己的团队风格选。
第一种是常量类：
/// 全局间距规范，请统一从这里取间距值 class AppSpacing { AppSpacing._(); static const double xxs = 2; static const double xs = 4; static const double sm = 8; static const double md = 12; static const double lg = 16; static const double xl = 24; static const double xxl = 32; static const double xxxl = 48; }使用的时候就是 SizedBox(height: AppSpacing.md)。这种做法的好处是简单直接，依赖关系一目了然，适合中小型项目。缺点是用着用着就容易在局部直接写数字，因为AppSpacing.md比裸写12长不少，人的惰性会很诚实。
第二种是给 BuildContext 扩展一个 spacing 属性，这样在设计稿上看到一个间距，可以先换算成“这是几档”，然后直接写context.spacing.md：
extension AppSpacingX on BuildContext { AppSpacing get spacing => const AppSpacing(); }不过说句实在话，我的经验是：对于大多数团队，第一种常量类已经够用了，第二种更多是为了代码整洁度，但不能解决“不写数字”这件事，团队纪律才是关键。真正能让间距体系落地的方法是在 Code Review 里强制要求：不允许出现裸数字间距。一旦执行一段时间，习惯就养成了。
2.3 列表项、卡片、分组组件的间距计算实例
有了间距体系，还得知道怎么算组合组件的间距。举一个最常见的例子：一个首页商品卡片，结构从上到下是图片、标题、副标题、价格标签。设计稿上图片和标题的间距是 12，标题和副标题是 4，副标题和价格是 12，卡片外边缘到内容边缘是 16。如果全部用 Column + Padding 来实现，嵌套会非常深。我的做法是：卡片外层用一个 Padding 统一搞定 16 的外边距，内部 Column 只负责内容排列，各个内容块之间用 SizedBox(height: AppSpacing.md) 和 SizedBox(height: AppSpacing.xs) 控制。
这里有一个容易被忽略的细节：当你用 Padding 统一处理外间距时，Column 里不要再额外给最外层元素添加 margin，否则会出现“双重间距”的问题，视觉上间距突然大一倍。我见过不止一次，有人给卡片加了一圈 padding 16，又给卡片内的标题加了 margin 16，然后发现标题位置不对，排查了半天。
另一个场景是消息列表里头像和文本的间距。Row 里有 CircleAvatar 和 Expanded 包裹的文本区域，两者之间用 SizedBox(width: AppSpacing.md) 就足够了。但如果文本区域的内部又有图标和文字，那么这个图标和文字之间的间距应该用 SizedBox(width: AppSpacing.xs)，不要在文本区域的外层再加 padding，否则会让整个文本区域离头像更远，和设计稿不一致。间距是叠加的，这一点很容易被忽略。
2.4 流式布局与 Wrap 的间距处理
间距处理还有一个容易踩坑的场景：动态标签列表、筛选列表、搜索历史这类“不知道有多少个、也拿不准总宽度”的内容。很多人第一反应是嵌套 Row + Expanded，但元素个数一多、宽度不一致，马上会出现溢出。这里应该用 Wrap，也就是常说的流式布局面板，它会在主轴放不下时自动换行。
Wrap 的 spacing 控制主轴方向（水平方向）的元素间距，runSpacing 控制交叉轴方向（垂直方向）的行间距。这两个参数非常好用，但也容易出问题：如果元素本身就带 margin，或者外层 Container 带着 padding，最终视觉上的间距就是 spacing + margin + padding 三者叠加的结果。为了减少不可控因素，我建议在使用 Wrap 的时候统一规则：元素内部的留白用 padding，Wrap 负责元素之间的间距，不要给每个子元素再加 margin。否则换行后间距会忽大忽小，视觉上非常乱。
还有一点，Wrap 默认的主轴对齐方式是 start，当整体宽度不足一行时，元素会靠左排列。如果你希望标签在筛选栏里均匀分布，可以使用 alignment: WrapAlignment.spaceBetween。但注意 spaceBetween 在只有两个元素时会分别顶到两端，如果你想要的是“元素之间保持固定间距且整体居中”，最好还是用 spacing + center 的组合，或者干脆在外面包一个中心对齐的 SizedBox。
3. 响应式设计：从适配屏幕到布局策略
3.1 响应式设计的核心工具：MediaQuery 和 LayoutBuilder
响应式设计的本质是让界面能根据不同屏幕尺寸、不同方向、不同可用空间，自动调整布局结构和尺寸。Flutter 里最常用的两个工具是 MediaQuery 和 LayoutBuilder。
MediaQuery 可以拿到设备屏幕信息，比如宽度、高度、设备像素比、安全区域等。在 Flutter 里，我最推荐用的是MediaQuery.sizeOf(context)来获取屏幕尺寸，而不是老的MediaQuery.of(context).size。原因是 sizeOf 会在 MediaQuery 变化时只重建依赖 size 的组件，性能更好，这是 Flutter 3.10 之后就推荐的新 API。
LayoutBuilder 的思路则不同，它不关心屏幕多大，只关心父组件给了它多大的约束，然后根据这个约束范围做出不同渲染。换句话说，LayoutBuilder 是“约束响应式”，更适合做界面局部区域的自适应。比如一个页面在宽屏下内容是左右两栏，在窄屏下变成上下两行，这种基于“可用宽度”切换布局的行为，用 LayoutBuilder 非常贴切。
很多人会纠结：到底用 MediaQuery 还是 LayoutBuilder？我的原则很简单：判断“整个页面怎么排”用 MediaQuery，判断“某一个区块怎么自适应”用 LayoutBuilder。举个实际例子，一个 Dashboard 页面，最外层根据屏幕宽度判断是否展示侧边栏，这是 MediaQuery 的活；而侧边栏里某个折线图，需要根据实际分配到的宽度决定图例排成一行还是两行，这就是 LayoutBuilder 的活。两者各司其职，代码结构也清晰。
3.2 Flex 布局的弹性区间：Expanded、Flexible 与 Spacer
在响应式设计里，最核心的容器就是 Flex 布局（Row 和 Column 的底层实现）。Flex 布局的精髓是“分配剩余空间”。Row 里有两个文本组件，宽度加起来不到 100，但屏幕宽度是 360，剩下的 260 个像素怎么分配？这就是 Expanded 和 Flexible 的职责。
Expanded 强制子组件填充所有剩余空间，比如头像右侧的文本区域，用 Expanded 包裹后就能自动占满剩余宽度，无论屏幕多宽，文本区域都会很自然地被撑开。Flexible 则不一样，它允许子组件在剩余空间里自由选择自己的尺寸，但并不是强制填满。给 Flexible 指定 flex 比值时，比如两个 Flexible(flex: 1) 和 Flexible(flex: 2)，Flex 会把剩余空间按 1:2 分配。
这里有一个高频坑：在 Row 里面，如果多个子组件都用 Expanded，但其中一个子组件的内部出现了不受约束的无限宽度，比如一个很长的字符串没有 maxLines，则 Expanded 并不能阻止文本的溢出。你需要对文本本身设置 maxLines 和 overflow 属性，否则 Expanded 只是把宽度分配给了文本组件，文本组件仍然可能渲染超长。我见过有人为了这个问题把一个好好的布局改成了 Stack + Positioned，简直是拿大炮打蚊子，正确解法就是文本加 maxLines: 1 + TextOverflow.ellipsis，或者包一层 Flexible + TextOverflow.clip。
Spacer 本质上就是 Expanded 的语法糖，一个空的灵活空间。很多人喜欢用它来把 Row 里的元素推向两端，比如左侧标题、右侧按钮，中间写一个 Spacer()。这个写法的好处是少写一个 Expanded，可读性也不错，但要注意 Spacer 不能放在有固定剩余空间需求的场景里，如果剩余空间为负数，Spacer 同样会引发 overflow。
3.3 GridView 与 Wrap 的自适应取舍
响应式页面绕不开网格。很多人的第一反应是 GridView.count，比如GridView.count(crossAxisCount: 2)，写起来很快，但 crossAxisCount 是固定值，在小屏和大屏上显示的列数完全一样，在平板和宽屏上每个格子会异常大，非常浪费空间。如果你希望列数随宽度自动变化，推荐使用 GridView.builder 配合 SliverGridDelegateWithMaxCrossAxisExtent：
GridView.builder( padding: const EdgeInsets.all(AppSpacing.lg), gridDelegate: const SliverGridDelegateWithMaxCrossAxisExtent( maxCrossAxisExtent: 200, mainAxisSpacing: AppSpacing.md, crossAxisSpacing: AppSpacing.md, childAspectRatio: 3 / 4, ), itemBuilder: (context, index) => ProductCard(product: products[index]), )maxCrossAxisExtent的意思是“每个格子最大宽度不能超过 200”，GridView 会依据这个值在主轴上自动计算出能放几列。当屏幕宽度从 360 变成 768 时，列数会自动从 2 变成 4，间距则始终由 crossAxisSpacing 控制。这样你就不需要写一堆 MediaQuery 判断。
还有一点要注意：childAspectRatio 是格子的宽高比，很多人布局乱跳、图片变形，都是因为这个比例设置得不合理。它的计算方式用逻辑像素做除法就好，比如你想让格子的宽度 200、高度 260，那比例就是 200 / 260 ≈ 0.77。不过我这里更推荐 3 / 4 这类规整比例，然后在格子里用 Column + Aysnchronous 布局去容纳内容，而不是死磕比例到小数位。
至于 Wrap，比 GridView 更适合做内容大小不固定的流式面板，比如搜索历史里的标签云。它不需要每个格子等宽，而是让每个子组件按自己的 intrinsic 宽度排列，放不下就自动换行。搜索热词相关的页面上，我经常用 Wrap 替代 GridView，因为标签的长度天然不统一，强行用 GridView 会搞得缝隙特别大。
3.4 定义自己的断点策略与响应式布局组件
响应式设计的关键不只是“宽度变了列数变”，而是整个布局结构是否跟随屏幕尺寸变化。移动端和桌面端的差异不只是宽度，还有导航模式、信息密度、交互方式。比如手机端底部导航栏，桌面端通常变成侧边栏；手机端商品列表是单列大图，桌面端是多列小图。这些布局层面的切换，需要一个统一的断点策略。
Flutter 中没有内置 breakpoint 概念，需要自己做一套轻量判断。我的习惯是定义一个简单的扩展方法：
enum ScreenType { compact, medium, expanded } extension ScreenTypeX on BuildContext { ScreenType get screenType { final width = MediaQuery.sizeOf(this).width; if (width < 600) return ScreenType.compact; if (width < 1024) return ScreenType.medium; return ScreenType.expanded; } }600 和 1024 是 Material Design 规范的参考断点，分别对应手机/可折叠设备、平板、桌面。实际项目中要根据自己的目标设备微调，但建议不要随便定 500、700 这种数值，因为设计稿、开发规范都习惯用这些标准档位来对齐。
有了 ScreenType，你就可以在页面级别做布局切换：
Widget build(BuildContext context) { return switch (context.screenType) { ScreenType.compact => const _PhoneLayout(), ScreenType.medium => const _TabletLayout(), ScreenType.expanded => const _DesktopLayout(), }; }这种写法很直白，也方便团队协作。每个布局文件各管各的，不会因为一个页面里塞满 if 判断而爆炸。当然如果你的项目结构不大，也可以在一个页面文件里用局部 Widget 分支，效果同样，但我不建议三层以上的 if 嵌套，那是灾难。
3.5 布局重叠问题：Stack、Positioned 与安全区域的正确姿势
布局重叠是响应式页面里最常见也最让人头疼的问题。造成重叠的原因通常有两类：一是用 Stack 放多个层级时，没有考虑内容的实际尺寸变化；二是没有处理系统安全区域，导致底部导航与全面屏手势条重叠。
Stack + Positioned 很强大，但 Positioned 是“绝对定位”，在有锚点定位的同时，也会忽略其他子组件的占位。所以如果 Stack 内的某个子组件内容变长、变宽，而你没有在 Stack 外面预留足够的空间，就会产生视觉重叠。我的经验是：Stack 尽量用于装饰性层级（比如图片上的渐变遮罩、角标），不要拿来做核心内容布局。如果确实需要内容层叠，建议先算好约束，或者用 fit: StackFit.passthrough 让未定位的子组件把 Stack 撑起来，再让定位组件基于这个尺寸去摆。
安全区域也是一个高频重叠来源。在 iPhone 上，底部如果直接放一个 Button，没有处理 bottom safe area，按钮就会顶到 Home 指示条。最简单的方式是外层用 SafeArea，或者用 Scaffold 的 bottomNavigationBar 自动处理。但如果你用了 Stack 作为根布局，SafeArea 可能只包裹了其中一层，另外一层仍然会顶到屏幕边缘。这里建议用 MediaQuery.paddingOf(context).bottom 来手动计算安全区域高度，在 Positioned 的 bottom 上额外加上这个值。
还有一类容易忽略的布局重叠，是键盘弹出引发的问题。比如一个页面底部有一个输入框，键盘弹起后，原本固定在 Stack 底部的按钮因为未考虑 ViewInsets，直接顶到键盘上沿，把输入框盖住了。处理方案是监听MediaQuery.viewInsetsOf(context).bottom，在键盘弹起时对底部间距做补偿。类似的案例我把它归到后面的常见问题里，说细一点。
4. 常见问题排查与面试考点整理
4.1 百分之九十的人都会遇到的 RenderFlex overflow 警告
写 Flutter 布局，一定会遇到这类黄色的黑边警告：RenderFlex overflowed by 28 pixels on the bottom。我看到好多人一开始都很慌，其实这个警告的信息量很大，它告诉你“当前这个 Flex 容器的高度不够，里面的内容超出了 28 个像素”。排查步骤我建议按顺序来：
第一，看警告发生在哪个组件。在 debug 模式下，触发 overflow 的组件会画出黄黑相间的条纹，点开 Flutter Inspector 能定位到具体 Widget。第二，确认该组件的约束来源。如果它在一个固定高度（比如 SizedBox(height: 48)）里，考虑内容是否超出了 48，这时候往往不是改容器高度，而是看内容是否能压缩；如果是文本，加 maxLines 或改字体字号。第三，判断是否缺少 Flexible/Expanded。Column 里的文本块如果可能很长，推荐用 Flexible + ListView 或 SingleChildScrollView 处理。
有一个很实用的排查技巧：把debugPaintSizeEnabled打开，也就是在代码里设置debugPaintSizeEnabled = true（需要 import 'package:flutter/rendering.dart'），然后看每个组件的绘制边界，能非常直观地看出哪个组件超出了父级范围。上线前记得关掉，不然会保留调试边框样式。
4.2 间距不一致：为什么界面上看起来忽大忽小
间距不一致是一个比较隐蔽的问题，经常出现在文本类组件上。原因是 Text 的默认 lineHeight 在不同平台、不同字体下可能不一样，比如中文系统和英文系统下字体渲染高度就不同。你在设计稿上看到的标题高 28，用默认 Text 渲染时实际可能不到 28，这意味着标题与下方内容的间距视觉上就会被“吃掉”一部分。解决方式是在 TextStyle 里显式设置 height，比如 height: 1.4，这样不同设备上的行高就是稳定的，间距的视觉效果也稳定。
另一种间距不一致和 Row 主轴对齐有关。当你用MainAxisAlignment.spaceBetween让两个元素分别贴左贴右，在窄屏上两个元素几乎贴在一起，在宽屏上中间就会隔得特别远，看起来像间距设置错了。这种情况不叫 bug，但确实会让界面在不同设备上观感差异巨大。如果业务上要求“不管屏幕多宽，两个元素之间的间隙始终是 16”，那就不该用 spaceBetween，而是用一个固定宽度的 SizedBox + 中间的对齐容器。
我自己的习惯是：凡是“固定间隙”的间距，坚决用 SizedBox；凡是“自动分配空间”的弹性布局，才用 Expanded 或 MainAxisAlignment.spaceBetween。千万不要混用，不然调试的时候你根本分不清某个间距到底是控件的固有宽度、margin、还是主轴对齐分出来的。
4.3 更多真实案例：底部弹窗里的 TextField 与键盘布局
我一次做消息发布页的时候，在底部弹窗（showModalBottomSheet）里放了一个 TextField，当键盘弹起时，整个弹窗没有跟随键盘上移，导致输入框被键盘完全挡住。排查后发现，showModalBottomSheet 虽然有isScrollControlled这个参数，但默认 false 时弹窗高度只到一半，键盘弹起后底部被遮挡。解决办法是给 showModalBottomSheet 设置 isScrollControlled: true，然后内部用 Padding 把MediaQuery.viewInsetsOf(context).bottom加到 Container 的底部 padding 上。
这个场景在面试中也经常被问到：如何让底部弹窗里的输入框避开键盘？其实核心就是理解 viewInsets 是键盘遮挡区域的高度，你把底部 padding 加上这个值，弹窗内容就会在键盘上方挤出来。类似思路也适用于聊天页面里输入框随键盘上移的场景。真实处理的时候记得再配合 AnimatedPadding 做一下平滑过渡，否则高度变化会很生硬。
4.4 面试高频考点：Flutter 布局相关问题的思考框架
顺着热搜词里的“flutter 面试题”，我也顺手整理了一下关于布局方面常见的面试考点。面试官问“谈谈 Flutter 的布局原理”时，你最好从“约束向下、尺寸向上”这个两段式过程讲起，最好能说出 BoxConstraints 的几个默认行为，比如 tight constraints、loose constraints 的区别。问“Flex 和 Wrap 的区别”时，要从“Flex 在主轴放不下会溢出，Wrap 会自动换行”这个本质差异回答，同时提一下 spacing 和 runSpacing 的作用。
问“如何实现响应式设计”时，要能讲出 MediaQuery 与 LayoutBuilder 的职责差异、断点策略的划分、Expanded/Flexible/Spacer 的适用场景，以及 SafeArea 对布局的影响。如果能顺手提一下“用 LayoutBuilder 做局部自适应与 MediaQuery 做全局断点的配合”，答案的层次会明显不一样。问“怎么避免布局重叠”，则把 Stack 定位、SafeArea 处理、键盘弹起三个场景都覆盖到，基本上就很难被问倒。
在实战里还有一个容易被问到的点：为什么不用MediaQuery.of(context).size而用MediaQuery.sizeOf(context)。答案是 sizeOf 会建立更细粒度的依赖关系，减少不必要的重建，这也是新版本 API 推荐用法的原因。你如果能解释到“依赖收集”这个级别，说明你对 Flutter 的重建机制是有理解的。
我在实际项目里踩过不少坑之后，现在对新项目的布局要求其实只有三条：间距必须走设计体系、响应式切换点必须收敛到统一策略、弹性布局和固定间距必须在代码层面划清边界。这三条看着简单，真能执行到位，布局代码的整体维护成本能降一半以上。你在动手排下一个页面之前，不妨先问问自己：这个间距是固定还是弹性？这个区域需要跟着全局屏幕走，还是只需要跟着父容器走？答案清楚了，布局怎么写都不会太跑偏。
