工程上最危险的不是完全不可用，而是在理想环境里正常、进入真实网络和真实数据量后悄悄失去边界。 反复分配短命大 buffer 会增加 GC 和原生内存压力，但池化只适合可明确归还的所有权。转移后的 ArrayBuffer 已 detached，不能直接放回原池。
性能优化先定义用户等待的完整区间，再拆分 CPU、队列、网络和持久化阶段。平均值会掩盖真正流失用户的尾延迟，优化必须比较 p95/p99 与资源成本。
工程边界与取舍
落地时要把关键选择变成稳定契约：输入如何校验、状态由谁推进、资源何时释放、旧版本如何降级。只有这样，后续优化才不会改变原有语义。
- 按 16/64/256 KiB 等大小类设每类字节上限，借出时记录 owner，归还时清零敏感区域；后台或 memorypressure 时主动清空空闲池。
- 把协议事实、用户意图和自动恢复分层；自动化只能恢复事实，不能推翻用户明确选择。
- 资源释放是协议的一部分：定时器、句柄、队列和临时数据都要在终态中可重复清理。
“ArrayBuffer 池与 GC：复用能提速，也能把内存永久占住”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
生产环境会怎样出错
不要把异常路径理解成弹一次提示。它还包括在途工作如何停、对端如何获知、残留数据如何处置，以及下一次操作是否会继承旧状态。
- 一个无限 Map 按任意大小缓存会被攻击者用奇异块尺寸撑爆；复用未清零 buffer 还可能把前一个文件数据泄露给下一任务。
- 只修正界面状态而没有清理底层资源，下一次操作继承队列、锁或过期凭据并再次失败。
- 只在理想数据量下测试，真实的大文件、长会话或高并发会越过隐含上限并产生级联故障。
把测试跑成闭环
测试不能以“最后成功了”结束。还要测量经历了多少次副作用、等待多久、是否泄露内容，以及失败后再次执行能否从干净基线开始。
- 连续传输不同大小与敏感内容，比较无池、有界池和无限池的分配数、暂停、常驻内存，并扫描复用缓冲是否残留 canary。
- 用乱序、重复和延迟消息驱动状态机，确认旧版本被丢弃且显式停止不会被自动恢复覆盖。
- 用故障注入验证告警先于用户投诉触发，并确认值班人员能从有限证据定位到具体阶段。
最终结果应同时满足正确性、可恢复性和可解释性。任何一项只能依赖刷新页面或工程师猜测，都说明协议闭环仍不完整。