核心策略是按体积分三级动态传输：≤128KB直传并压缩；128KB~5MB启用带CRC校验的分块传输；＞5MB返回413并引导分片上传，全程依托HTTP/2、mTLS、HMAC校验与服务端智能决策保障安全高效。

核心思路是：根据资源文件实时体积，动态选择传输策略——小文件走常规HTTPS响应，中等文件启用分块传输（Chunked Transfer Encoding），大文件则触发分片上传+断点续传机制，并配合HTTP/2多路复用与服务端流式响应能力。

按体积分级的三档策略

不依赖预设阈值，而是运行时计算文件大小后决策：

• ≤128 KB：直接返回完整响应，设置Content-Length，启用Brotli压缩，利用TLS 1.3早期数据（0-RTT）加速首字节时间
• 128 KB ~ 5 MB：禁用Content-Length，启用Transfer-Encoding: chunked，按64 KB分块流式发送，每块附带CRC32校验头（自定义X-Chunk-Checksum）
• >5 MB：拒绝直传，返回413 Payload Too Large并携带X-Upload-Strategy: multipart-resumable头部，引导前端切换为分片上传流程（基于File API + Range协议）

服务端动态识别与响应适配

关键不在客户端判断，而在服务端根据请求上下文智能响应：

• 对GET请求，读取文件元信息（如stat()）后立即确定传输方式，避免全量加载到内存
• 对POST请求，解析Content-Type: multipart/form-data边界前先读取Content-Length或Transfer-Encoding，结合X-Expected-Size头部做预判
• 若检测到客户端支持HTTP/2且请求含Accept: application/octet-stream，即使文件>5MB也允许流式响应，但需开启nghttp2优先级树调度，保障小资源不被阻塞

客户端协同机制

服务端策略生效的前提是客户端能理解并配合：

• 首次请求可带X-Client-Capabilities: http2,chunked,resumable声明能力集
• 收到413响应后，前端自动提取X-Upload-Endpoint和X-Chunk-Size，启动分片逻辑（例如按2MB切片、并行上传、MD5指纹校验）
• 对流式响应（chunked），使用ReadableStream逐块解码，配合TransformStream实现边收边解密/解压，避免内存堆积

安全与可靠性增强点

分级不是简单切分，必须嵌入安全闭环：

• 所有分块/分片均强制TLS双向认证（mTLS），服务端验证客户端证书中的upload_scope扩展字段
• Chunked传输中，每个块末尾附加HMAC-SHA256签名（密钥由会话派生），客户端校验失败则中断连接
• 大文件分片上传时，服务端维护upload_id → [part_id: checksum]映射，合并前校验全部分片完整性，缺失或篡改则返回460 Incomplete Parts