一、背景：收到一份记录，不等于拿到了完整现场
假设工程师收到同事发来的一份HAR文件，对方只说明“刚才处理了一张图片”，希望判断这次会话里发生了什么。此时需要还原的，不只是有哪些请求，还包括当时选择了什么功能、使用了哪个档位，以及浏览器是否已经缓存对应资源。没有这些条件，网络记录容易被解释成一个看似完整、实际缺少依据的故事。
本文以这个假设场景组织分析，但现有资料没有提供实际HAR文件、entries样例或字段规范。因此，下文围绕请求方向、响应体积、Timing、Mime Type以及Request Body、Response Body是否存在这些检查项讨论判断边界，不补写字段路径或解析代码。相关方法为建议流程，未包含实测数据。
资料依据为2026年10月12日核对的公开说明。模型名称、体积、来源与缓存方式来自这份资料，不能当成当前HAR已经包含的观察结果。分析时应始终区分“已知实现说明”“记录中实际可见的内容”和“仍需复核的推断”。
二、方案：先建立候选解释，再寻找对应证据
面对HAR中的entries，分析方案不应是看到大文件就直接判定其身份，而应先列出可能对应的业务环节。一次端侧任务可能包含模型资源准备，也可能直接复用已有缓存；用户文件是否外发则需要另行检查。模型资源与用户输入虽然属于同一次业务操作，却承担不同角色。
可以把待回答的问题分成三组：这条记录可能对应什么资源，资源流向如何，记录是否足以支持用户文件流向的结论。响应体积、Timing和Mime Type可以作为拟检查的线索，但资料没有给出这些项目的实际取值。因而不能预设某个值必然代表模型、缓存命中或文件外发。
业务上下文需要与记录一起补齐。建议确认具体功能、所选档位、输入样本、浏览器版本、操作日期和缓存状态，再尝试关联各条记录。如果同事无法提供这些条件，应缩小结论，而不是用模型参数填补整个会话。
三、步骤：从方向与体积辨认资源候选
请求方向的核心问题，是区分模型资源从站点进入浏览器，与用户文件从浏览器发往服务端。不能把“浏览器发起了一次请求”直接解释成“浏览器发送了用户图片”。需要结合请求对象与内容，判断这次交互实际涉及哪类文件。
响应体积可以帮助提出资源候选，但不能单独确认身份。图片抠图快速档使用ISNet INT8，约42MB；专业档使用BEN2 FP16，约219MB；骨灰级使用BiRefNet HR-Matting FP16，约447MB。这些是模型资源参数，只有确认当时选择的任务和档位后，才适合用来辅助解释记录。
视频高配档还说明，不能把任务资源理解成一个孤立文件。MatAnyone2当前比例档约294MB，并复用约51.3MB的RVM ResNet50进行首帧校准，合计约345MB，且仅限非商业测试。因此，即便记录中出现多个大体积资源候选，也应先考虑任务依赖，不能据此认定用户视频发生了多次传输。
四、步骤：让时间与类型服务于核对
Timing可以列为还原处理顺序时需要查看的项目，但现有资料没有提供它的具体记录，也没有说明各项时间数据的含义。本文不能据此虚构耗时，更不能给出判断缓存命中的时间阈值。能够沿用的原则，是结合请求发生的时间与业务操作定位，而不是单凭快慢作结论。
Mime Type同样需要与资源内容和任务上下文一起核对。资料没有列出各模型对应的类型标记，因此不能编造某种类型与某个模型的固定映射。即使记录中存在相关值，也不能仅凭它认定资源就是模型，或认定其中没有用户文件。
时间与类型的作用，是帮助整理检查顺序，而不是替代内容判断。资料建议先查看全部请求，再按类型、时间和地址定位，这个顺序应保留。若一开始就只留下符合预期的条目，后续分析可能遗漏其他与用户文件相关的请求。
五、步骤：正文是否可见，决定能核对到哪里
检查Request Body与Response Body是否存在，是为了判断手头记录能否支持内容核对。现有资料没有实际正文，也没有HAR导出条件，因此不能声称某条请求已经携带图片，或某份响应已经被确认是模型。正文缺失时，应明确缺少什么证据，而不是把“没有可看的内容”写成“没有发生传输”。
用户文件是否外发，需要检查是否存在携带文件内容的请求。模型资源是否符合预期，则是另一个问题：AI变高清会在每个模型加载前检查固定字节数与SHA-256，不符合预期就不进入推理。这项机制针对模型完整性，不能替代对用户文件流向的检查，也不能自行扩展到其他能力。
图片相关数据通常以blob地址在本地流转，处理结果也在本地生成。不过，看到本地流转线索并不足以覆盖会话中的全部请求。若要判断整个过程，仍需确认记录范围，并检查其他可能携带用户文件内容的条目。
六、验证：缓存推断需要处理条件配合
模型按需加载，各类资源独立缓存，图片抠图模型存放在浏览器Cache Storage中。已有模型再次使用时可以直接读取，因此没有新的模型资源请求，与缓存复用这一机制相符。但如果当前记录范围和缓存状态不明，就不能把这种解释写成已确认的缓存命中。
清理缓存、更换浏览器或更换设备后，需要重新取得模型资源。复核时，建议分别记录首次使用与已有缓存两种条件下的完整处理过程，并注明任务和档位。资料没有缓存命中率、Timing阈值或HAR状态值规则，因此不能据此输出统计结果或自动判定规则。
资源来源也应与任务说明对照。视频模型优先从ModelScope CDN取得，失败时回退到站点的同版本文件，检查通过后写入缓存。来源变化可以按这一已知机制提出解释，但不能仅凭变化就认定用户文件处理位置发生了改变。
七、注意事项与局限：会话结论不能覆盖全部功能
分析HAR之前，还应确认这次操作是否属于资料所述的端侧任务。HEIC写出、TIFF、JPEG 2000、图片导出PDF需要服务端能力，会把文件交给服务端处理；HTML转PDF执行转换后，也会提交去脚本的自包含快照给同源PDF服务。不能用模型本地运行的说明替这些功能作结论。
因此，对外只能表述为“常见格式不上传”，不能扩展成“所有功能都不上传”。服务器仍提供静态资源和模型文件，本地推理也不等于整个应用不需要服务器。文件外发的判断必须与具体功能对应，不能仅看会话中是否存在网络活动。
从HAR线索还原会话，应当得到有范围的判断，而不是补出缺失的现场。本文没有实际entries或正文证据，无法确认某条模型请求、缓存命中或用户文件传输；所给方法为建议流程，未包含实测数据。取得完整记录并补齐业务条件后，再限定到对应样本、功能和版本形成结论，才符合证据所能支持的范围。
