对应 PRD 5.4-3e 三级降级链。每条测试都要人工确认文件是否真的落到设备上—— 已知故障 316518 的表现就是「Promise 成功但用户没拿到文件」，只看自动结果会误判通过。
生产架构是浏览器端压缩，交付给下载的就是 Blob。必须用 Blob 测，用服务器直出文件测不到真风险。 先预取也是为了满足下一条的 transient activation 约束。
主路径。W3C 规范：files 是数组，允许一次交多个文件。Safari 14+ 支持 files 参数。
验证我在文档里写的那条设计约束——share 需要用户手势（transient activation）。
若这里报 NotAllowedError 而 T1 正常，就证明「点击后才去取图压缩」的写法在 iOS 上必然失败，
预取不是优化而是必需。
判断故障是「多文件特有」还是「share 本身在该机型就不可靠」（对应 316518 的机型差异）。
<a download>无服务端参与，纯 blob: URL。对应未修问题 275473 / 321299（blob 下载在真机上失败或为空）。
Content-Disposition: attachment走 /api/img/1，由函数附上 attachment 头。这是改到 Pages Function（同源）后的预期生产形态。
复现 263608 那一类「TXT/图片在当前标签打开而非下载」。T5 与 T6 的差异就是那条响应头的价值。
这条是本次最该测的：caniuse / MDN / WebKit 三处都查不到 iOS Safari 对「连续多下载」的限制说明， 标准只留了一句裁量条款。所以只能实测。探针会记录每次点击后页面是否被隐藏（被隐藏往往意味着发生了导航）。
最后一级。确认图片可长按、且引导文案在视觉上找得到。
OPFS 与 showSaveFilePicker。文档结论是二者都不作为交付手段（OPFS 是站内私有存储，卸载即失； showSaveFilePicker 在 iOS 从未支持）。这里只做一次真机确认。