浏览器POST请求发送1.3MB左右大Payload失败问题求助

排查思路 #

• 定位writeFile内部阻塞/异常
  小文件能正常上传，大文件卡在before uploading日志之后，说明问题出在UploadingService.writeFile的执行环节。首先给这个方法加错误捕获，避免异常被吞：

  export const uploadFile = createAsyncThunk(
    'uploadService/uploadFile',
    async ({ sessionId, user, fileHandle, fileBuffer }) => {
      console.log('before uploading')
      try {
        const response = await UploadingService.writeFile({
          sessionId,
          user,
          fileHandle,
          buffer: fileBuffer,
        })
        console.log('after uploading')
        console.log(response)
        await UploadingService.closeFile({ sessionId, user, fileHandle })
      } catch (err) {
        console.error('上传失败详情:', err)
        throw err
      }
    }
  )
  

  同时在UploadingService.writeFile内部的关键步骤（XML生成、AES加密、请求发送前）加日志，确认是卡在编码、加密还是请求准备阶段。

• 检查大文件数据处理的内存问题
  1.3MB文件Base64编码后体积会增至约1.7MB，若writeFile是在主线程同步处理编码和加密，可能导致主线程阻塞，请求无法触发。可以测试将大文件buffer换成同等大小的随机字符串，看是否能复现问题，排除文件读取环节的问题。

• 验证请求大小限制
  虽然1.7MB不算超大，但部分后端中间件（如Nginx）或前端环境可能有默认请求体大小限制。可以用原生fetch构造相同大小的XML请求体直接发送，确认是否能触发网络请求；同时检查后端配置（如Nginx的client_max_body_size）是否允许该大小的请求。

解决方案 #

• 分块处理大文件
  将大文件拆分为多个小片段（比如每块500KB），逐个调用writeFile上传片段，最后调用closeFile完成文件合并。这样既避免了单次处理大内存数据导致的阻塞，也降低了单请求的大小限制风险。

• 用Web Worker隔离耗时操作
  将Base64编码、AES-GCM加密这些耗时的操作放到Web Worker中执行，避免阻塞主线程，确保请求能正常触发。

• 调整请求大小限制
  若排查出是后端或中间件的请求体大小限制问题，修改对应配置（如Nginx的client_max_body_size设为2M或更大）；前端确认请求头的Content-Length是否正确计算并设置。

• 修复未捕获异常
  根据错误捕获得到的信息针对性修复，比如加密时的密钥/IV长度错误、内存溢出导致的崩溃等。

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