👋 你好，欢迎来到我的博客！我是【菜鸟学鸿蒙】
   我是一名在路上的移动端开发者，正从传统“小码农”转向鸿蒙原生开发的进阶之旅。为了把学习过的知识沉淀下来，也为了和更多同路人互相启发，我决定把探索 HarmonyOS 的过程都记录在这里。
  
  🛠️ 主要方向：ArkTS 语言基础、HarmonyOS 原生应用（Stage 模型、UIAbility/ServiceAbility）、分布式能力与软总线、元服务/卡片、应用签名与上架、性能与内存优化、项目实战，以及 Android → 鸿蒙的迁移踩坑与复盘。
  🧭 内容节奏：从基础到实战——小示例拆解框架认知、专项优化手记、实战项目拆包、面试题思考与复盘，让每篇都有可落地的代码与方法论。
  💡 我相信：写作是把知识内化的过程，分享是让生态更繁荣的方式。
  
   如果你也想拥抱鸿蒙、热爱成长，欢迎关注我，一起交流进步！🚀

摘要

页面在竖屏手机上显示正常，切到横屏或在折叠屏小屏态下就看不到底部按钮——这是开发阶段很容易漏掉的问题。宽度方向的适配已经有大量资料，但高度方向溢出导致操作按钮不可见，排查起来要绕一个弯，原因值得专门说一次。

一、短屏是一个真实的开发场景

所谓"短屏"，并不是某一种特定的设备形态，而是指在当前运行状态下，页面的可用高度明显小于设计时的预期。出现这种状况的情况有几类：

横屏状态。 手机横置后，屏幕的宽高对换，高度会急剧缩小。一块分辨率为 2400×1080 的设备，横屏后可用高度大约只有原来的 45%。

折叠屏小屏态。 折叠屏在外屏或折叠状态下，屏幕比例接近方形，高度偏小。

字体变大以后。 用户在设置中调大系统字号，会导致页面内文本组件撑开更多高度，原本刚好放得下的内容，变大之后就超出了屏幕范围。

多任务分屏。 应用在分屏模式下获得的窗口高度，远低于全屏。

这几种场景有一个共同的结果：页面总高度不变，但可用高度缩水，布局里"位置靠下"的组件就会被顶出视口。

二、固定高度页面会出什么问题

先看一种常见的写法：

// 问题示例：整页使用 Column + 固定高度排列
@Entry
@Component
struct FixedLayoutPage {
  build() {
    Column() {
      // 标题区，固定高度
      Row() {
        Text('填写信息')
          .fontSize(20)
          .fontWeight(FontWeight.Medium)
      }
      .width('100%')
      .height(56)
      .padding({ left: 16, right: 16 })

      // 内容区，也写了固定高度
      Column() {
        TextInput({ placeholder: '请输入姓名' }).height(48).margin({ top: 16 })
        TextInput({ placeholder: '请输入手机号' }).height(48).margin({ top: 12 })
        TextInput({ placeholder: '请输入邮箱' }).height(48).margin({ top: 12 })
        TextInput({ placeholder: '请输入地址' }).height(48).margin({ top: 12 })
        TextInput({ placeholder: '备注信息（选填）' }).height(48).margin({ top: 12 })
      }
      .width('100%')
      .height(400)  // ← 固定了高度
      .padding({ left: 16, right: 16 })

      // 底部按钮区
      Button('提交')
        .width('100%')
        .height(48)
        .margin({ top: 24, left: 16, right: 16 })
    }
    .width('100%')
    .height('100%')
  }
}

这段代码在竖屏 6.7 英寸手机上可能完全正常，按钮清晰可见。但在横屏状态或折叠屏小屏态下，内容区的固定高度 400vp 加上标题区 56vp 再加上按钮 48vp，总计已经超过可用高度，底部按钮就被推到屏幕外面去了。

问题的根本不是按钮出了什么错，而是内容区占用了固定的像素数量，无法根据实际窗口高度收缩。

三、标题区、内容区、底部操作区如何划分

在需要垂直铺满整个页面的场景中，官方推荐的思路是将页面划分为三个区域，各自承担不同的职责：

区域	高度策略	说明
标题区（Header）	固定高度	品牌标识、页面标题、导航按钮，高度相对稳定
内容区（Content）	弹性拉伸，内部可滚动	表单、列表、详情内容，随窗口高度自适应
底部操作区（Footer）	固定高度，始终贴底	确认、提交、跳转等关键按钮

这三个区域共同组成一个撑满整个页面的 Column。其中内容区承担了"弹性"的责任：不管当前窗口高度如何变化，它都自动占用标题区和底部操作区"剩下来"的空间，不多也不少。

四、内容区改造成可滚动结构

让内容区弹性拉伸并支持内部滚动，核心用到两个机制：

layoutWeight 属性： 根据 ArkUI 官方说明，layoutWeight 用于设置组件在父容器主轴方向上的权重，父容器会在分配完其他固定尺寸子组件的空间后，将剩余空间按权重分配给设置了 layoutWeight 的子组件。这正是内容区弹性拉伸所需要的能力。

Scroll 组件： 当内部内容高度超出 Scroll 容器本身的高度时，用户可以通过手势滚动查看完整内容，而不会撑开容器本身。

下面是改造后的结构：

// 改造后：三段式页面结构，内容区可滚动
@Entry
@Component
struct AdaptiveLayoutPage {
  build() {
    Column() {

      // ① 标题区：固定高度，不参与弹性分配
      Row() {
        Text('填写信息')
          .fontSize(20)
          .fontWeight(FontWeight.Medium)
      }
      .width('100%')
      .height(56)
      .padding({ left: 16, right: 16 })
      .backgroundColor('#F5F5F5')

      // ② 内容区：用 layoutWeight(1) 占用剩余空间
      //    内部使用 Scroll 包裹，内容超出时可滚动
      Scroll() {
        Column() {
          TextInput({ placeholder: '请输入姓名' })
            .height(48)
            .width('100%')
            .margin({ top: 16 })
          TextInput({ placeholder: '请输入手机号' })
            .height(48)
            .width('100%')
            .margin({ top: 12 })
          TextInput({ placeholder: '请输入邮箱' })
            .height(48)
            .width('100%')
            .margin({ top: 12 })
          TextInput({ placeholder: '请输入地址' })
            .height(48)
            .width('100%')
            .margin({ top: 12 })
          TextInput({ placeholder: '备注信息（选填）' })
            .height(48)
            .width('100%')
            .margin({ top: 12, bottom: 16 })
        }
        .width('100%')
        .padding({ left: 16, right: 16 })
      }
      .width('100%')
      .layoutWeight(1)  // ← 核心：占用标题区和底部操作区之外的全部剩余高度
      .scrollable(ScrollDirection.Vertical)
      .scrollBar(BarState.Auto)

      // ③ 底部操作区：固定高度，不参与弹性分配，始终可见
      Column() {
        Button('提交')
          .width('100%')
          .height(48)
          .type(ButtonType.Capsule)
      }
      .width('100%')
      .padding({ left: 16, right: 16, top: 12, bottom: 12 })
      .backgroundColor(Color.White)
    }
    .width('100%')
    .height('100%')  // 整个页面撑满窗口
  }
}

五、关键操作按钮如何保持可见

改造后底部操作区之所以始终可见，原因是它和标题区一样，都没有设置 layoutWeight，在父容器 Column 的布局计算中，它们会先被分配固定高度。剩余的空间才由设置了 layoutWeight(1) 的 Scroll 区域独占。

这个逻辑可以用一句话概括：固定的先走，剩下的全给 Scroll。

无论窗口高度是 800vp 还是 320vp，底部操作区都稳稳占据自己的 72vp（48vp 按钮 + 12vp 上下内边距），不会被内容区挤掉。

一个值得关注的细节是：底部操作区不应该写在 Scroll 的内部。如果把按钮放进了 Scroll 里面，它会随内容一起滚动，用户可能需要拖动到底部才能看到按钮，这在高度特别小的短屏场景下体验非常差。

六、字体变化后再验证一次

用户字号调大是另一类容易忽略的短屏诱因。系统字号变大后，TextInput 的占位符文本、标签文字都会变大，但如果组件本身设置了固定高度（如 height(48)），内容可能出现截断；如果没有固定高度，组件会自然撑开，导致内容区整体变高。

两种情况都会带来问题：

• 固定高度：文字被截断，显示异常
• 不固定高度：内容区总高度增加，在小屏下溢出更严重

处理方法是：对于内容区内的表单组件，高度可以设置一个合理的最小值而非绝对固定值，或者干脆不设置高度，让组件根据内容自然撑开。因为内容区的外层已经是 Scroll，即使总高度超出 Scroll 的容器高度，用户也可以通过滚动访问全部内容，底部按钮不受影响。

对于标题区和底部操作区，固定高度是合理的，但内部文字尽量使用 maxFontScale 做限制，避免在极大字号下出现布局异常。这部分能力在 ArkUI Text 组件的字体相关属性中有说明，实际项目中建议在对应 SDK 版本中核实属性可用性。

七、横屏状态为什么也是短屏测试场景

横屏是最容易复现短屏问题的手段，因为不需要折叠屏，任何手机都可以操作。

在 HarmonyOS 应用开发中，如果 module.json5 里 abilities 的 orientation 配置为 unspecified 或 user_rotation，应用就会响应设备旋转，进入横屏。此时窗口的宽高互换，高度急剧降低。

测试时可以关注以下几点：

• 进入横屏后，页面底部按钮是否仍然可见，不需要滚动就能直接点击；
• 进入横屏后，内容区是否可以正常滚动，不会卡住；
• 从横屏切回竖屏，布局是否正常恢复，没有残留异常。

如果应用需要感知窗口尺寸变化（例如在宽度增大时切换双栏布局），可以通过 window.on('windowSizeChange', callback) 监听窗口尺寸变化事件，在回调中根据新的窗口尺寸更新状态变量，触发 ArkUI 的响应式重绘。

// 监听窗口尺寸变化（示例，根据官方接口定义组织）
import { window } from '@kit.ArkUI'

// 在 UIAbility 的 onWindowStageCreate 或页面的 aboutToAppear 中注册
windowInstance.on('windowSizeChange', (size: window.Size) => {
  // size.width 和 size.height 单位为 px
  // 使用 vp 换算时需要结合屏幕密度
  console.info(`窗口尺寸变化：宽=${size.width}，高=${size.height}`)
})

八、几个值得单独注意的地方

layoutWeight 生效有前提。 它只在直接父容器是 Row 或 Column 时生效，且父容器必须有明确的尺寸（比如 height('100%') 或固定高度）。如果父容器高度是 auto（即由子组件撑开），layoutWeight 无从分配剩余空间，效果会失效。

Scroll 的直接子组件只能有一个。 Scroll 组件只接受一个直接子组件。如果需要在可滚动区域内放置多个并列的内容块，需要用一个 Column 或 Row 包裹后再放进 Scroll，而不是直接在 Scroll 里并列写多个组件。

不要在 Scroll 内的子组件上设置 height('100%')。 Scroll 内部的子组件高度设置为 100% 在某些情况下会导致滚动失效，因为子组件高度等于 Scroll 容器高度，不存在可滚动的溢出内容。子组件应该由自身内容决定高度，或者设置比 Scroll 容器高的固定高度。

底部安全区域。 在使用全面屏或异形屏设备时，底部可能有系统手势条的安全区域，直接把按钮放在页面底部可能和手势条重叠。可以在底部操作区加 padding({ bottom: ... }) 并结合安全区域相关设置处理，具体配置方式参考官方文档中关于沉浸式窗口和避让区的说明。

九、页面高度适配排查清单

当遇到页面在某些设备或状态下底部内容不可见时，按以下顺序排查：

1. 确认页面根容器高度 — 根 Column 或其他容器是否设置了 height('100%')，没有的话整个布局无法撑满窗口；
2. 检查内容区有没有固定高度 — 固定高度是短屏溢出的最常见原因，改为 layoutWeight(1)；
3. 确认 Scroll 是否包裹了内容区 — 仅靠 layoutWeight 让内容区弹性收缩还不够，内容多时仍需滚动；
4. 检查底部按钮是否在 Scroll 外部 — 在 Scroll 内部的按钮会随内容滚动消失；
5. 切换到横屏验证 — 最快的短屏复现方式；
6. 调大系统字号再验证 — 字体变化会改变实际内容高度，要单独测试一次；
7. 检查 layoutWeight 的父容器是否有明确高度 — 父容器高度 auto 会导致 layoutWeight 失效；
8. 底部安全区域 — 确认按钮是否因为手势条区域被遮挡。

开发经验总结

• 页面高度适配的核心是：固定高度区域（标题、底部操作）先分配，剩余空间全部交给可滚动的内容区，用 layoutWeight(1) 加 Scroll 组合来实现。
• 横屏是成本最低的短屏测试手段，不需要折叠屏设备，任何手机都可以直接验证。
• layoutWeight 有生效前提，父容器必须有明确尺寸且是 Row 或 Column，这一点比 layoutWeight 本身更值得注意。
• 字体变大引发的高度溢出，和短屏本质上是同一个问题，统一用可滚动的内容区来应对。
• 底部操作区必须放在 Scroll 外部，这是保证关键按钮始终可见的前提。

---

如果你正在处理类似的页面结构，可以重点观察一下项目里所有使用"固定高度内容区 + 底部操作按钮"组合的页面，在横屏模式下逐个检查一遍，这类问题通常集中在表单页、详情页和设置页。

📝 写在最后

如果你觉得这篇文章对你有帮助，或者有任何想法、建议，欢迎在评论区留言交流！你的每一个点赞 👍、收藏 ⭐、关注 ❤️，都是我持续更新的最大动力！

我是一个在代码世界里不断摸索的小码农，愿我们都能在成长的路上越走越远，越学越强！

感谢你的阅读，我们下篇文章再见～👋

✍️ 作者：菜鸟不学编程
🧵 本文原创，转载请注明出处。