在微信小程序里实现一个底部弹窗不难，难得是让弹窗高度自动匹配内容。固定高度方案写起来简单，但内容一旦变化，要么溢出被截断，要么出现大段空白，视觉上非常生硬。更麻烦的是，弹窗内容往往由接口数据或异步图片组成，高度在渲染前是未知的。只有拿到内容真实高度，再动态设置弹窗外层容器的height样式，才能做到理想中的自适应效果。
自适应听起来像是CSS的职责，比如让容器height:auto。但在小程序的自定义modal组件里，外层fixed定位的遮罩层、动画过渡的位移效果，以及内部滚动区域的嵌套，常常让height:auto失效。尤其是当我们需要给弹窗容器设置一个最大高度，让内容超过阈值时内部滚动，就必须明确知道内容尺寸，才能决定是撑开还是收缩。下面从固定高度的痛点开始，逐步拆解自适应方案。
固定高度方案为什么无法胜任
常见的底部弹窗写法，是给弹窗容器设置一个固定高度，例如height: 600rpx，内部再放一个scroll-view滚动。这样确实能保证弹窗可见，但问题在于这个高度是拍脑袋决定的。不同机型屏幕高度不同，600rpx在iPhone SE上可能占据大半个屏幕，在iPhone 14 Pro Max上又显得很短；内容只有几行文字时，空白区域特别扎眼；内容超过固定高度时，用户必须滚动才能看完，但又看不到“更多内容”的暗示。
另一种思路是让弹窗高度由内容自然撑开，即不设置高度，依赖子元素的高度总和。这个方案在纯静态内容下可行，但一旦内容里包含异步加载的图片、云端数据，或者用户交互后内容变化，弹窗容器的高度并不会自动重新计算，因为小程序的布局计算发生在节点创建时，数据更新后没有显式触发重排时，测量结果往往是旧的。
本质上，height:auto在小程序里不是不能用，而是无法配合动画和最大高度限制。我们需要的最终效果是：内容短时，弹窗矮一点，紧包内容；内容长时，弹窗最多到屏幕的80%，内部滚动。这个“80%”和“紧包内容”之间需要一个动态的临界判断，而这个判断依赖对内容高度的精确测量。
使用SelectorQuery获取内容真实高度
小程序提供了wx.createSelectorQuery接口，可以查询节点布局信息，配合boundingClientRect能拿到节点的宽高和位置。在自定义组件中，需要调用this.createSelectorQuery()来获取与组件实例绑定的查询器。查询到的内容节点高度，就是弹窗在自然撑开状态下应该显示的高度。
具体的做法是：在弹窗内容外部包裹一层透明的容器，这个容器不要设置任何高度限制，让内容自由排列。然后在弹窗显示后，查询这个包裹节点的高度，将它记录到data中，再赋给外层弹窗容器的height样式。这样外层容器的高度就等于内容的高度，视觉上内容被完全展示，没有固定高度造成的截断问题。
下面是一个简单组件的代码骨架。WXML中两层结构：外层是定位容器，内层是测量节点。测量节点不设置高度，保证内部的view、text等元素自然堆叠。
<view class="modal-overlay" wx:if="{{visible}}">
<view class="modal-wrapper" style="height: {{modalHeight ? modalHeight + 'px' : 'auto'}};">
<view class="modal-body" id="modalBody">
<slot></slot>
</view>
</view>
</view>
在组件的js中，当弹窗显示且内容渲染完成后，调用测量方法。注意这里需要等待数据渲染完成，通常使用wx.nextTick来确保节点已经插入。
methods: {
show() {
this.setData({ visible: true }, () => {
wx.nextTick(() => this.measureBodyHeight());
});
},
measureBodyHeight() {
const query = this.createSelectorQuery();
query.select('#modalBody').boundingClientRect(rect => {
if (rect) {
this.setData({ modalHeight: rect.height });
}
}).exec();
}
}
这里把测量到的height赋值给modalHeight，外层容器使用px单位。为什么不用rpx？因为boundingClientRect返回的是px，如果直接用在style里就需要px；当然也可以把px转换成rpx，但通常使用px更直接，小程序style支持px。
内容变化时的重新测量与平滑过渡
动态内容并不仅仅在初始渲染时出现，用户操作可能改变内容高度。例如点击“展开更多”、加载完网络图片、从服务端获取数据后重新渲染。如果只测一次，后续内容变化不会触发高度更新。所以需要把测量逻辑抽象成一个公共方法，在数据变化后调用。
对于图片高度，最典型的问题是通过样式设置了width: 100%的图片，图片加载完成后高度才会稳定。如果只监听页面数据更新，图片可能还没加载完。这时需要给图片绑定binderror和bindload事件，在图片加载完成后再重新测量一次。为了避免频繁测量，可以用一个标志位来控制重测的时机。
高度变化时直接改变height样式会显得突兀，可以给modal-wrapper加上CSS过渡，让高度在200ms内平滑变化。注意过渡可能会与其他动画冲突，建议弹窗出现时使用位移动画，高度变化时使用过渡。为了不影响内容渲染性能，测量结束后最好使用setData一次性更新。
.modal-wrapper {
transition: height 0.2s ease-out, transform 0.3s ease-out;
overflow: hidden;
border-radius: 24rpx 24rpx 0 0;
}
如果内容较短，高度的变化可能因为动画产生视觉跳跃，可以限制高度差值超过某个阈值时才开启过渡。比如前后高度差小于5px时，不做动画，直接更新。
限制最大高度并处理滚动与安全区
自适应弹窗不能无限增高，否则内容很长时会占据整个屏幕。通常给弹窗设置一个最大高度，比如屏幕高度的80%。实现方式是查询系统窗口高度，再乘以0.8得到一个临界值。测量内容高度后，如果内容高度大于该临界值，则外层容器的高度设为临界值，同时测量节点内部需要转换为可滚动容器；如果内容高度小于临界值，则外层高度等于内容高度，不需要滚动。
measureBodyHeight() {
const query = this.createSelectorQuery();
query.select('#modalBody').boundingClientRect(rect => {
if (!rect) return;
const windowInfo = wx.getWindowInfo();
const maxHeight = windowInfo.windowHeight * 0.8;
const contentHeight = rect.height;
const finalHeight = Math.min(contentHeight, maxHeight);
this.setData({
modalHeight: finalHeight,
needScroll: contentHeight > maxHeight
});
}).exec();
}
在WXML中，根据needScroll决定测量节点内部是否使用scroll-view包裹。这里有一个细节：如果直接用scroll-view包裹内容，测量节点的高度就不再是内容真实高度，因为scroll-view自身有固定的滚动区域。所以测量节点和滚动容器不能是同一个节点。可以在内容外层再加一层，只有需要滚动时才启用scroll-view，否则直接用view。
另外，通过position: fixed实现弹窗时，内部滚动会引起页面背景的滚动穿透。解决思路是在弹窗显示时给page设置overflow: hidden，或者使用catchtouchmove阻止触摸事件冒泡。为了兼容性和性能，推荐使用catchtouchmove，同时在滚动容器内保持正常的滚动行为。
底部弹窗还要考虑iPhone的安全区。当弹窗贴底时，底部需要在padding-bottom中加上env(safe-area-inset-bottom)，避免内容被Home Indicator遮挡。可以在弹窗内部底部增加一个安全区占位节点。
.safe-area {
height: env(safe-area-inset-bottom);
}
最后，如果弹窗内容中包含textarea或map等原生组件，需要注意原生组件的层级问题。固定高度方案下可以给原生组件设置同层级，但自适应测量时原生组件的高度通常不参与普通节点的布局计算，可能需要额外查询。这时可以考虑使用cover-view，或者换成非原生组件。不过多数场景下，底部弹窗里的内容以文本和按钮为主，测量方案是足够可靠的。
总结来看，微信小程序自定义modal底部弹窗的自适应高度并不需要复杂的布局技巧，关键是准确测量内容节点的高度，并在恰当的实际更新容器高度。然后配合最大高度限制、滚动切换、安全区适配和过渡动画，就能得到一个体验良好的弹窗组件。这个方案同样适用于顶部弹窗或居中弹窗，只需要调整外层定位方式和边界判断逻辑。