小程序 iOS scroll-view 底部为什么会多一截空白

最近在做一个小程序 Agent 项目，页面主体是一条不断增长的对话流。

这类页面看起来和普通聊天列表差不多，但真正做下来，会发现很多体验问题其实都集中在滚动、键盘、流式生成和动态内容高度这些运行时细节上。

尤其是小程序。

同一套布局，在 Android、iOS、H5 上经常不是同一种表现。

最近就碰到一个很典型的问题：

同一个 scroll-view，Android 一切正常，iOS 真机滚到最底却总会多出一截空白。

而且这段空白还不是固定高度。

最后一条是什么类型，它就跟着变。

这次的问题不是 scroll-view 自己多了 padding，而是最后一块内容的 margin-bottom 一路向上塌陷，最后被 iOS 算进了可滚动高度。修复重点也不是消灭 margin，而是只处理「整个列表视觉上的最后一块」。

一开始的问题：为什么滚到底还会多一截？

对话列表是一个纵向 scroll-view，输入栏独立在外面，贴在屏幕底部。

Android 一直正常。

但 iOS 真机上，滚到最底时，最后一条消息和输入栏之间总会多出一截空白。

而且这段空白不是固定的：

末尾是普通回答 / 工具栏
→ 大约多一行间距

末尾是欢迎卡片
→ 大约多一张卡片的下边距

这其实已经给了一个很重要的线索：

空白跟着最后一块内容变化，而不是跟着输入栏、安全区或者 scroll-view 本身变化。

所以一开始就可以先把「底部 padding 写错了」这个方向往后放。

先把几个最像的东西排掉

最开始排查了几个很容易怀疑的地方。

底部渐隐遮罩

直接注释掉。

空白还在。

不是它。

滚动到底用的 anchor

列表末尾确实有一个定位节点，也存在一点间距，但不是主要来源。

调试的时候还把它改成过一条黑色块。

后来发现这种调试样式反而很容易干扰肉眼判断。

Safe Area / 输入栏

也不是。

空白的位置实际上是：

最后一条消息
↓
额外空白
↓
输入栏

而不是：

输入栏
↓
Home Indicator

所以问题还是在滚动内容里面。

高度到底多在哪一层？

真正开始接近问题，是把消息结构逐层量出来之后。

结构大概是：

scroll-view
  ↓
content
  ↓
agent-entry
  ↓
wrapper
  ↓
turn-group
  ↓
message-renderer
  ↓
真正的正文 / 卡片 / 工具栏

然后分别量每一层的：

top
height
margin-bottom
padding-bottom

最后出现了一个很奇怪的数据：

wrapper → entry = 18px

但：

entry.padding-bottom = 0
entry.margin-bottom  = 0
wrapper.margin-bottom = 0

也就是说：

.agent-entry 自己没有写这 18px，但它就是比里面的 wrapper 高了 18px。

继续往里面查，这 18px 又刚好等于末条消息内部内容自己的 margin-bottom。

到这里基本就确定了：

是 margin collapse。

最后一条的 margin 一层层穿了出来

CSS 的垂直外边距有一个很经典的行为。

如果父级没有：

padding
border
独立格式化上下文

子元素的上下 margin 就可能和父级发生塌陷。

而消息结构里刚好有很多纯包裹层：

真正内容
  margin-bottom: 32rpx
      ↓
message-renderer
      ↓
turn-group
      ↓
wrapper
      ↓
agent-entry

这些层本身都没有东西把 margin 截住。

于是实际发生的是：

末条内容的 margin-bottom
↓
穿过 renderer
↓
穿过 turn-group
↓
穿过 wrapper
↓
最后停在 agent-entry

为什么停在这里？

因为 .agent-entry 已经处于 flex 布局关系里，塌陷到这里被截住。

于是原本看起来只是：

.message {
  margin-bottom: 32rpx;
}

最终反映到高度上却变成：

agent-entry 实际高度
=
真实内容高度
+
32rpx

iOS scroll-view 又把这一截算进去了

如果只是 CSS margin collapse，本身还不一定会变成明显的视觉问题。

真正让它暴露出来的是 scroll-view。

从真机表现来看：

iOS scroll-view
→ 会把末尾塌陷出来的 margin 算进内容高度

Android scroll-view
→ 同样结构下基本没有明显表现

于是最终：

真实内容高度
+
末条塌出来的 margin
=
iOS scroll-view 的可滚高度

滚到底以后，就看到了那一截额外空白。

这里有两个比较直接的实锤。

最后一条换类型，空白跟着变

普通回答或者工具栏：

≈ 32rpx

欢迎卡片：

≈ 48rpx

和各自组件的 margin-bottom 能直接对上。

滚动容器本身没有对应 padding

scroll-view、列表容器、输入栏都没有一份相同数值的底部空间。

所以不是外层硬垫出来的。

第一反应：把最后一条的 margin 清掉

方向其实很明确。

既然 iOS 多算的是：

视觉最后一块
→ margin-bottom

那只要：

视觉最后一块
→ margin-bottom: 0

这段额外可滚距离就不存在了。

问题变成了另一件事：

谁才是真正的「最后一块」？

这件事比想象中麻烦。

第一版：直接选最后一个元素

最开始想的是：

:last-child {
  margin-bottom: 0;
}

但实际消息结构并没有这么简单。

消息可能长这样：

wrapper
  └── component
        └── markdown-renderer
              └── paragraph
                    margin-bottom

真正带 margin 的节点可能隔了很多层。

比如普通正文外面还有 Markdown 组件。

深度思考也可能是：

外层空壳
  ↓
真正内容块
    margin-bottom

所以只清 wrapper 的直接子节点根本没有用。

真正产生 margin 的节点还藏在更深的组件里。

第二版：给最后一条打标记，再往里面清

于是换了一个方向：

最后一条 wrapper
→ 打 is-last 标记

然后在它内部，不管中间隔了多少层，只要某个块本身又是父级的最后一个子节点，就清掉 margin-bottom。

概念上类似：

.turn-group .is-last xxx:last-child {
  margin-bottom: 0;
}

这里外面还需要加一层回合容器作为前缀。

因为一些组件本身用了 scoped style。

编译之后会带上额外的属性选择器，优先级比页面层单纯的：

.xxx:last-child

更高。

不把选择器权重提上来，即使选中了节点，样式也压不掉。

做到这里之后，大部分普通回答场景已经正常了。

但欢迎卡片还是有空白。

第二个坑：空壳抢走了「最后一条」

欢迎卡片这一轮，最终节点实际上类似：

wrapper
  └── 欢迎卡片
      margin-bottom: 48rpx

wrapper  ← is-last
  └── 空

也就是说：

数组里的最后一条消息，不一定是视觉上的最后一块内容。

真正有内容的是前面的欢迎卡片。

最后一条只是一个高度为 0 的空壳。

空壳是哪来的？

问题出在数据层和组件渲染条件是分开的。

数据层只负责：

收到消息
→ push 进 messages

列表层看到数组里有这一项，就会正常创建一层 wrapper。

但是工具栏组件内部又有自己的显示条件。

例如：

showToolbar === false
→ 组件内部不渲染任何节点

于是最终变成：

有 message
有 wrapper
组件内部什么都没有

这个空壳：

height = 0

对于视觉布局来说几乎不存在。

但是对于：

messages.length - 1

它又确实是最后一条。

于是 is-last 标记打给了它。

真正的欢迎卡片仍然保留着自己的 margin-bottom。

iOS scroll-view 还是会把它算进去。

一度想维护一个「可见消息列表」

当时有过一个方案：

把所有可能不渲染节点的消息类型整理成一张表。

然后：

messages
↓
过滤掉不会显示的消息
↓
visibleMessages
↓
找最后一条

但很快放弃了。

因为这实际上是在页面层重新复制组件内部逻辑。

例如组件里以后改成：

A && B && C

页面这里也必须同步修改。

否则就会出现：

组件实际上有内容
页面却判断它没有内容

这种问题比现在的底部空白更危险。

而且当前已经通过真机定位到的空壳只有工具栏这一种。

没必要为了一个已知问题，提前维护一套「所有组件是否会渲染」的镜像规则。

所以最后这层抽象删掉了。

最后的做法：消息不删，只决定标记打给谁

最终逻辑很简单。

只有：

当前轮 = 整个列表最后一轮

才需要考虑末条标记。

然后从这一轮的最后往前找：

最后一条消息
↓
如果是已知空壳
→ 跳过

继续往前
↓
第一个真正会渲染内容的消息
→ 标记 is-last

目前只判断一种已经确认的空壳：

工具栏消息
+
后端明确告诉前端不展示工具栏

其他类型不提前猜。

以后真碰到新的空壳，再增加对应判断。

还不能把每一轮最后一条都清掉

这里还踩过另一个坑。

最开始做的是：

每一轮
→ 最后一条 margin-bottom: 0

底部空白确实消失了。

但点完欢迎卡片以后再问一句，就发现：

上一轮卡片
下一轮问题

直接贴在一起。

因为原本轮与轮之间的间距，本来就依赖：

上一轮最后一条的 margin-bottom

也就是说，这份 margin 在中间位置其实是有意义的。

真正有问题的只有：

整个列表滚到最底时，最后一块还留下了一份向下的 margin。

所以不能清：

每轮最后一条

而只能清：

整个对话列表视觉上的最后一条

还要看后面有没有别的内容

甚至最后一轮也不一定需要清。

比如后面还有：

结束分割线
冷启动提示
其他尾部内容

这时候消息的 margin-bottom 仍然承担正常的元素间距。

所以最终末条标记必须同时满足：

1. 当前是整个列表的最后一轮

2. 后面没有结束分割线 / 提示语

3. 从当前轮尾部往前找

4. 跳过已知空壳

5. 第一个真正有内容的 wrapper
   → 标记为视觉末条

CSS 再负责另一半：

视觉末条 wrapper
↓
往内部找到各层 :last-child
↓
真正带 margin-bottom 的末端节点
↓
margin-bottom: 0

这样只会移除滚动内容最底部那一份 margin。

中间所有消息间距都继续保持原样。

为什么没直接用 BFC 截住？

从 CSS 角度，还有一个更直接的思路：

给回合容器建立独立格式化上下文。

例如：

display: flow-root;

这样子元素的 margin 就不会继续往祖先塌。

理论上是能解决的。

但这会直接改变：

整轮消息的高度模型

而现在很多轮间距本身就在依赖这套 margin 行为。

如果统一截断，需要把所有消息类型重新走查一遍。

风险比只处理末条大很多。

类似的还有：

padding-bottom: 1px;

也可以阻止 margin collapse。

但本质上是在真实布局里人为加入一个尺寸，只为了触发 CSS 行为。

更像 hack。

这次也没有采用。

为什么不用纯 CSS 找「最后一个非空节点」？

真正麻烦的节点关系其实是：

A  ← 有内容
B  ← 空壳，但是 :last-child

我们真正想表达的是：

如果 B 没有内容
→ 选 A

传统 CSS 没有向前选择兄弟节点的能力。

:has() 可以绕一部分场景，但微信小程序还要考虑 Android 内核兼容性，不太适合把修复押在这里。

而即使：

B {
  display: none;
}

A 在 DOM 结构上依然不是 :last-child。

所以最终把职责拆开：

JS
→ 判断谁是视觉上的最后一条

CSS
→ 清掉它内部真正末端内容的 margin

反而更稳定。

这次真正修的并不是 scroll-view

表面现象是：

iOS scroll-view 底部多了一截

但小程序并没有提供类似：

不要把 collapsed margin 算进 scrollHeight

这样的能力。

所以平台层没什么可以控制的。

真正能调整的是内容布局。

最终做的事情其实是：

不要让整个页面视觉上的最后一块内容，继续使用向下的外边距表达间距。

中间消息继续用原来的 margin。

只有到了滚动内容的真正末尾，才把最后一份 margin 收掉。

更彻底的根治方式

这次没有继续往下做。

但从布局模型上看，更彻底的方式其实是不要再依赖：

上一块内容的 margin-bottom

表达所有纵向间距。

可以逐步改成：

下一块的 margin-top

或者统一由：

gap
padding

管理。

这样最后一个元素天然不会继续向滚动容器外留下 margin-bottom。

也就不会再触发这类问题。

不过这已经属于整个对话系统的垂直间距重构。

没必要和一次 iOS bug 修复绑在一起。

最后怎么验

这个问题必须用 iOS 真机。

模拟器和 Android 都不能证明问题已经解决。

至少覆盖下面几种情况：

普通问答
→ 生成中滚到底
→ 生成完成滚到底
→ 不再出现额外空白

欢迎卡片
→ 报告 / 皮肤 / 找医院
→ 卡片底部没有额外空隙

欢迎卡片之后继续问问题
→ 两轮之间仍然保留正常间距

最后一轮有结束分割线
→ 分割线上方间距正常

最后检查
→ 调试背景色
→ 黑色 anchor
→ opacity
→ 全部还原

这次一路查下来，最后其实可以把整个问题压缩成一句话：

不是 iOS 凭空多出了一段高度，而是末条 margin-bottom 穿过多层包裹后，被 scroll-view 当成了真实可滚内容。