企业官网建设流程全解析

先说一个真实感受：在鸿蒙上跑 Flutter，很多人第一反应是“能不能跑起来”，其实真正磨人的不是引擎本身的兼容性，而是最基础的布局属性。尤其 Row 和 Column 的间距控制，看起来是两行代码的事，一旦遇到嵌套、动态列表、真机适配，各种距离不对、溢出、间距不生效的问题就全冒出来了。这篇文章不聊 SDK 安装，也不聊签名打包，就专心把 Flutter 在鸿蒙项目里 Row 和 Column 的间距控制讲透——从常规写法到原理，从坑点到可复用的代码，都是我实际调过一轮之后整理出来的东西。不管你是刚开始接触鸿蒙 Flutter 开发，还是已经踩了不少布局的坑，这份指南应该能直接帮你把问题理清。

1. 间距控制不简单：先搞懂 Row 和 Column 在鸿蒙项目里的定位

1.1 为什么间距控制会成为布局重灾区

Flutter 的布局体系里，Row 和 Column 是最基础的两个线性布局组件，一个管水平方向，一个管垂直方向。理论上它们没有自带“间距”属性，所有间距全靠子组件的外边距、内边距或者填充组件来实现。这套设计本身没问题，但在鸿蒙项目里会被放大成一个非常容易出错的点，原因是鸿蒙的 ArkUI 里，Row 和 Column 是原生自带 space 参数的。

比如在 ArkTS 里你可以直接写：

Row({ space: 12 }) { // 子组件 }

父组件一个 space 搞定所有子元素的间距，非常省事。但 Flutter 的 Row 没有这个参数，你只能用 SpaceX/SizedBox/MainAxisAlignment 自己拼。跨框架切换的时候，很多开发者的思路还停留在“父组件统一控制间距”的惯性里，到了 Flutter 这边就会一脸懵：为什么我写了space它不认？为什么间距忽大忽小？为什么有的间距生效了，有的没生效？

这就是第一坑：框架思维没有切换过来。Flutter 的间距控制是一种“子组件驱动”的模式，谁要间距谁自己负责，父组件只负责排列策略。用 ArkUI 的思路写 Flutter 的 Row，必然踩坑。

第二个容易被忽略的问题，是鸿蒙项目的屏幕适配。鸿蒙设备从手机、平板到折叠屏、车机屏，逻辑分辨率跨度极大。Row 和 Column 的间距如果用死了像素值（比如 SizedBox(width: 20)），在手机上看着挺舒展，到折叠屏上就挤成一团。ArkUI 那套自适应栅格用得习惯了，到了 Flutter 里如果没有一套间距管理策略，布局质感会严重下滑。

1.2 Flutter 与鸿蒙 ArkUI 布局思想的差异化对比

我在实际开发里总结过一个类比，方便团队里的新人快速理解：ArkUI 的布局像“中央集权”，父组件管间距、管对齐、管尺寸；Flutter 的布局像“地方自治”，每个组件自己申报自己的大小和边距，父组件只负责把它们摆到正确位置。这个差异直接决定了两套写法完全无法直接平移。

光看表格可能觉得还好，实际写起来差别很折磨人。比如 Flutter 的MainAxisAlignment.spaceBetween只会处理“剩余空间的分配”，如果子元素本身已经把整行占满，spaceBetween 是不会给你挤出间距的。而 ArkUI 的 space 是“不管满不满，每个间隔固定加这么多”，两者语义完全不同。

所以，在鸿蒙项目里写 Flutter 布局，第一件事不是写代码，而是把间距控制的目标理清楚：哪些间距要固定，哪些间距要弹性，哪些间距要跟随屏幕变化。理清楚了，Row 和 Column 的间距控制其实就三种武器轮番上阵：固定间距组件、对齐策略、灵活空间分配器。

2. Row 间距控制的五种方案与选型逻辑

2.1 固定间距的最优解：为什么不建议到处塞 SizedBox

水平方向控制 Row 子元素的间距，最直接的写法是在每个子元素之间塞一个SizedBox(width: 16)。这种写法新手最爱用，因为一眼就能看出来间距是多少，改起来也方便。但我自己在鸿蒙项目里踩过坑之后，对这种方式的态度从“可以用”转变成了“只在小范围内使用”。

先看一个典型的反面案例：

Row( children: [ Icon(Icons.home), SizedBox(width: 8), Text('首页'), SizedBox(width: 8), Icon(Icons.search), SizedBox(width: 8), Text('搜索'), ], )

这段代码有三个问题。第一，间距数值分散在 children 列表里，如果产品经理说“统一间距改成 12”，你得手动改每一个 SizedBox，漏改一个界面就会显得特别不整齐。第二，SizedBox 的 width 是固定像素，没有语义，新人根本看不出这个 8 到底是图标和文字之间的呼吸感，还是故意留的白。第三，也是最隐性的问题：SizedBox 占据了 children 的位置，后续如果需求变成“在某些条件下不显示某个组件”，间距逻辑很容易跟着错位。

我的做法是：把所有间距收敛成语义常量，然后写一个专门的间距组件。比如：

class Gap extends StatelessWidget { final double width; final double height; const Gap.horizontal(this.width) : height = 0; const Gap.vertical(this.height) : width = 0; @override Widget build(BuildContext context) { return SizedBox(width: width, height: height); } } // 使用 Gap.horizontal(Insets.sm),

这样间距自带语义，统一维护，后期做深色模式、大屏适配也比较方便。当然，SizedBox 本身依然是最底层实现，只是包了一层，让代码更好读、更好维护。

提示：别在 Row 里混用 SizedBox 和外部 Container 的 margin。一个行内组件用了 margin，另一个又用 SizedBox 撑间距，经常会出现两倍间距或者视觉上对不齐的问题。要么统一用 SizedBox，要么统一用 margin，混着来一定会乱。

2.2 对齐策略：MainAxisAlignment 如何帮你免费获得间距

Row 的水平间距，除了固定值的 SizedBox，还有一套“免费”方案：MainAxisAlignment。这套方案适合“间距不固定，但我要整体铺满、两端对齐或者三等分”的场景。

Flutter 给 Row 提供了六种主轴对齐策略：

Row( mainAxisAlignment: MainAxisAlignment.values, // 以下具体展开 )

• start：子元素统统靠左，间距为零，需要自己加。
• end：靠右排列。
• center：居中排列。
• spaceBetween：第一个子元素贴左边缘，最后一个贴右边缘，中间的间距均分。
• spaceAround：每个子元素左右都有相同间距，但两端只算一半。
• spaceEvenly：包括两端在内，所有间隙完全相等。

这里面最容易踩坑的是spaceBetween和spaceAround的区别。spaceBetween 适合“三个按钮分布在标题栏左右两侧”这种场景，比如返回键在左、操作按钮在右，中间隔开。spaceAround 适合“三个图标在页面底部均匀排列”。这两个一旦搞混，界面看起来会有微妙的差异，尤其是鸿蒙真机上，边缘的留白会被安全区那套逻辑放大，视觉上特别明显。

我举一个实际的项目场景：做一个底部操作栏，左边是“删除”，右边是“保存”，中间还要放一个“分享”按钮，要求三个按钮等距分布。用空间策略的话：

Row( mainAxisAlignment: MainAxisAlignment.spaceEvenly, children: [ TextButton(onPressed: _delete, child: Text('删除')), TextButton(onPressed: _share, child: Text('分享')), TextButton(onPressed: _save, child: Text('保存')), ], )

这样写的好处是间距不写死，屏幕宽了间距自动变大，屏幕窄了自动变小。这类弹性的间距需要在“不需要精确像素”的场景下大胆用，它本来就是 Flutter 布局体系为自适应而设计的。

2.3 Spacer 与 Expanded：用权重思维替代固定宽度

第三种控制 Row 间距的方式是Spacer，本质上是一个Expanded的轻量封装，专门用来“把子元素推开”。它的行为是占据剩余空间，让被推开的元素产生间距。

举个例子，左侧一个标题，右侧一个详情图标，中间的空隙不管屏幕多宽都可以自动拉开：

Row( children: [ Text('设置', style: TextStyle(fontSize: 18)), Spacer(), // 占据所有剩余空间 Icon(Icons.chevron_right), ], )

这种写法的价值在于：你不需要知道屏幕有多宽，也不需要计算间距像素，Spacer 自动把“多余空间”吃掉了。它比spaceBetween更灵活，因为你可以在一个 Row 里塞多个 Spacer，实现“左中右三块各自独立”的排列。比如：

Row( children: [ Icon(Icons.menu), Spacer(flex: 1), Text('中间标题'), Spacer(flex: 1), Icon(Icons.more_horiz), ], )

这段代码的效果是：菜单图标在左，更多图标在右，标题严格居中。如果用 spaceBetween，这个效果很难实现，因为 spaceBetween 只能保证首尾贴边，中间的标题不会自动居中。Spacer 的 flex 参数还可以控制多个空白区域的占比，本质上就是 Flex 布局的权重思维。

用 Spacer 的时候有一个特别注意：它不能用在 Row 的mainAxisSize等于 min 的情况下。如果 Row 已经设置成 MainAxisSize.min，那么 Row 自身只会包裹内容尺寸，没有“剩余空间”，Spacer 就会报错（RenderFlex 断言失败）。这一点在鸿蒙项目里更隐蔽，因为鸿蒙的 Row 默认就是自适应内容宽度，很多从 ArkUI 平移过来的代码反而会主动把 mainAxisSize 设置成 min，结果一行 Row 里放 Spacer 就崩了。

3. Column 垂直间距控制：从 margin 到 Expanded 的完整拆解

3.1 垂直间距最容易让人忽视的两个细节

Column 是纵向排列的，间距控制逻辑和 Row 相似，但方向上更容易出问题。第一类是视觉对齐问题，第二类是可滚动问题。

垂直间距的常规写法同样是 SizedBox：

Column( children: [ Text('标题'), SizedBox(height: 12), Text('内容描述'), SizedBox(height: 20), ElevatedButton(onPressed: () {}, child: Text('确认')), ], )

听着很简单，但实际操作里我会盯着两个问题看。一是CrossAxisAlignment默认是 center，也就是说 Column 里的子元素都会水平居中。当间距大小不一时，视觉上“中间这条线”会让人感觉距离判断错乱。比如两行文字，一行长、一行短，中间隔 20 像素，人眼的感知可能是“这两行不在一组”。所以垂直间距大的时候，一定要同时处理水平对齐方式。

二是Column嵌套Column时，间距会被“折叠感知”。注意这里的折叠不是 CSS 的 margin collapse，Flutter 里上下两个 SizedBox 的间距是累加的。但嵌套 Column 的场景，比如外面的 Column 设置了SizedBox(height: 16)，里面的 Column 又在首尾加了同样 16 的间距，最终视觉效果可能是 24 或者 32，因为父子的 padding、margin、gap 会叠加。这种“看起来间距变大了”的问题，排查起来很费劲，需要逐层打印计算。

3.2 用 Container margin 控制间距：语义与边界问题

除了 SizedBox，Container 的 margin 也是 Column 间距的常见来源。很多人喜欢写：

Column( children: [ Container( margin: EdgeInsets.only(bottom: 16), child: Text('第一段'), ), Container( margin: EdgeInsets.only(bottom: 16), child: Text('第二段'), ), ], )

这样写的好处是间距跟组件绑定在一起，组件挪走的时候间距也跟着消失，不会留下一个孤零零的 SizedBox。坏处是 Container 包裹 Text 之后，Text 的样式继承、点击区域、背景绘制都会发生微妙变化。

我在鸿蒙项目里遇到过一件很诡异的事：项目里大量使用 Container + margin 来做间距，结果某次升级后，部分 Text 的字体大小变了。查了一下午发现，Container 的constraints默认是BoxConstraints()，它会尽可能扩展自己，把本来 Text 自适应的宽度撑大的，加上 alignment 没设置，导致 Text 在 Container 里的排版位置变了，视觉上字体好像变大了。这个和间距无关，却是因为“用 Container 做间距”牵扯出来的后续问题。

所以我对 Container margin 控制间距的态度是：适合每个子组件本身就有独立背景、边框、圆角的场景，比如卡片列表、标签块。如果只是单纯的文字或者图标排列，优先用 SizedBox 或者 Gap，别为了加个间距让每个元素都套一层 Container。

注意：在 Column 里用 Container 的 margin 时，margin 的上下方向会参与CrossAxisAlignment计算，如果 Column 设置了crossAxisAlignment: CrossAxisAlignment.start，建议用margin: EdgeInsets.only(top: 12)而不是EdgeInsets.symmetric(vertical: 12)，后者可能导致子元素的左对齐基准线发生偏移，原因在于上下 margin 会改变 Container 自身在 Column 中占据的高度，进而影响后续基线对齐。

3.3 Expanded 和 Flexible 在 Column 里的间距使用场景

Column 的间距控制还有一个杀手锏：Expanded配合固定间距组件，实现“占满剩余空间”的效果。

比如在设计一个表单页面时，底部有一个保存按钮，要求按钮始终贴在屏幕底部。这时 Column 的结构可以是：

Column( children: [ Text('账号'), TextField(), SizedBox(height: 12), Text('密码'), TextField(), Expanded(child: Container()), // 占满剩余空间，形成弹性间距 ElevatedButton(child: Text('保存')), ], )

这里Expanded(child: Container())不是用来显示内容的，而是充当“弹簧”，把保存按钮顶到底部。它比用Spacer()更可控，如果需要在弹性距离之上再加一个固定距离，可以在 Expanded 外面包一层 Padding。

Flexible 和 Expanded 的区别经常有人搞混。Expanded 是强制占满剩余空间，Flexible 则允许子组件在不超过剩余空间的前提下自行决定是否占满（fit 属性可以控制）。在间距控制场景下，我通常用 Flexible 而非 Expanded 的情况是：当剩余空间很少的时候，Expanded 可能会导致子元素被迫压缩，而 Flexible 可以提供“空间够了就撑开，不够就收缩”的横向余量。这在 Column 里处理“按钮组跟随内容移动，但底部也要有落点”的需求时特别有效。

4. 鸿蒙环境下的间距适配：不只是 Flutter 的事

4.1 安全区、刘海、字体缩放：间距的隐形变量

Flutter 开发本来就自带一套逻辑像素体系，到了鸿蒙设备上，有几个变量会让 Row 和 Column 的间距显示效果大不相同。

第一个是安全区。鸿蒙系统的全面屏手势、底部横条、顶部状态栏区域，都会压缩可视区域。如果 Flutter 页面没有对 MediaQuery 的安全区做 padding，Column 底部的内容（按钮、输入框）很容易被手势条遮挡，而这时候你调间距根本没意义——不是间距的问题，是页面没有避开系统区域。

具体到 Row，出现在屏幕上边缘的横向按钮组，比如一个自定义标题栏放在 SafeArea 外部，左侧返回键会被状态栏吞掉一半。这时候 Row 的第一个子元素的间距调多少都不对，必须在 Row 外层包SafeArea，或者手动读取MediaQuery.of(context).padding.top作为 top 间距。在鸿蒙上，这个 top 值在不同机型（有刘海、无刘海、折叠屏外屏）差异巨大，绝对不能写死。

第二个是字体缩放。鸿蒙系统允许用户在设置里调整字体大小，这个缩放会直接影响 Text 组件的宽高，进而影响 Row/Column 的布局计算。如果你用 SizedBox 写死了文字间距，字体放大后文字变长变高，固定间距就会显得过于局促甚至溢出。所以在“文字密集 + 固定间距”的场景，建议间距基准值适当放宽，并且用MediaQuery.textScalerOf(context)做一次动态补偿。

第三个是鸿蒙窗口的dpr（设备像素比）。Flutter 内部用的是逻辑像素，但如果你的代码里有任何地方直接读取了原生平台的物理像素（比如通过鸿蒙侧的能力拿到的屏幕宽度），再和 Flutter 的间距常量混用，就会出现“间距忽大忽小”的灵异现象。遇到这种情况，先统一单位：Flutter 层只用逻辑像素，鸿蒙原生层的数据要除以 dpr。

4.2 横竖屏切换与折叠屏：间距策略必须跟着屏幕状态走

鸿蒙设备对横竖屏和折叠状态的支持特别丰富，这对 Row 和 Column 的间距控制提出了更高要求。

在手机竖屏状态下，页面的主要布局是 Column 纵向排列，Row 通常只用于行内元素。一旦横屏，可用宽度暴增，原本宽度固定的 Row 如果继续使用MainAxisAlignment.center且子元素较少，会产生大量空白，子元素间距不变但视觉上变散。这时候正确的做法是根据屏幕宽度决定 Row 的主轴对齐策略：宽屏用 spaceBetween 或者加 Spacer，窄屏用固定间距。

折叠屏更复杂：同一个 Row 在外屏宽度 300 多逻辑像素，展开后宽度可能翻倍。我在项目里的做法是定义一个全局的SpacingCalculator：

class SpacingCalculator { static double get horizontalMainGap { final width = WidgetsBinding.instance.window.physicalSize.width / WidgetsBinding.instance.window.devicePixelRatio; if (width > 720) return 24.0; if (width > 480) return 16.0; return 12.0; } }

把间距从“固定常量”升级成“根据屏幕宽度动态计算的常量函数”，Row 和 Column 的核心布局代码不用大改，只需要在创建间距时调用这个计算器。这样横竖屏切换和折叠屏展开闭合之后，间距会自然重新计算，不会出现“折叠之后挤成一团”的尴尬。

新增了动态间距函数后，记得在 State 里监听窗口变化并触发 setState。鸿蒙上的窗口尺寸变化事件不一定每次都走 Flutter 的 didChangeMetrics，有些折叠屏需要监听MediaQuery变化，常用的处理方式是在build里直接读取 MediaQuery，让系统在窗口变化时自动重建相关子树。

5. 常见问题与排查技巧实录

5.1 间距“不生效”的三种真实原因

我在调试鸿蒙 Flutter 项目的过程中，遇到“我明明写了 SizedBox，但间距就是没出来”的频率非常高。总结下来，真正的原因通常是下面三种：

父组件宽度或高度被限制死。比如一个 Row 外面套了一个SizedBox(width: 200)，Row 内部有三个子元素和两个 SizedBox(width: 30)，如果三个子元素自身的宽度已经超过 140，那么 SizedBox 的“间距”实际上会和子元素抢空间，视觉上间距被压缩甚至完全消失。记住：间距组件也是组件，它占据的宽度/高度一样要参与父布局的空间分配。当空间不够时，间距不会优先被保证，而是和其他子元素一起争夺空间。

MainAxisSize 设置不当。Column 如果设置了mainAxisSize: MainAxisSize.min，同时内部又有 Expanded 或者 Spacer，会直接触发 Flutter 的一个运行时断言错误，具体提示是类似RenderFlex children have non-zero flex but incoming width constraints are unbounded。这个问题在鸿蒙的 Flutter 版本日志里也多次出现，尤其是从旧版本升级后，原来可以跑过的代码突然报错，多半就是空间分配层级的严格化导致的。

外层使用了 Stack 或 Transform。在 Stack 中放一个 Positioned 的 Row，Row 的间距如果“无效”，要检查是不是 Stack 的 fit 属性把 Row 的约束设成了 loose。鸿蒙项目里用 Stack 做悬浮球、底部弹层特别常见，这块出问题的概率比较高。排查方式很简单：在 Row 外面包一层Container(color: Colors.red)，看红色区域的尺寸是否符合预期。如果红色区域宽度已经正确扩大，但你的眼睛觉得间距没生效，那可能是 Row 内部某个子元素使用了负 margin 或者 transform 位移，这类视觉欺骗是最容易中招的。

5.2 间距导致溢出红条：从报错信息反推间距问题

Flutter 里最让人心烦的报错是底部黄黑相间的“overflowed pixels”提示。Row 或者 Column 里的子元素总宽度/高度超过了父组件可用空间，渲染时就会溢出。这个报错和间距直接相关，因为间距占的空间往往比子元素本身还大。

遇到这种情况，我的排查顺序是：

1. 先在报错信息里找到超出的像素值，比如A RenderFlex overflowed by 27 pixels on the right.。
2. 把这段 Row 写成临时硬编码，只用两个子元素，把间距替换成 0，看是否能正常渲染。如果能正常，说明就是间距挤占了空间。
3. 再逐个恢复间距和子元素，找到超限的那个“最后一根稻草”。

还有一种情况不是 Row 本身溢出，而是 Column 嵌套的子组件溢出。比如一个 Column 里有 5 个 Row，每个 Row 内部又有很多 SizedBox 间距，在外层空间不够时，会有一个 Row 的文本被压缩换行或者被裁剪。这个时候的修复思路不是去调那个 Row 的内部间距，而是要回到 Column 上，考虑是否给某些区域设置 Expanded，或者把整块内容包进 SingleChildScrollView。

经验之谈：间距溢出和内容溢出不等于同一个问题。间距导致出界，优先砍间距或改对齐策略；内容本身太宽导致出界，优先换行或调整文字缩放。先把问题归好类再去改代码，能省一半调试时间。

5.3 排查间距“不同设备不一致”的独门方法

鸿蒙真机测试的时候，同一个页面在 Mate 系列和 P 系列上间距看起来不一样，甚至在模拟器和真机上都不一样。这种事新手容易慌，其实十有八九是这些原因：

• 设备的 dp 值不同。Flutter 的逻辑像素与 iOS 的 pt、鸿蒙的 vp 不完全等价，不同机型上报的 devicePixelRatio 有细微差异。
• 状态栏高度不一致导致 Column 的视觉起跑线不一样，间距本身没错，但相对屏幕的位置看起来变了。
• 字体缩放差异，文字变大之后挤压了间距的视觉空间。

我的排查方法是：在布局函数里临时打印MediaQuery的size、padding、devicePixelRatio，把不同设备的数据贴到一起对比。一旦发现间距常量相同，但屏幕尺寸不同，就要考虑使用“相对间距”（比如按屏幕宽度的百分比计算）而不是绝对间距。还有一种更靠谱的实践：以内容大小为基准计算间距，比如两个文本的间距取前一个文本行高的 0.5 倍，这样字体变化时间距会同步变化，视觉比例稳定。

6. 一套可直接上手的间距控制实现

6.1 间距常量与组件封装：告别魔数

说了这么多原理和坑，最后我直接给出一套在鸿蒙项目里验证过的实现。核心思路是用“间距语义化 + 自定义 Gap 组件 + 动态间距计算器”三层结构。

第一层是常量文件，明确制定间距刻度：

class Insets { static const double xxs = 4.0; static const double xs = 8.0; static const double sm = 12.0; static const double md = 16.0; static const double lg = 24.0; static const double xl = 32.0; static const double xxl = 48.0; }

第二层是 Gap 组件，负责把常量变成实际占位：

class Gap extends StatelessWidget { final double? width; final double? height; const Gap({super.key, this.width, this.height}) : assert(width == null || height == null, '只能指定宽或高中的一个，不能同时指定'); const Gap.h(double value) : width = value, height = null; const Gap.w(double value) : width = null, height = value; @override Widget build(BuildContext context) { return SizedBox(width: width ?? 0, height: height ?? 0); } }

用Gap.h(Insets.sm)就能在每个需要间距的地方生成一个语义明确的间距占位。

第三层是动态间距计算器，负责按屏幕宽度返回不同档位的间距值：

class AdaptiveGap { static double horizontal(double base) { final width = MediaQuery.of(context).size.width; if (width >= 700) return base * 1.5; if (width >= 450) return base * 1.2; return base; } }

这样的好处是业务代码里几乎不用改动间距逻辑，只需要在从常量取值的时候额外走一层自适应函数，就能让同一套代码在鸿蒙手机、折叠屏和平板上都有比较协调的间距体验。

6.2 一个典型页面的间距实战示例

以最常见的“列表详情页”为例，页面上方是一个标题栏，中间是信息展示区，底部是操作按钮。用前面说的间距体系写下来，结构大概是这样的：

Column( crossAxisAlignment: CrossAxisAlignment.start, children: [ // 顶部标题栏 Padding( padding: EdgeInsets.fromLTRB(Insets.md, Insets.sm, Insets.md, 0), child: Row( children: [ IconButton( onPressed: _back, icon: Icon(Icons.arrow_back), ), Gap.w(Insets.xs), Expanded( child: Text('详情', style: TextStyle(fontSize: 18)), ), IconButton( onPressed: _more, icon: Icon(Icons.more_vert), ), ], ), ), // 信息区 Padding( padding: EdgeInsets.all(Insets.md), child: Column( crossAxisAlignment: CrossAxisAlignment.start, children: [ Text('标题文字', style: TextStyle(fontSize: 22, fontWeight: FontWeight.bold)), Gap.h(Insets.sm), Text('这里是简短描述的第一行文字，用来展示详情页面的基本信息。'), Gap.h(Insets.lg), _InfoRow(label: '状态', value: '已启用'), Gap.h(Insets.md), _InfoRow(label: '创建时间', value: '2025-01-15 09:30'), ], ), ), // 用 Expanded 把底部按钮推到最下面 const Spacer(), // 底部按钮区 Padding( padding: EdgeInsets.all(Insets.md), child: Row( mainAxisAlignment: MainAxisAlignment.spaceEvenly, children: [ OutlinedButton(onPressed: _cancel, child: Text('取消')), SizedBox(width: Insets.md), // 固定间隔 ElevatedButton(onPressed: _confirm, child: Text('确认')), ], ), ), ], )

这个页面里 Row 和 Column 的间距各用到了三种策略：固定间距（Gap.w / Gap.h）、弹性间距（Spacer）、对齐策略（spaceEvenly）。它们在鸿蒙真机上跑起来，无论屏幕宽度怎么变，底部按钮都能贴合底部，标题栏左右图标不会贴到安全区边缘，信息区的文字间距在不同字体缩放下也能保持可读性。写到这里我想强调：间距控制从来不是“代码写完就完了”的事，一定要在三种以上不同尺寸的鸿蒙设备上过一遍。另外，实际开发时强烈建议把这篇代码里的间距常量打印出来，配合 Flutter Inspector 看清楚每一层 Padding、Gap 和 margin 的实际像素值，你会发现所谓的“间距玄学”，绝大多数都是数字没对应上。