使用Microsoft Graph API断点续传文件至SharePoint时出现Error 400无效请求但文件已创建的问题求助

我来帮你梳理几个针对性的排查方向，这个“报错但文件实际生成”的情况确实有点诡异，大概率是请求细节或者会话参数的小问题：

• 严格检查Content-Range的格式与数值正确性
  这是分块上传最容易出错的地方：

  • 格式必须严格遵循bytes start-end/total，比如文件总大小是10MB，第一块上传0-5242879字节（5MB），那Content-Range应该是bytes 0-5242879/10485760，注意end是当前块的最后一个字节索引（不是块大小），total是文件的完整字节数，不能填当前块的大小。
  • 另外Graph API要求非最后一块的大小至少是5MB，如果你的块小于这个值且不是最后一块，服务器可能会返回400，但同时已经写入了部分数据到SharePoint，导致文件存在。

• 验证请求头的完整性

  • 除了Content-Length和Content-Range，务必添加Content-Type头，设置为文件对应的MIME类型（比如application/vnd.openxmlformats-officedocument.spreadsheetml.sheet对应Excel，image/png对应图片），缺少这个可能导致服务器解析请求时出现异常。
  • 确认Content-Length的值和你上传的块的实际字节数完全匹配，比如你上传的块是5242880字节，Content-Length必须精确等于这个数，多一个少一个都可能触发400。

• 核对上传会话的参数一致性

  • 你创建上传会话时的请求体参数（比如@microsoft.graph.conflictBehavior）要和上传URL里的overwrite参数保持一致：比如创建会话时设置了@microsoft.graph.conflictBehavior: replace，那URL里的overwrite=True是对的；如果创建时是fail，但URL里写了overwrite=True，就可能出现冲突报错，但覆盖操作已经执行的情况。
  • 检查创建会话时是否设置了deferCommit：如果设置为false，服务器会在收到最后一块后立刻提交文件，要是你误将中间块当成最后一块上传，可能会触发错误，但文件已经被部分写入并创建。

• 检查上传会话的状态与分块顺序

  • 可以用GET请求调用你的上传URL（带上tempauth参数），获取当前会话的状态，响应里的nextExpectedRanges字段会告诉你服务器期待下一个上传的字节范围，通过这个可以确认你之前上传的块是否被正确接收，有没有重复上传或者顺序错误的情况。
  • 比如你先上传了10485760-15728639的块，再上传0-5242879的块，虽然服务器可能会合并数据，但某些场景下会返回400错误。

• 排查临时授权令牌的有效性
  上传URL里的tempauth是临时令牌，可能存在过期的情况，虽然过期通常返回401，但偶尔服务器处理异常会返回400。可以尝试重新创建上传会话，拿到新的URL后立刻发送PUT请求，排除令牌过期的影响。

• 简化测试场景定位问题

  • 先测试单块上传：找一个刚好5MB的文件，用一个PUT请求完成上传，看是否还会返回400。如果正常，再测试分块上传（比如10MB文件分两块），逐步缩小问题范围。
  • 用Graph Explorer复现相同流程：如果在Graph Explorer里操作正常，那大概率是你代码里的请求构造有细节问题（比如头信息的编码、换行符、参数转义错误等）。

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