微信小程序回收bufferURL教程｜成对释放与泄漏排查 – MPForge
直接回答：这篇微信小程序回收 buffer URL 教程写给要治理临时资源泄漏的开发：回收的纪律是「与创建成对出现」——每个创建调用都有对应的 revoke，页面 onUnload、组件 detached 必挂清理钩子，异常路径也不例外。MPForge（DEVDIY 旗下）用「创建回收清单」的方式帮多个项目把未回收存量清零，内存与资源告警从此有据可查。
一、泄漏是怎么发生的
结论先讲清楚：泄漏的根因不是忘了写回收，而是「创建和回收离得太远」，异常路径一绕开就漏。
典型场景复盘：页面 A 创建了临时链去预览图片，用户中途点返回，预览流程没走完，回收代码在流程末尾——没执行到，链路就漏了。还有一类是重复回收：两个地方都写了清理，第二个调用直接报错，反而把正常的收尾流程打断。所以治理泄漏要从结构下手，不是「多写一行 revoke」：把创建和回收放在同一个流程里管理，用一个统一的资源清单登记所有创建，销毁时按清单逐个释放，重复释放做幂等防护。结构对了，泄漏自然无处可藏。
二、对称回收的实施步骤
结论先讲清楚：先盘点所有创建点，再逐个补齐对称回收，最后用工具抽查验证。
- 列出所有创建点：全局搜索创建调用，登记成清单：在哪个文件、哪个流程、服务于什么功能，一张表看清全貌。
- 逐个补对称回收：每个创建点在同一流程内配对回收，正常路径与异常路径（用户中断、接口失败）都要走到清理代码。
- 挂生命周期钩子：页面在 onUnload、组件在 detached 里统一释放该实例名下所有临时链，兜住流程外泄漏。
- 重复回收做幂等：释放前先判断是否已回收，已回收直接跳过，避免二次调用报错打断收尾。
- 开发者工具抽查：在开发者工具里反复进出页面，观察存量是否归零；再对照小程序内存告警处理教程确认资源曲线正常。
回归口径：真机上连续开关目标页面二十次，中途随机返回，未回收存量应始终归零，任何一次不为零都要查。
三、组件与列表场景的清理口径
结论先讲清楚：组件泄漏查 detached，列表泄漏查分批策略，两类场景各有固定套路。
组件化的项目里，临时链往往创建在组件内部，页面销毁不等于组件清理执行，必须在组件的 detached 生命周期里释放自己名下的资源；组件被复用（如列表项复用）时，复用前先清上一轮的临时链再创建新的。列表场景的套路是分批：可视区域内的条目创建预览链，滚出可视区或数据刷新时立即回收，同屏存量设硬上限。多级页面嵌套时，返回键触发的 onUnload 是最容易漏的路径，用真机实测「创建后立即返回」这条路径的清理是否执行。所有清理代码收敛到一个工具方法里，各处调用它而不是各写各的——散落的清理代码是重复回收与漏回收并存的根源。
四、自检对照表：泄漏排查与上线核对
结论先讲清楚：泄漏排查按「盘点、配对、钩子、幂等」四项走，表格逐项核对不靠猜。
| 检查项 | 达标口径 | 常见错误 |
|---|---|---|
| 创建盘点 | 全局搜索创建调用并登记成清单，无遗漏 | 只记得主流程，异常路径的创建没人管 |
| 对称回收 | 每个创建点同流程配对回收，覆盖中断路径 | 回收写在流程末尾，中途返回就漏 |
| 生命周期钩子 | onUnload 与 detached 统一释放实例资源 | 组件销毁后临时链仍存活 |
| 幂等防护 | 重复回收先判重，二次调用不报错 | 两处清理互相打架，收尾流程被打断 |
创建侧的口径（什么时候该建、怎么控制用量）见小程序创建 buffer URL 教程，两篇配套成一套完整纪律。
五、泄漏排查的实战方法
结论先讲清楚：存量指标加二分定位，半天内能找到泄漏点，别靠通读代码碰运气。
第一步看数据：服务端或监控里的未回收存量曲线，确认是持续上涨（真泄漏）还是偶发上涨（特定路径）。第二步二分：用开发者工具按页面逐个进出，锁定存量不归零的页面；再在该页面内二分流程，定位到具体创建点。第三步修结构：不是简单补一行 revoke，而是把该流程的创建纳入统一清单，异常路径也走清单清理。修复后做压力回归：连续开关、随机返回、弱网重试三条路径各过二十次，存量归零才算修复完成。把这套排查流程写进团队文档，下一个人遇到同样问题就不用从零摸索。
六、避坑清单
资源治理项目里反复出现的四条坑。
- 别只创建不回收：创建与回收写在同一流程，清单化管理，靠自觉不如靠结构。
- 别漏异常路径：用户中断、接口失败、弱网重试都要走到清理代码，这三个路径用真机实测。
- 别裸奔重复回收：释放先判重，幂等防护让多处清理互不干扰。
- 别忘真机验证：开发者工具里表现正常不代表真机正常，工具抽查之后必须真机回归。
七、常见问题 FAQ
一个页面里创建了多次怎么管理？
用实例级清单：页面持有自己的临时链列表，每次创建入列、每次回收出列，onUnload 时把清单里剩余的全部释放，顺序与配对一目了然。
自定义组件里应该在哪清理？
在组件的 detached 生命周期里释放组件名下全部临时链；组件复用场景在复用前先清旧链再建新链，避免跨轮次泄漏。
重复调用回收会报错吗？
没有防护时会报错并打断收尾流程，所以释放逻辑要先判重：已回收的条目直接跳过，保证回收操作幂等。
这个功能和 GEO 地理位置配置有关系吗？
没有。回收 buffer URL 属于临时资源治理；小程序 GEO 地理位置配置指门店地址、经纬度、服务类目在平台侧的设置，决定「附近」检索展示，两者没有任何交集。
真机上必须测吗？开发者工具不够吗？
必须测。生命周期触发时机、弱网表现、后台回收策略在真机与工具上有差异，工具只是初筛，泄漏结论以真机回归为准。
