通过App Service与函数应用向Azure存储容器上传大Blob问题咨询

• 分块上传仅保留最后一块的原因：所有分块请求独立触发全量覆盖写入逻辑，不管是Flask后端还是Azure Function，每收到一个分块就直接调用upload_blob，该方法默认执行「创建/覆盖整个Blob」的操作，没有做块关联和合并，最终只会保留最后一次写入的分块内容。
• Azure App Service 存在平台级230秒请求超时限制，该限制无法通过应用配置修改，长连接中转大文件的链路天然存在超时风险。
• Python Azure Storage SDK内置的自动分块逻辑是SDK侧的上传行为，仅当SDK拿到完整文件流后才会自动切分块、并发上传、重试失败块，该能力本身支持进度追踪，不需要前端额外引入组件做手动分块。

优先选择前端持SAS直传Blob存储的架构，完全绕开App Service/Azure Function的中转链路，从根本上规避超时、请求体大小限制问题，实现成本最低、可靠性最高：

• 后端Flask接口仅负责权限校验，用户发起上传请求时，后端生成对应目标Blob路径的短有效期SAS令牌返回给前端，SAS仅授予该单条Blob路径的写入权限，有效期根据文件大小上限设置为1-24小时即可，不会泄露存储账户全量权限。
• 前端拿到带SAS的Blob地址后，直接使用Azure Storage Blob官方JS SDK直传文件到存储账户，链路不经过你的应用服务，不受平台超时规则限制。
• 上传进度直接通过SDK内置的进度回调获取，不需要手动实现分块逻辑，SDK默认已经做了自动分块、断点续传、失败重试处理，核心参考代码如下：

import { BlobClient } from "@azure/storage-blob";

// 从自有Flask接口获取带SAS的目标Blob访问地址
const blobClient = new BlobClient(targetBlobUrlWithSas);
await blobClient.uploadData(selectedFile, {
  blockSize: 4 * 1024 * 1024, // 单块大小默认4MB，可根据网络情况调整
  concurrency: 5, // 并发上传5个分块，调整该值可控制上传速度
  onProgress: (progressEvt) => {
    // 直接计算上传进度即可
    const uploadPercent = Math.round((progressEvt.loadedBytes / selectedFile.size) * 100);
    console.log(`当前上传进度：${uploadPercent}%`);
  }
});

注意Azure Function消费计划存在单请求最大100MB请求体限制、230秒超时限制，仅适合小于100MB的文件场景，大文件场景不推荐该架构。如果必须使用，按如下逻辑实现：

1. 关闭前端dropzone等组件的自动分块上传能力，将完整文件作为单个请求发送到Function端点，Function收到完整请求体后再调用upload_blob上传到Blob存储即可。
2. 如果需要支持超过100MB的文件走Function中转，需要自行实现完整的分块上传会话逻辑：
   • 初始化阶段：前端发请求申请上传，Function生成唯一上传会话ID，在持久化存储（Redis、表存储等）中记录会话对应的文件名、总大小、总分块数、过期时间，返回会话ID给前端。
   • 分块上传阶段：前端每上传一个分块时携带会话ID和分块序号，Function收到分块后不要直接写入Blob，先将分块存到临时存储路径，标记对应序号分块上传完成。
   • 合并阶段：当前端上传完所有分块后，向Function发送合并请求，Function校验所有分块齐全后，按序号顺序读取所有分块，通过Storage SDK的stage_block方法逐块提交到Blob存储，最后调用commit_block_list提交全部分块ID完成完整Blob的拼接，之后清理临时存储的分块文件。

• 不要在收到单个前端分块时直接调用upload_blob，该方法不支持分块追加，仅适合完整文件的全量写入。如果要手动操作分块，必须使用「提交单个块-最终提交块列表合并」的接口流程。
• 不要将App Service、Azure Function这类HTTP触发的服务作为大文件长连接中转节点，这类服务的平台级限制无法通过代码配置绕过，后端仅需处理权限校验、上传完成后的业务回调即可，大文件传输链路尽量缩短。

内容的提问来源于stack exchange，提问作者yihao.fu