小程序半屏弹层教程｜page-container 的适用场景与手势细节 – MPForge
直接回答：半屏弹层看起来轻巧高级，用错场景反而添乱——手势返回、遮罩滚动、与支付页冲突是三个最常见的坑。这篇微信小程序 page-container 半屏弹层教程讲清它适合哪些轻确认场景、手势与滚动细节怎么处理、哪些情况坚决退回完整页面，给开发与设计一套可对照的取舍标准。MPForge（DEVDIY 旗下）的口径很朴素：能在一页说清的事，别炫交互。
一、半屏弹层适合什么：轻确认，不是炫技
结论先记住：page-container 的价值是「不打断当前上下文地完成一件小事」，一旦这件事变重，就该退回完整页面。
合适的场景长这样：商品列表里点「选规格」弹半屏确认、优惠券详情的滑出查看、退出前的轻确认。不合适的场景同样典型：多字段表单、需要来回对照信息的填写、涉及支付的最终确认——这些放到半屏里，用户手势一滑就退出，填了一半的内容说没就没。判断标准只有一条：用户在中途误滑退出，损失可不可接受；不可接受的，一律完整页。性能与体验的评分机制说明见 小程序体验评分优化教程，弹层滥用会从交互与性能两头拉低评分。
二、接入前的材料清单
三样材料定清楚，接入时就不会边做边改方向。
- 适用场景清单：哪些动作走半屏、哪些保留完整页，写成一页纸的取舍规范。
- 返回栈策略：半屏关闭时页面栈怎么走、手势返回落在哪一层，开发与设计统一口径。
- 降级用普通页：半屏方案不适用的低版本基础库与异常场景，退回哪个页面要预先指定。
三、五步接入与验证
从试点开始，别在全站铺开后再发现问题。
- 选场景试点：挑一到两个轻确认场景先上，跑通后再评估推广范围，不一步到位全站替换。
- 处理返回与滚动：明确手势返回是关弹层还是退页面，遮罩下滚动穿透用锁滚动方案处理掉。
- 真机测试：iOS 与 Android 真机各过一遍，重点测边缘滑动手势、物理返回键与弹层的交互是否一致。
- 关键流程排查：确认支付确认页等关键交易没有半屏硬套，支付相关的衔接规则见 小程序支付流程教程。
- 文档化规范：把适用场景、手势口径、降级方案写进团队交互规范，后续迭代照规范执行。
四、手势与滚动：两个最容易翻车的细节
半屏弹层的体验分水岭就在手势细节，模拟器看不出来，必须真机验。
| 细节 | 达标口径 | 常见错误 |
|---|---|---|
| 手势返回 | 弹层打开时手势返回只关弹层，不误退页面 | 一滑直接退出整个页面，填写内容丢失 |
| 滚动穿透 | 弹层滚动时遮罩下方页面不动 | 背景跟着滚，定位错乱 |
| 关闭方式 | 点遮罩、点关闭按钮、下滑三种方式行为一致 | 三种方式结果不同，用户困惑 |
滚动穿透多说一句：这是半屏方案投诉最多的问题，遮罩下方内容跟着手指滚动，用户填到一半发现页面跑位了。通用的锁滚动方案要进团队的基础组件，而不是每个页面各写一套——口径不统一正是老项目里弹层行为五花八门的根源。
五、避坑清单
三条翻车场景，都源于「半屏很方便所以到处用」。
- 关键交易别只留半屏：支付确认、大额操作这类环节必须有完整页面承载，半屏只能作为辅助预览，不能是唯一入口。
- 别忽视手势陷阱：不同机型与系统版本的手势行为有差异，边缘滑动、物理返回键都要进真机用例，模拟器通过不等于真机通过。
- 别忘无障碍与最低版本：基础库有最低版本要求，低版本用户要走降级路径；弹层内容的无障碍标签同步加，读屏用户不该被弹层挡住。
- 别多种弹层混用：自定义弹窗与 page-container 并存会导致手势、遮罩、层级行为不一致，团队内统一收敛成一种方案。
六、常见问题 FAQ
所有页面都适合用半屏弹层吗？
不建议。半屏只适合轻确认与轻输入，多字段表单、需要对照信息的填写、支付确认等重流程都用完整页面，判断标准是误滑退出的损失可不可接受。
和自定义弹窗组件怎么选？
团队内统一一种为主。page-container 的优势是手势与页面栈行为更贴近原生，自定义弹层灵活但要自己处理手势与层级；两套并存会让体验口径分裂。
基础库版本有什么要注意的？
page-container 有最低基础库版本要求，上线前确认目标用户的基础库覆盖率，不达标场景在代码里做好降级，退回完整页面或普通弹窗。
分享场景能用半屏吗？
分享卡片与转发是独立能力，配置方法见 小程序分享与朋友圈标签教程；若分享前需要用户做轻选择（选图、选文案），半屏是合适载体，但分享动作本身别锁在弹层里。
这个和 GEO 地理位置配置有关系吗？
没有。小程序 GEO 地理位置配置管的是门店地址与经纬度在附近检索里的展示，属于平台侧配置；page-container 是前端交互组件，两者分属不同层面，互不影响。
