Cloud Run部署的Django上传800MB文件到Google Storage无需手动分片的方案

方案1：调整平台及服务配置（无需修改业务代码） #

该方案可以直接复用你现有业务逻辑，不需要手动实现分片上传：

• 调整Cloud Run请求体上限：Cloud Run默认请求体最大为32MB，这是你收到413错误的核心原因。你可以将上限调整到最高1024MiB，刚好满足800MB文件的传输需求，执行命令：
  gcloud run services update <你的服务名称> --max-request-size=1024Mi
  也可以在Cloud Run控制台的修订版配置页面，在「网络」选项下手动修改请求大小上限。
• 调整Cloud Run临时磁盘容量：你的FILE_UPLOAD_MAX_MEMORY_SIZE配置为25MB，超过该大小的文件会被Django自动写入本地临时目录（默认/tmp）缓存，Cloud Run默认临时磁盘仅512MB，不足以缓存800MB文件，需要调大：
  gcloud run services update <你的服务名称> --ephemeral-storage=2Gi
  建议至少预留1.5倍最大文件体积的缓存空间，同时可以根据实际情况适当上调服务内存配置避免OOM。
• 确认daphne启动参数：daphne本身默认也有请求体大小限制，启动时添加参数放开限制即可：
  daphne -b 0.0.0.0 -p 8080 --http-body-size 1073741824 你的项目名.asgi:application
  上述参数将请求体上限设为1GB，适配你的需求。

完成以上配置后，你现有的GS_BLOB_CHUNK_SIZE配置已经可以让django-storages自动将缓存的大文件分片上传到GCS，不需要额外开发分片逻辑。

方案2：GCS签名URL直传（更优的长期方案） #

如果你不想调整请求体限制，或者后续可能有更大的文件上传需求，可以采用直传方案，整个流程不需要Cloud Run转发文件流：

• 调用方先请求你的Django接口，申请上传权限
• Django接口校验权限后，调用GCS SDK生成带过期时间的签名上传URL返回给调用方
• 调用方直接将文件上传到该签名URL，传输过程完全走GCS的链路，不需要经过你的Cloud Run服务
• 上传完成后调用方再回调你的Django接口，通知上传完成、执行后续业务逻辑

这个方案完全规避了大文件传输带来的413问题、磁盘/内存占用问题，传输稳定性更高，也能降低Cloud Run的资源消耗。

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