网页3D展台切了十几个房间后越切越卡，刷新一下又顺了，是显存没释放吗？

结论：网页3D展台在触摸屏上连续切换房间，越切越卡、刷新一下又恢复，按 2026 年常见交付经验，多数不是模型面数太大或设备太旧，而是切换时 GPU 侧资源没有回收：贴图、几何体、材质、阴影贴图与渲染目标持续累积，直到触及浏览器为单个页面划定的显存上限才开始掉帧。典型线索是首屏帧率正常，连续切换十几次后帧率明显下滑，刷新页面立刻回到正常水平。

为什么「刷新就好」通常是资源没释放的信号

WebGL 的资源分成两层：一层是 JavaScript 里的对象引用，一层是真正占 GPU 显存的缓冲和纹理。把对象置为 null 只解决前者，后者要显式调用 dispose 才会释放。浏览器为了运行稳定，一般不会主动替你回收仍被页面引用的 GPU 资源；如果页面反复创建而不释放，占用就会一路往上走。

所以「刷新就好了」这个现象很关键——刷新会销毁整个 WebGL 上下文，把 GPU 侧资源一次性清空。如果刷新后表现立刻恢复，说明问题大概率出在资源生命周期管理上，而不是显卡性能或模型本身有多重。

• 贴图：每次进场景都重新创建一次贴图，切出时不 dispose，是常见的一号泄漏源。
• 几何体与材质：同一份模型被反复加载，顶点缓冲就会反复申请。
• 渲染目标：后期处理、阴影、镜像用的 RenderTarget 不释放，占用通常比普通贴图更大。
• 事件监听与定时器：不解除绑定会让旧场景继续参与运算，表现为越用越慢。

判断是不是显存问题：用「三段基线法」对照

单看一次帧率说明不了什么，把「首屏、连续切换之后、刷新之后」三个状态放在一起比，才能区分是模型本来就重，还是资源没回收。这也是现场排查时比较省力的做法。

1. 第一段，首屏基线：刚进入页面时记录帧率、draw call 数，以及渲染器里几何体与贴图的数量。
2. 第二段，切换压力：按真实使用习惯来回切换场景十几到几十次，再记录同样几项。
3. 第三段，刷新对照：刷新页面，重新进入首个场景并记录。

判断口径是：如果第三段和第一段接近，而第二段明显掉下来，基本可以判定为资源没释放；如果首屏本身就不达标，那要先回到模型面数、贴图尺寸和材质数量上找原因，不要一上来就怀疑内存泄漏。浏览器的任务管理器里一般能看到 GPU 内存一项，做趋势对照比看绝对值更有意义。

交付现场：贴图精度、阴影和事件监听常是隐性放大器

在项目里常见的情况是：甲方一次性给来整套 4K 贴图，预算和周期都不允许重做，做法通常是入库前先统一降一档，漫反射贴图压到 2K 以内、法线单独保留，再按场景拆文件夹。这么做多数能把切换压力降下来。代价是如果代码里漏掉某几张贴图的 dispose，反复切换十几分钟后仍然会开始掉帧，最后要回炉补资源回收逻辑，按经验区间一般会多出 1 到 3 个工作日。

阴影贴图和实时反射也常被忽略：为了画面好看，一套场景挂了三四个实时阴影，每个都带自己的一张渲染目标，切场景时忘了跟着释放，占用会翻倍。交付时要先核对阴影是否开了缓存、反射是否有降级策略，再决定哪些资源允许常驻。

可复用的资源管理清单：「登记—复用—过期—回收」

之所以按这四步划分，是因为一次性销毁容易把还要用的公共资源也删掉，而完全不管又往往泄漏。用引用计数把「谁还在用」这件事显式记下来，才能在多场景之间安全复用。

1. 登记：场景加载时，把创建的贴图、几何体、材质、渲染目标写进一张带场景标识的表，便于统一查找。
2. 复用：环境贴图、字体、公共材质这类跨场景资源只创建一次，被引用时计数加一。
3. 过期：切出场景时计数减一，只有归零的资源才进入待回收队列，避免误删。
4. 回收：按渲染目标、材质、贴图、几何体的顺序释放，再清理渲染列表，最后解绑事件监听与动画循环。

做到什么算合格：连续切换二三十次，帧率和占用能回落到接近首屏水平，不再持续爬升。反过来，如果每次切换后占用都往上走一小截，即便当次看不出来，长时间停留在页面上也会出问题。

全量预载还是按场景分包，怎么取舍

两种做法各有代价，关键是看用户会不会频繁在不同场景之间跳。2026 年比较常见的判断依据是首次进入时间和切换次数这两个指标。

• 全量预载：首屏等待常见在 5 到 15 秒量级，弱网更久；换来的是切换几乎无感，适合场景数量少、跳转频繁的展示页。
• 按场景分包：首屏通常能压到 2 到 5 秒量级，切换时有 0.3 到 2 秒的加载间隙，适合房间多、用户大多只逛一两个的场景。
• 开发成本：分包要多写加载状态、预加载与资源登记逻辑，经验区间会比全量预载多出 2 到 5 个工作日。
• 适用对象：设备档次偏低的展会触摸屏，分包更稳；高配主机加固定浏览动线的展厅，全量预载体验更顺。

适用场景与边界

资源回收不是每个 WebGL 页面都需要，判断标准是「同一个页面生命周期里会不会多次创建和销毁场景」。满足这个条件才值得投入。

• 适合：多房间、多配置、多版本的展示页；长期不刷新、挂在展台或触摸屏上运行的项目。
• 不适合：整站只有一个场景、加载一次就不再变的页面；模型总量很小、刷新即用的临时演示页。
• 边界：如果切换场景时是整页跳转而不是单页内切换，浏览器会自然释放上下文，一般不需要再做引用计数，硬上反而增加维护成本。

常见问题

网页3D 展台切场景越来越卡，一般先从哪儿查起？

先刷新做一次对照。若刷新即恢复，优先查切场景时的贴图与渲染目标是否释放，再查事件监听有没有解绑。

带资源回收的 WebGL 项目，交付周期一般在什么区间？

按 2026 年项目交付经验，单场景页面常见 5 到 10 个工作日，多场景含资源管理常见 10 到 25 个工作日，具体看模型量。

WebGL 项目的报价差在哪，建模和渲染各占多少？

报价多为区间，建模与优化常占四到六成，渲染与交互开发占三到五成，其余为机型适配与真机调试。

WebGL 交付时通常要给哪些文件？

常见交付源工程、压缩后的模型与贴图、还原说明，以及按平台规范核对过的验收清单，便于后续维护。

同一套 WebGL 页面，手机和电脑表现差很多算正常吗？

正常。移动端显存与填充率限制更紧，建议按机型分档设置贴图尺寸与阴影档位，而不是一套参数通用。

如果页面只是加载一次、不做场景切换，先把模型分档和贴图尺寸控制住通常就够了；只有长期驻留、频繁切场景的 WebGL 项目，才值得按上面的清单做资源回收。落地前建议先做一次三段基线测试，把首屏数据留档，后续优化才有对照。犀跃公司在交付这类长期运行的网页3D展示时，一般会把资源登记表一并交接给维护方。