微信小程序｜Loading 与 Toast 教程｜时长上限、成对关闭与防叠层 – MPForge
直接回答：这篇小程序 Loading 与 Toast 教程管三件事：Loading 最长显示时长、show 与 hide 必须成对出现、Toast 不做遮罩不当弹窗用。给开发看关闭责任人与超时兜底怎么写，给产品看反馈分级的口径——什么用 Loading、什么用 Toast、什么干脆静默。MPForge（DEVDIY 旗下）把「永不关闭的转圈」列为发版前必清零项，这套规则在支付与核销链路上反复验证过。
一、永不关闭的转圈是最贵的反馈
结论先亮出来：Loading 不关闭，等于告诉用户「系统坏了」——比报错更伤转化，因为它不给任何出路。
最典型的事故链：请求开始 showLoading，请求失败的分支忘了 hideLoading，用户卡在转圈界面只能杀进程；下次再进这个页面，转化率数据已经跌了一截。三类高频问题：
- Loading 永不关：异常分支漏掉 hide，或全局与页面各自 show 互相覆盖。
- 成功失败都狂 Toast：每步操作都弹提示，Toast 从「信号」退化成「噪音」。
- 遮挡关键按钮：带透明遮罩的反馈层压住提交按钮，用户点不动也不敢动。
分工口径：开发按「谁 show 谁 hide」写代码与单测，产品定反馈分级表——哪些操作值得打扰用户，不在表里的反馈一律静默。
二、反馈分级：Loading、Toast 还是静默
先分级再用组件，别拿 Toast 当万能贴。
| 反馈类型 | 适用场景与口径 | 常见错误 |
|---|---|---|
| Loading | 超过 300 毫秒的等待，需阻断重复操作 | 短请求也全屏转圈 |
| Toast | 1.5 秒级的结果告知，不打断流程 | 长文案塞进 Toast |
| 页内提示 | 需要用户阅读并行动的错误说明 | 错误详情只在 Toast 闪一下 |
| 静默 | 自动保存、预加载等用户无感的动作 | 每次后台同步都弹提示 |
Loading 期间请求失败怎么办、重试怎么设计，见 小程序请求重试与超时处理；反馈链路的耗时问题往往连着性能债，见 小程序性能优化实操。
三、落地步骤：把关闭机制写进代码
反馈组件不需要多，需要「一定关闭」。按这五步执行：
- 请求开始再 show：预估超过 300 毫秒的请求才显示 Loading，短操作用按钮自带 loading 态。
- 结束必达：成功、失败、超时、用户离开四个分支都要 hide，用统一的请求封装兜住。
- 超时强制关：show 时挂一个 30 秒的保险定时器，到点强制关闭并提示稍后重试。
- 错误用 Toast 说明：一句「提交失败，请重试」足够，详情与行动指引放页内提示。
- 禁多重 Loading：同一时刻只允许一个全局反馈，并发请求合并计数，全部结束才关。
四、验收清单：专盯异常分支
反馈的验收不看正常流程，专挑异常路径掐表。
| 检查项 | 达标口径 | 常见错误 |
|---|---|---|
| 关闭覆盖 | 断网、超时、取消三条路径 Loading 都关闭 | 只测成功分支 |
| 时长上限 | 任何 Loading 存活不超过 30 秒 | 转圈到用户杀进程 |
| Toast 频次 | 单次操作触发的 Toast 不超过 1 条 | 连续弹三四个提示 |
| 无障碍 | 读屏能播报结果提示与错误摘要 | 纯视觉反馈无替代文本 |
五、避坑清单
四条口诀：该遮才遮、能短则短、合并同类、留好退路。
- 别滥用透明遮罩：需要用户继续操作的场景不挂 mask，别让一个提示把整页锁死。
- 别用 Toast 承载长内容：超过一行的说明改用页内提示，闪一下没人读得完。
- 别让并发请求打架：三个请求各自 show/hide 会互相覆盖，统一封装做计数管理。
- 别忘读屏用户：转圈与 Toast 都是视觉信号，关键结果要有读屏可播报的文本。
六、常见问题 FAQ
Loading 要不要加遮罩？
按场景：提交订单这类不能重复触发的操作挂遮罩；列表刷新、预加载这类允许并行的操作不挂，别为了「防手贱」把整页冻住。
能自定义样式吗？
可以，图标与文案都支持定制；但自定义别过头——动画超过半秒、文案超过一行，就背离了「快速反馈」的本意，宁可简单。
多个请求并发时怎么处理反馈？
合并：请求封装里做计数，第一个开始时 show、最后一个结束时 hide；别让每个请求各弹各的，用户看到「转圈闪来闪去」就是没合并。
这个和 GEO 地理位置配置有关系吗？
没有。Loading 与 Toast 是反馈机制问题；GEO 指小程序 GEO 地理位置配置——门店地址、经纬度、服务类目，决定附近检索展示，不是按城市堆关键词的地域 SEO。
怎么快速发现「永不关闭」的漏洞？
用自动化用例遍历所有请求分支，外加真机弱网测试：开飞行网点提交，看 Loading 是否在超时上限内关闭；这类用例进回归清单，每次发版跑一遍。
