如何通过Azure托管的ASP.NET Core 3.1应用实现大文件上传至Sharepoint

思路可行性评估 #

你提到的大文件上传不使用缓冲、直接通过流写入目标地址的思路完全正确，这是处理GB级大文件上传的标准最优方案，可以避免服务器内存被占满、触发不必要的磁盘IO，性能和稳定性都远高于缓冲方案。

你设计的两步实现思路整体合理，细节上可以做针对性优化，以下是实际落地的经验参考：

第一步：前端到ASP.NET Core服务端的上传实现 #

你参考的官方流式上传示例逻辑是可用的，落地时注意这几个关键点：

• 主动关闭ASP.NET Core默认的请求缓冲，不然底层还是会自动缓存整个请求体，流式处理就失去了意义，接口可以加上[DisableRequestSizeLimit]特性，同时按需配置Kestrel的最大请求体大小，避免大请求被默认规则拦截。
• 分块上传时要增加块序号、块哈希校验逻辑，同时配套断点续传能力，用户上传中途断网不用从头重传，体验提升非常明显。
• 如果你托管在Azure App Service，记得额外修改部署配置里的IIS请求大小上限，默认的上限很低，单块大小超过限制会被直接拦截。

第二步：服务端到Sharepoint的上传实现 #

你计划采用的Graph SDK大文件上传方案是官方推荐的标准实现，完全可用，可以做进一步优化：

• 不用等收完全部分块再往Sharepoint传，完全可以做「边收边传」：前端传一个块到你的服务端，你直接把这个块的流转给Graph的上传会话，不需要把整个文件暂存在你的服务端内存或磁盘里，既节省服务器资源，还能减少整体上传耗时。
• Graph的大文件上传会话本身支持断点续传，你可以把会话ID存在服务端，就算服务重启也能恢复之前的上传进度，不需要用户重新上传。
• 提前做文件大小校验，Sharepoint Online单个文件最大支持250GB，超过这个限制的文件直接提前给用户提示，不要等传完才报错。

额外落地建议 #

• 你托管在Azure上可以直接用Azure托管身份调用Graph API，不需要硬编码客户端密钥，安全性更高，也不用管理密钥轮换。
• 尽量不要把文件暂存在Azure App Service的本地磁盘，本地磁盘是临时的且容量很小，如果确实需要暂存可以用Azure Blob Storage，不过能边收边传的话完全可以省掉暂存环节。
• 你对Sharepoint不熟悉的话可以拆分逻辑实现：先把文件上传到Sharepoint文档库拿到唯一的DriveItem ID，再把这个ID关联到对应列表的附件字段即可，逻辑清晰不容易出错。

内容的提问来源于stack exchange，提问作者dot