流式上传兼容性断层需通过“行为可观测性”和“能力可探测性”识别，三步定位包括检测xhr2、formdata+blob、fetch+readablestream支持；主流断层对应iframe模拟、input直传、js分片降级；补丁应封装为能力检测+工厂模式，服务端需统一处理多路径请求。
流式上传的兼容性断层通常不报错，而是表现为进度停滞、响应延迟、分片丢失或直接 fallback 到全量提交。识别关键在“行为可观测性”和“能力可探测性”两个层面，补丁编写需兼顾检测逻辑、协议适配与降级兜底。
一、三步定位流式上传兼容性断层
无需依赖用户反馈，通过前端主动探测即可发现潜在断裂点：
-
检查 XMLHttpRequest Level 2 支持：执行
window.XMLHttpRequest && 'upload' in new XMLHttpRequest()。返回false表明 IE9 及以下或部分 WebView（如旧版 Android System WebView）不支持原生上传事件监听 -
验证 FormData 构造能力：尝试
new FormData().append('file', new Blob(['test']))。若抛出TypeError或 append 失效，说明运行环境不支持 Blob 作为文件源（常见于 iOS 10.3 以下 Safari） -
探测 fetch + ReadableStream 支持：检查
typeof window.ReadableStream !== 'undefined' && typeof fetch !== 'undefined'。缺失任一即无法启用现代流式 chunk 上传（如fetch(url, { method: 'POST', body: stream })）
二、主流断层场景与对应降级策略
不同断层触发不同补丁路径，核心原则是“能流则流，不能流则切片，切片不可靠则整传”：
-
XHR2 不可用 → iframe 模拟异步上传：创建隐藏
<iframe name="upload-frame"></iframe>，设置表单target="upload-frame"，监听 iframeload事件解析服务端返回 JSON（注意 IE6–7 需引入json2.js） -
FormData + Blob 失效 → 退回到 input[type=file] 的 files[0] 直传：绕过内存构造，直接使用原生
input.files[0]提交，配合enctype="multipart/form-data"表单提交，适用于 Safari 5.1–10.2 等老版本 -
ReadableStream 不可用但 XHR2 可用 → 启用 JS 分片上传：用
File.prototype.slice()手动切片（兼容至 IE10+），每片单独 POST，服务端聚合；需维护分片序号、MD5 校验与重传逻辑
三、补丁代码结构建议（轻量、可插拔）
避免全局污染，封装为能力检测 + 上传器工厂模式：
- 导出
detectUploadCapability()返回对象，含字段：supportsStream、supportsChunked、fallbackMethod（值为'iframe'/'form'/'xhr-slice'） - 上传主函数接收该能力对象，内部路由到对应实现模块，各模块仅关注自身协议逻辑，不耦合判断分支
- 所有上传路径统一返回 Promise，并暴露
abort()方法（iframe 方案可通过iframe.contentWindow.stop()或移除 iframe 实现软中断）
四、服务端需同步配合的关键点
前端降级无效，往往因服务端未对多路径做兼容处理：
- 接收逻辑不能强依赖
Content-Type: multipart/form-data的边界解析——iframe 和表单提交也走此类型，但 XHR 分片上传常用application/octet-stream或自定义content-type - 分片上传需识别
Content-Range或自定义 header（如X-Upload-ID、X-Chunk-Index），并支持合并前校验 MD5/SHA256 - 整传与分片应共用同一文件存储路径生成规则，避免前端降级后文件名或路径语义不一致
