半模态高度自适应全解析：从CSS到小程序的方案与避坑指南

半模态高度自适应，我一直觉得是个“反直觉”的命题。以前做弹层组件，产品需求里写着“高度随内容自适应”，听起来很简单，一旦你真拿它去实现，就会发现页面里几乎每个结构都要为这句话服务，踩坑点密集。这篇文章想把半模态高度自适应的原理、CSS方案、JS测量方案、小程序和uni-app场景下的处理方式完整拆一遍，顺便把 flex 布局子元素宽度自适应、scroll-view 剩余高度计算、CSS 高度为宽度 50% 这类常被一起搜索的兄弟问题讲清楚，适合正在写弹层组件或者改造旧弹层的人参考。

1. 半模态不是半个弹窗：它要自适应的是哪一维高度

1.1 半模态形态与“半”字的误解

半模态在移动端产品里出现频率极高。最常见的形态是底部弹层，比如分享面板、筛选器、商品规格选择，桌面端也有类似对话框。很多人一听“半模态”，第一反应是高度只有屏幕一半，这种理解会把实现方向带偏。半模态的“半”，语义更接近“保留上下文”，不是把页面切成两半。它允许主界面仍然可见，让用户知道自己在哪一屏，而不是像全屏弹窗那样把前一个页面完全盖住。

正因为这样，半模态的高度就很难用固定值表达。iPhone 的可用高度和 Android 不同，同尺寸下有没有底部小黑条也不同，页面里如果还有自定义导航栏或底部 TabBar，可分配高度又会被压缩一块。写死 600px 或写死 70vh，短期看能用，换一款机型或改一版视觉稿就露馅。所以你会看到大量“半模态高度能否自适应”的搜索，背后都是同一个诉求：弹层高度可以跟着内容走，在极端情况下又不会溢出屏幕。

这个诉求里藏着一个常见误区。很多人认为，只要把半模态根节点的高度设为 auto，让内容自己撑开就是自适应。实际开发中，auto 撑开只是最基础的一步，距离“可用”还很远。移动端底部弹层通常带内部滚动区，弹层弹出后主页面不能跟着滚，内容很长时弹层内部要有独立滚动；同时底部安全区要留白，顶部的圆角区域又不能被状态栏挡住。没有上限、没有滚动规则、没有安全区处理的“纯 auto”，在真机上不是自适应，是裸奔。

1.2 自适应不是一个方向，而是两条线同时作用

半模态高度自适应的本质，可以拆成两条线。第一条线是“容器随内容长高”，第二条线是“内容随容器收缩”。

第一条线处理内容少的情况。比如分享面板只有两行按钮，弹层应该是紧凑的一小坨，而不是占满半屏。第二条线处理内容多的情况。比如动态加载了一批筛选条件后，内容超过了屏幕可用高度，弹层外框要封顶，内部出现滚动条，而不是把底部按钮顶出屏幕或者让背景页面跟着滚动。

这两条线不是互相替代的关系，而是同一套组件在不同时刻呈现的不同状态。早期我做弹层时，习惯把整个弹层当成一个巨大的 scroll-view，觉得最省事。可用性很差：用户想操作底部“确定”按钮时，要先滚过一长串内容；而且弹层滚动会吃掉背景页面的手势，关闭手势和滚动手势冲突得很厉害。后来改成 header、可滚动内容区、footer 三段式才顺眼。而三段式布局恰恰要求高度计算更精确：外部只负责封顶，header 和 footer 固定，中间那一块才是真正的滚动区。

理解了这两条线，再看各种技术方案就清晰了。纯 CSS 方案适合容器上限比较宽松、内容高度相对稳定的场景；JS 动态测量适合内容异步变化、图片加载、节点增删导致高度不确定的场景；而小程序这种没有 DOM 测量能力的平台，还要额外依赖 SelectorQuery 这类 API 去补“内容真实高度”的缺失。下面几章按这条路径来展开。

1.3 弹层高度优先级的三个原则

我在项目里给半模态高度定过一组优先级，可以帮你判断某个方案对不对。第一，高度只能封顶，不能写死；第二，弹层内部滚动区要把 footer 或关键操作按钮留在可视区；第三，所有涉及自适应的地方都要考虑键盘和安全区这两个“外部变量”。

这三点听起来简单，却会在细节上反复挑战你。比如只给外层加了 max-height，但 flex 子项没有处理好，内容一多照样溢出圆角区域。又比如动态算出高度之后，每次内容变化都触发过渡动画，弹层看起来像在呼吸，体验反而很差。这些问题不是某个框架特有的，而是所有带滚动和自适应的 UI 组件都会遇到的通病。后面我会在具体实现里反复回到这三条原则。先抛个结论：半模态高度能自适应，但别指望一个 CSS 属性解决，通常需要“外层限高 + 内容测量 + 滚动区兜底”三者配合。

2. 纯CSS的先决条件：从固定height改成max-height，再谈flex和aspect-ratio

2.1 基础结构：把 height 换掉，先让弹层“能长也能缩”

先看一个最简 Web 半模态结构：遮罩加底部面板。面板里是三段内容：标题区、可滚动内容区、底部操作区。很多人的第一版是这么写的：

css复制.half-modal {
  position: fixed;
  left: 0;
  right: 0;
  bottom: 0;
  height: 60vh; /* 第一次实现时拍脑袋写的高度 */
}

这段代码最开始可能还能用，等产品把内容从三个选项改成十个选项，问题就出现了。60vh 在全面屏手机上可能太高，在小屏手机又可能不够装。正确的基础写法是去掉固定 height，改成 max-height，让内容自己决定最终高度：

css复制.half-modal {
  position: fixed;
  left: 0;
  right: 0;
  bottom: 0;
  box-sizing: border-box;
  max-height: min(85dvh, calc(100dvh - 48px));
  display: flex;
  flex-direction: column;
}

.half-modal__body {
  flex: 1 1 auto;
  min-height: 0;
  overflow-y: auto;
  -webkit-overflow-scrolling: touch;
}

这里有几个细节值得展开。max-height 用的是 min(85dvh, calc(100dvh - 48px))，意思是“不能超过视口高度的 85%，同时顶部至少留 48px 给点击遮罩关闭”。dvh 和 vh 的区别在于移动端地址栏收起展开时，dvh 能跟随动态视口变化，传统 vh 在某些浏览器里会偏大或偏小。项目如果不用考虑太老的内核，可以直接上 dvh。

外层设了 max-height，但没显式给 height。内容不多时，面板高度等于内容高度；内容一多，max-height 会把面板封顶。flex 布局负责分配空间：header 和 footer 默认不会被压缩，body 的 flex: 1 和 min-height: 0 让它能在剩余空间不足时变成滚动区域。很多人漏掉的就是 min-height: 0。flex 子项的默认 min-height 是 auto，含义是“不小于内容高度”，这一条会让长内容把面板撑破，max-height 直接失效。

提示：用 flex 做弹层三段式时，min-height: 0 和 overflow-y: auto 必须成对出现。只写 overflow 不写 min-height，内容不会在指定区域内滚动；只写 min-height 不写 overflow，内容一多依然会溢出。

但这个纯 CSS 方案有一个边界：它依赖 flex 子项在容器 max-height 封顶后正确收缩。实测下来，现代浏览器的行为基本符合预期，但如果你发现某些 WebView 里内容还是往外顶，更稳妥的兜底方案是：不要只把滚动限制在 body，而是给外层也加一个 overflow: hidden，同时用 JS 测量后给 body 设具体高度。这个兜底思路，第三章会展开。

2.2 为什么不建议把百分比高度当成自适应方案

还有一种很容易踩坑的写法，面板高度写成 50% 或 80%，希望通过百分比实现“自适应不同屏幕”。百分比高度是一条链式规则：子元素高度百分比依赖父元素有确定高度。如果是从根节点一路 height: 100% 下来，比如 html, body, #app { height: 100% }，那 height: 50% 确实能拿到主屏一半；如果你的父级是某个内容自适应高度的容器，height: 50% 可能会算出 0 或表现得很奇怪。

半模态通常挂在 body 或应用根节点下面，写成 50vh 比 50% 可靠。但 vh 方案的问题回到前面：它只解决“不同屏高下占一半”，不解决“内容少时不要占一半”。内容只有两行，面板还是占了半屏，产品验收时多半会打回来。所以百分比和 vh 适合做“高度上限”，不适合做“唯一高度”。你可以把 80vh 放在 max-height 里，而不是放在 height 里。

如果一个半模态的定位是“必须占屏幕的某个固定比例，内容无论多少都不改变”，那就别用 CSS 硬撑内容了。直接给 height 设置百分比或 vh，里面再做滚动。这种场景比较少见，通常出现在二级筛选页，产品明确要求底部弹层固定占六成屏。这种情况下，高度不需要“随内容自适应”，反而简单很多。判断是做自适应还是做固定比例，是第一个要回答的问题。

2.3 flex 布局子元素宽度自适应：一个必须单独记忆的细节

半模态内容区经常是表单或选项网格，这就会牵扯到“flex 布局子元素宽度自适应”。很多人写九宫格或商品标签时，喜欢给每个格子 flex: 1，结果一行放几个不受控制，还常常跟间距打架。flex: 1 的真实含义是“在主轴方向尽可能瓜分剩余空间”，不代表“固定占几格”。

如果场景是“一行四个，宽度自适应”，最稳的写法是给子项一个明确的计算宽度，按间距数量补齐：

css复制.grid {
  display: flex;
  flex-wrap: wrap;
  gap: 12px;
}

.grid__item {
  width: calc((100% - 12px * 3) / 4);
  flex-shrink: 0;
}

一行四个，四个之间有三个空隙，每个空隙 12px，所以要减掉 36px，再除 4。写成百分比时一般不要用 flex: 0 0 25%，因为 flex-basis 的 25% 不含 gap，如果父容器没有额外的 padding，四列实际宽度会是 25% + 间距，第一行可能放不下第四个。用 calc 把 gap 的占用算进去，或者干脆让子项不换行，父容器横向滚动，都能绕开这个坑。

“flex 布局子元素宽度自适应”在很多文章里都被讲得很玄，其实核心就一句话：子元素的最终尺寸，由 content、flex-basis、flex-grow、flex-shrink、min-width 共同决定。宽度自适应的前提是对主轴尺寸有把握。半模态内容网格出现换行错乱时，第一步永远是检查 gap 有没有算进宽度，而不是往后排列方向调半天。

2.4 CSS 高度为宽度 50%：用 aspect-ratio 解决等比例问题

在弹层里做内容卡片时，常见需求是“卡片宽度撑满容器，高度等于宽度的 50%”，很多老项目会用 JS 监听 resize 再设置高度。现在可以不用这么麻烦。CSS 的 aspect-ratio 属性直接表达宽高比例：

css复制.card {
  width: 100%;
  aspect-ratio: 2 / 1;
  object-fit: cover;
}

aspect-ratio 的优先级很有意思：如果一个元素同时设置了显式 height 和 aspect-ratio，显式 height 会赢；如果宽度由布局决定但没有显式高度，浏览器会按比例推算出高度。这个属性特别适合自适应宽度场景下的等比例缩略图，半模态里的商品图、封面图都能用上，省掉一坨 resize 事件。

要提醒的是，aspect-ratio 只解决“外层盒子按比例”，不解决图片内容截取。如果里面是 img，还需要 object-fit: cover，否则图片会被拉伸变形。卡片文字很短时，aspect-ratio 高度会显得太空，可以考虑 aspect-ratio: auto 和具体比例组合使用，但绝大多数情况下 2:1 就够用。像热搜里“css高度为宽度的50%”这类问题，现在答案可以从 JS 改成纯 CSS，但前提是你确认目标环境支持 aspect-ratio。微信小程序基础库较新的版本也支持，实在需要兼容老版本，再用 padding-top + 百分比的老做法：padding-top: 50%，外层高度由 padding 撑起。

3. 动态内容的精确解法：ResizeObserver测量、键盘和安全区的博弈

3.1 先还原 auto，再量 scrollHeight

纯 CSS 方案对“内容静态”的半模态已经够用，但内容一旦异步变化，光靠 flex 和 max-height 就不够了。典型场景是：弹层打开后先渲染 loading，图片加载完成后内容高度突然翻倍；或者用户勾选条件后，筛选区动态展开，面板需要跟着长高。这个时候需要一套 JS 测量机制。

最直接的方法是，用 JS 拿到内容区的真实高度，然后跟上限比较。首先把内容容器的高度重置为 auto，让它按内容自然展开。紧接着读 scrollHeight 或 getBoundingClientRect().height。为什么强调先还原 auto？因为如果容器上残留上次设置的高度，scrollHeight 也会被限制住，读出来不是真实内容高度。

js复制function measureSheet() {
  const content = document.querySelector('.sheet-content');
  // 先清掉上次的固定高度，让它自然展开
  content.style.height = 'auto';
  const naturalHeight = content.getBoundingClientRect().height;

  const max = getMaxHeightByViewport();
  const nextHeight = Math.min(naturalHeight, max);

  content.style.height = nextHeight + 'px';
}

这段代码里有几个容易忽略的点。naturalHeight 读出来的是包含内部滚动内容的完整高度，如果里面是长列表且本身有 overflow，需要先临时把 overflow 改成 visible 再测量。其次，getBoundingClientRect 比 offsetHeight 更稳，因为 offsetHeight 在某些 WebView 里会受 transform 缩放影响。最后，如果内容里有图片且图片还没有加载完成，第一次测量会偏小。图片通常有固定宽高比，设置好 img 的宽高或 aspect-ratio 就能避免大部分测量误差。

3.2 ResizeObserver + requestAnimationFrame 做自适应频率控制

内容不是只在弹层打开时变化一次，后续可能还会因为窗口尺寸变化、字体调整、节点增删而二次变化。与其在每次变化点手工调用 measureSheet，不如用 ResizeObserver 监听内容区的尺寸变化。ResizeObserver 能在元素盒子尺寸改变时触发回调，但它触发的频率非常高。一个复杂弹层里可能同时有图片、折叠动画、v-if 切换，每个子节点的尺寸变化都会冒泡到父容器，如果每帧都做 setData 或 style 写入，开销不小，还可能出现抖动。

所以一般会给它加一重“自适应频率控制”。常用的做法不是用 setTimeout 做节流，而是把测量放在 requestAnimationFrame 里合并。也就是说，不管一帧内有多少次尺寸变化，只调度一次测量和更新：

js复制let rafId = 0;
let lastHeight = 0;
const THRESHOLD = 8;

const observer = new ResizeObserver(() => {
  if (rafId) return;
  rafId = requestAnimationFrame(() => {
    rafId = 0;
    const height = measureAndGetResult();
    if (Math.abs(height - lastHeight) > THRESHOLD) {
      applySheetHeight(height);
      lastHeight = height;
    }
  });
});

observer.observe(document.querySelector('.sheet-content'));

这里我加了 8px 的阈值。为什么不是任何 1px 变化都更新？因为高度变化 1~2px 肉眼基本分辨不出来，反而是频繁写入 style 会把 GPU 合成层反复打回重排，滚动时会掉帧。8px 是一个经验值，实测里既能保证跟手，又不会因为四舍五入导致动画抖动。如果项目对流畅度要求高，阈值可以放到 12~16px，但不要太大，否则弹层会明显“跳一下”。真正需要严格节流到 300ms 的场景不多，凡是发现弹层高度更新后位置乱跳，大概率是过渡动画和 ResizeObserver 打架，而不是节流不够。

3.3 键盘弹出时，maxHeight 应该跟随 visualViewport

移动端关键字是动态内容里最容易被忽略的一环。input 聚焦后，系统键盘弹起会让可视区域高度缩小，window.innerHeight 在很多浏览器里并不会及时更新，或者更新得不如 visualViewport 准确。如果半模态内部有输入框，弹层底部会被键盘顶起来或背景变黑，视觉上非常突兀。

现代移动端浏览器支持 visualViewport 接口。它代表用户当前真正能看到的那块区域。监听 visualViewport 的 resize 事件，弹层的高度上限改成基于 visualViewport.height 计算，比基于 window.innerHeight 更可靠。

js复制const vv = window.visualViewport;
if (vv) {
  vv.addEventListener('resize', () => {
    sheetEl.style.maxHeight = `${Math.max(160, vv.height - 24)}px`;
  });
}

键盘落下后 visualViewport 恢复，半模态高度也要跟着恢复。真正棘手的不是计算，而是时序：iOS 键盘收起时，visualViewport 的 resize 可能触发多次，最后一次不一定是稳定态。实测习惯是在 resize 回调里加一个 requestAnimationFrame 或 setTimeout，再测量一次内容高度。如果弹层里只有一两个输入框，更省心的做法是键盘弹起时把操作区固定在键盘上方，而不是疯狂调整弹层高度。键盘行为在不同 WebView 里差异较大，方案做得再精致也要在真机列表里过一遍。

3.4 入场动画和测量更新的冲突处理

动态测量做出来后，很容易遇到一个奇怪现象：弹层打开时高度从 auto 变成固定值，入场动画每次都会闪一次。原因是入场动画通常用 transform 或 height 做过渡，而测量结果又连续几次改写了高度，两次 style 写入之间浏览器还没完成排版，就会把过渡分成好几段。

处理办法是给“初始测量”和“后续更新”设置不同策略。弹层打开后第一帧不急着开过渡，先把高度设为 auto，测量完最终高度后，下一帧再写入最终高度并启用过渡。比较稳的写法是在弹层显示前先拿到高度：

js复制function openSheet() {
  sheetEl.style.transition = 'none';
  sheetEl.style.height = 'auto';
  const h = sheetEl.scrollHeight;
  sheetEl.style.height = '0px';
  // 强制浏览器排版一次
  requestAnimationFrame(() => {
    sheetEl.style.transition = 'transform .28s ease, height .28s ease';
    sheetEl.style.height = h + 'px';
  });
}

思路是让浏览器先渲染出测量高度，再开始过渡。所有连续测量都要注意不要让高度频繁在 auto 和定值之间横跳。实际项目里，弹层高度很少需要做成每 100ms 都变的动态传感器，绝大多数内容变化发生在用户操作后。所以在用户点击筛选条件、展开折叠区时再主动调一次测量，比全局 ResizeObserver 更可控。ResizeObserver 适合兜底，不适合做大范围实时驱动的核心逻辑。

4. 小程序和uni-app里的一套特殊公式：导航栏高度、scroll-view剩余空间与半模态限高

4.1 微信小程序顶部导航栏高度为什么必须动态算

小程序场景跟 Web 最大的区别是没有 DOM，也没有 ResizeObserver。你不能随便读取一个 View 的自然高度，必须通过 SelectorQuery 发起异步查询，再 setData。但在动手之前，很多高度计算其实可以靠系统 API 推断出来。

比如“微信小程序顶部导航栏高度”，网上能搜到一堆代码，直接写死 44px 或 48px 的多得是。问题在于，微信提供的胶囊按钮在不同机型上有不同尺寸和位置，胶囊跟状态栏的距离也会随系统变化。自定义导航栏时，如果顶部高度写死，在小屏机型上导航栏会跟胶囊重叠；如果你写的半模态要放在自定义导航栏页面里，顶部空间也会被算错。

动态获取导航栏高度有一套广为流传的公式：

js复制const windowInfo = wx.getWindowInfo();
const menuRect = wx.getMenuButtonBoundingClientRect();

// 胶囊上边缘到状态栏的距离 = 导航栏上下padding
const navPadding = menuRect.top - windowInfo.statusBarHeight;
// 导航栏总高度 = 状态栏高度 + 上下padding + 胶囊高度
const navHeight = windowInfo.statusBarHeight + navPadding * 2 + menuRect.height;

这套公式的原理是把状态栏和胶囊按钮的相对位置当成一种“参考系”。状态栏高度通过 wx.getWindowInfo 拿，胶囊矩形通过 wx.getMenuButtonBoundingClientRect 拿，不管什么机型，算出来的导航栏高度都是准的。如果你所在平台是 uni-app，同样的 API 在 uni.getWindowInfo 和 uni.getMenuButtonBoundingClientRect 里也能找到，用法基本一致。

4.2 主界面 scroll-view 剩余高度的计算公式

热搜词里有一句很具体：“uni-app 使用 scroll-view 主界面 怎么计算剩余的高度 赋值给 scroll-view”。这个场景通常出现在一个页面里有自定义导航栏、底部按钮、中间列表的结构。scroll-view 必须有明确高度才能滚动，但高度不能写死，要动态等于“windowHeight 减去导航栏高度再减去底部操作区高度”。公式可以抽象成：

js复制const { windowHeight, statusBarHeight, safeAreaInsets } = uni.getWindowInfo();
const menuRect = uni.getMenuButtonBoundingClientRect();
const navTopGap = menuRect.top - statusBarHeight;
const navHeight = statusBarHeight + navTopGap * 2 + menuRect.height;

const bodyScrollHeight = windowHeight
  - navHeight
  - bottomActionHeight
  - safeAreaInsets.bottom;

这个公式看起来简单，但有几个变量很容易漏。safeAreaInsets.bottom 不是在所有页面都存在，但底部有 Home Indicator 的 iPhone 一定存在。如果你把 scroll-view 的高度算到了最底边，最后一块内容会被手势条盖住，滚动到底也看不全，视觉上特别难受。

还有一点，uni-app 里如果开启的是自定义导航模式，windowHeight 拿到的是整个窗口高度，不是去掉导航栏后的高度，所以一定要手动减去。如果是官方默认导航栏，windowHeight 已经是去掉导航栏之后的可视高度，再减一次就重复了。写自定义导航栏时最容易出现这个 44px 误差，排查时先确认页面是不是 custom 模式。

4.3 半模态在页面里如何拿“剩余高度”

想做小程序里的半模态底部弹层，可以把刚才的剩余高度计算思路套进去。弹层从页面底部出现，它的高度上限不是整个 windowHeight，而是“windowHeight 减掉顶部遮罩保留区，再减掉底部安全区”。比如产品希望弹层弹出后，顶部还能露出一部分背景页面，露出区域的高度是 80px，那最大高度就是：

js复制const sheetMaxHeight = windowHeight - 80 - safeAreaInsets.bottom;

这个值在弹出前就可以算好。但跟 Web 不同的是，小程序里没法让一个 View 在内容少时自动撑开、内容多时自动限高并让中间区域滚动。scroll-view 如果没有明确高度，内容再多它也不会滚，而是把外层撑高。所以这里需要切换逻辑：先量出内容自然高度，再决定是否给 scroll-view 一个固定高度。

典型的实现步骤是四条：

1. 弹层弹出后，通过 wx.createSelectorQuery 选中内容区并读取高度。
2. 把内容区高度与 sheetMaxHeight 做比较。
3. 如果内容区高度小于上限，scroll-view 不设高度，弹层整体随内容长高。
4. 如果内容区高度大于上限，外层高度设为上限，中间 scroll-view 的高度设为“上限减 header 和 footer 高度”。

这个判断不是一次性的。内容里如果有网络图片，第一次读取高度可能偏小。为了减少误差，图片元素尽量给定宽高比例，或者用 image 的 binderror/bindload 在图片加载后再查一次高度。一个半模态的滚动区域频繁变化时，接受一次从“auto 高度”到“固定高度”的跳变，比反复 setData 覆盖高度要稳定。

4.4 无 DOM 环境下“高度测量”的兜底写法

小程序的 SelectorQuery 查询是异步的，一次性拿多个节点高度要避免层层回调嵌套。可以借助 boundingClientRect 支持传入 SelectorQuery 实例的特性，把多个查询放到同一批里执行，再统一在回调里处理。实际项目里，header、footer、内层内容这几个节点的高度经常需要同时读取：

js复制const query = this.createSelectorQuery();
query.select('.sheet-header').boundingClientRect();
query.select('.sheet-body').boundingClientRect();
query.select('.sheet-footer').boundingClientRect();
query.exec((res) => {
  const headerHeight = res[0] ? res[0].height : 0;
  const footerHeight = res[2] ? res[2].height : 0;
  const bodyHeight = Math.max(0, this.data.sheetMaxHeight - headerHeight - footerHeight);
  this.setData({ bodyHeight });
});

这里有一个细节：如果 body 内容不超过上限，bodyHeight 应该保持为 0，让 scroll-view 自然由内容撑开。如果直接给 scroll-view 设一个很大的固定高度，即使内容很短，滚动区也会占掉不该占的空间。这个“先判断再赋值”的步骤，是半模态自适应区别于普通全屏列表的地方。

search scroll-view 主界面计算剩余高度时，还有一个更好的选择：给滚动区域外面包一层 flex 容器，页面整体用 flex 纵向布局。header 和 footer 都是固定高度，中间的 scroll-view 直接用 flex: 1 分配，看起来像不需要手算高度。实际开发里不靠谱的地方仍在于：scroll-view 的 flex: 1 只会占满容器剩余空间，不会按照内容量自动收缩或扩展示区域。在一个固定高度的页面容器里，flex: 1 的 scroll-view 确实能自动获得剩余高度，这是推荐的写法；但半模态弹层的高度本身不固定，它是浮在页面上方的，所以“内容自适应”还得靠每层节点高度测量来圆回来。

5. 宽度自适应的两个衍生问题：flex一行四个与表格自适应

5.1 表格自适应宽度：table-layout: fixed 是第一选择

半模态里偶尔要放表格或类表格数据。热搜词“表格自适应宽度”同样是很高频的问题。很多人给表格加了一堆 word-break、white-space 之后还是乱，是因为没有意识到表格的宽度算法分两种。

表格默认使用 auto 布局，浏览器会扫描整列内容，尽可能满足所有单元格不换行，于是某列内容一长，整张表就被顶出容器。改成 fixed 之后，表格宽度由 width 和列宽决定，内容再长也会被约束在列内，配合 overflow 和 text-overflow 才能真正做成自适应：

css复制.table {
  width: 100%;
  table-layout: fixed;
  border-collapse: collapse;
}

.table__col-name {
  width: 60%;
  overflow: hidden;
  white-space: nowrap;
  text-overflow: ellipsis;
}

width 和 table-layout: fixed 一起用，意味着第一行的单元格宽度会成为整列宽度基准。所以写表头时就要把各列宽度规划好。如果内容是动态 JSON，渲染后列数可能变动，fixed 布局不能替代“设计列数”这一步。实践里我用过的组合是：表格外层包一个 min-width: 0 的容器，表格自身 width: 100%，列内文本超过两行时用 -webkit-line-clamp 截断，效果比横向滚动表格更符合移动端习惯。

5.2 flex 一行四个宽度自适应的写法参考

前面已经说过 calc 方案，这里补充一个更贴近真实项目的例子。半模态里的商品标签区域，需求经常是：最多一行四个，标签宽度跟随屏幕均分，标签文字过长时省略号处理。如果容器宽度是弹层内容宽度，那每个格子的宽度就不能用 25% 完事，因为还有间距。用 CSS 变量可以让计算更直观：

css复制.tag-grid {
  --gap: 12px;
  display: flex;
  flex-wrap: wrap;
  gap: var(--gap);
}

.tag-grid__item {
  width: calc((100% - var(--gap) * 3) / 4);
  flex-shrink: 0;
  overflow: hidden;
  white-space: nowrap;
  text-overflow: ellipsis;
}

这里 gap 和负 margin 的方案都可以，但负 margin 会让最后一个元素的右边距看起来和其他行不同。flex 的 gap 在微信小程序和现代浏览器里都已支持，省心得多。需要注意：item 数量不满 4 个时，flex 不会把后面的空白空间挤给已有 item，因为 item 宽度已经由 calc 写死，不会 grow。这是“四个固定宽度”和“平均分配剩余空间”的区别。如果你想前两个标签各占一半，后两个自动换行，那要用不同的 flexible 策略，不要在一个组件里混用两种需求。

5.3 同源思路：自适应都是“总量减去固定/弹性分配”

把表格宽度、flex 网格和半模态高度放一起看，会发现一个共同规律：所谓自适应，不是让浏览器猜，而是明确“总量、固定部分、弹性部分”三者的关系。半模态高度自适应的总量是视口可用高度，固定部分是顶部遮罩保留区和底部安全区，弹性部分是中间内容区；表格宽度的总量是容器宽度，固定部分是某一列的最小宽度，弹性部分是其他列；flex 一行四个的总量是父容器宽度，固定部分是间隙，弹性部分才是四个 item 的共享宽度。

换句话说，先写总量再减固定项，最后把剩余空间按规则分配给弹性项，任何布局问题都不难拆。很多看起来玄妙的 CSS 技巧，本质都是在表达这个减法。碰到“自适应”需求时，先不要急着找某个属性，先在纸上把这三类写出来，答案往往就自己浮出来了。这个方法在处理半模态这种既要垂直自适应又要保持内部滚动条的自然承接。

6. 落地后的几个保留观点

方案聊到这里，基本把实现路径走了一遍。最后讲几个我踩过坑之后形成的个人习惯。

第一个习惯是：不是所有半模态都应该做高度自适应。如果你的弹层只有固定两三个选项，高度稳定，做自适应纯粹是增加复杂度。内容是否可变、是否可能出现超长列表、是否要放输入框，这三个问题里只要有两个答案是否，直接用固定高度或 max-height 即可，不要为了“高级”而动态测量。半模态高度自适应的核心价值在内容长度不可控的场景，不是所有弹层的标配。

第二个习惯是：上限要比想象中低一点。给弹层留出顶部呼吸区，用户才能点遮罩关闭；如果把高度顶到接近屏幕顶部，遮罩点击区域变得很小，关闭成本也变高。我习惯在 max-height 里保留 48~80px 的顶部空间，小程序里再额外减去安全区。页面里如果同时有状态栏，还要算上状态栏高度。不要拿 windowHeight 的 100% 去冒险。

第三个习惯是：能不做实时测量就不要做。Web 端有 ResizeObserver，也有 requestAnimationFrame，理论上可以把高度做成非常实时的自适应，但实时测量带来的代码复杂度和真机 bug 往往比收益更大。很多场景其实只需要在三个节点测量一次：弹层打开后、内容异步加载完成时、用户主动展开收起时。其他时间保持高度稳定，反而更符合用户对弹层的直觉。自适应频率控制不是为了炫技，是为了让这种“稳定中的变化”更跟手、更省资源。

半模态高度能不能自适应？答案是可以。但它在工程上更像一个“状态机”，而不是一条 CSS 规则。内容少、内容多、键盘弹起、安全区变化、图片加载成功，每个状态都要有一条明确的输出，弹层才能在不同手机上保持一致的手感。沿着这个思路去写，组件会越来越稳，你自己对弹层这件事的理解也会透彻很多。