Flux Art先把问题落到预览资源上
从 Flux Art 取得图片后，团队自建的素材审核页可能用对象 URL 展示本地文件。连续换图时页面仍能操作，内存却逐步上涨；另一种故障是刚显示便不能另存图片。这两种现象需要相反的检查：前者看资源是否遗留，后者看释放是否早于使用结束。本文讨论你自己开发的浏览器工具，不将这些按钮、资源登记或清理逻辑描述为平台内置能力，也不以单次内存读数断定发生泄漏。
先登记谁创建了这条地址
建议每次创建时记录资源编号、所属页面部件、文件版本、当前用途与关闭动作。一个文件可能被预览、放大窗口和下载按钮同时使用，不能只登记缩略图。不要把对象 URL 当作长期素材地址写进业务数据库，也不要发给同事当共享链接。先保留能重新取得原始文件的来源，再让临时地址服务当前交互。登记的是使用关系，不需要把用户图片内容或整条临时地址上传到诊断日志。
读取规范，再决定回收时点
MDN 说明，每次 createObjectURL 调用都会产生新的对象 URL；只要相关地址仍有效，底层对象就可能继续被保留。revokeObjectURL 用于释放不再需要的地址，但图片加载完成不代表用户已经结束右键保存或打开大图。工程上应把清理放到资源确实不再供用户使用的阶段，而不是统一挂在图片 load 回调里。下面是设计核对表，不是浏览器内存实测结果。
| 观察项 | 应留证据 | 不合格时处理 |
|---|---|---|
| 新建预览 | 资源编号与创建部件 | 补登记后再测 |
| 多处共享 | 仍在使用的消费者 | 暂不释放 |
| 换图失败 | 旧图可用与新资源清理 | 修复失败分支 |
| 关闭大图 | 最后消费者退出 | 释放对应地址 |
| 另存图片 | 实际可保存的文件 | 检查过早回收 |
| 连续操作 | 创建释放计数及环境 | 未知原因继续定位 |
替换图片要交接资源，不要只改 src
建议先为新版本准备独立资源，确认预览可用，再把界面和操作按钮切换到同一版本。随后核对旧版本是否还有放大窗口、待处理下载或其他消费者；全部退出后才释放旧地址。失败时继续保留旧版可用预览，清理未接管的新资源。需要共享地址的部件应有明确的引用登记，或者各自创建并负责释放，不能一边共享一边由任意部件决定全局清理。
关闭和失败路径也要走清理
把“移除这一项”“关闭审核面板”“文件读取失败”“切换到另一个项目”逐项列为结束条件。重复调用关闭操作应安全，清理之后从登记表移除记录，避免把已失效地址再次分配给新按钮。页面卸载会帮助释放资源，但长期不刷新的工具不能只等用户关标签。排查时先看本次创建与释放是否成对，再看内存趋势；图片解码缓存和其他对象也会影响内存，地址数归零并不是全部内存已释放的证明。
用两种故障验收，而不是只测显示
假设审核员轮流查看甲、乙两张图片各二十次，最后保留乙的大图窗口。这是假设流程，不是真实用户案例。合格结果应是甲的无人使用资源完成清理，而乙仍能执行界面承诺的打开与保存动作。然后关闭乙并检查登记表归零。再注入一次新图片解析失败，确认旧预览不被清空，失败分支没有遗留新地址。测试次数只是本例输入，不是推荐的统一压力标准。
不要用固定延时掩盖所有权错误
发现另存失败后把释放延迟几秒，可能暂时让人工测试通过，却无法覆盖用户停留更久或设备更慢的情况。应回到资源消费者是否结束的证据。对程序触发下载的实现，也要结合实际浏览器验证点击、下载开始和后续清理，不假定一个定时器在所有环境都足够。不能确认的环境标为待补证，保留普通文件交付方式；不要为了证明优化有效而自动删除原始图片。
交付记录要能定位谁忘了结束
建议交付一份资源生命周期表，包含创建入口、所有使用部件、最后释放者和异常退出路线。记录测试浏览器与版本、操作序列、资源计数前后值、仍可执行的用户动作。内存曲线只作为辅助证据，不能替代这些操作核对。如果地址计数持续增加而登记显示无人使用，优先查遗漏的结束分支；如果计数正常但内存仍异常，再单独排查解码尺寸、缓存和其他引用，不把所有问题归咎于对象 URL。
资料和业务入口分开保留
技术依据核对于2026年11月9日：对象 URL 的用途与内存管理见 https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Schemes/blob 。本文的资源登记和测试流程是编辑建议。Flux Art 面向创作与商业素材制作，生成结果可用于商业用途；输入素材权利与商品真实性仍需单独核验。需要把已完成的图片接入自建业务工具，可从 https://flux-art.net/zh/openapi 了解接口入口；浏览器临时预览资源应由你自己的应用负责管理。