云环境Spring Boot Webflux Multipart上传超时（已解决：负载均衡）及方案咨询

问题根源 #

已确认负载均衡是导致部署到GCP后图片上传超时的核心原因，本地环境无相关限制因此运行正常。

上传方案合理性说明 #

使用multipart/form-data是文件上传的标准且合适的方案，无需改为直接传递ByteArray。客户端通过表单上传文件是常规可靠的方式，你提供的Postman生成的curl请求格式完全正确：

curl --location 'protocol://some-location/properties/967275918/images' \
--form 'image=@"C:/Users/MyUser/Pictures/testimage.jpg"'

Webflux代码优化建议 #

你的代码存在逻辑漏洞：调用image.next()消费了Flux中的第一个Part后，再次使用image.flatMap(Part::content)会丢失第一个Part的内容，这可能在云环境中加剧超时问题（后端服务因等待完整数据一直挂起）。优化后的代码如下：

@RequestMapping(
        method = RequestMethod.POST,
        value = "/properties/{property-id}/images",
        consumes = ["multipart/form-data"]
)
fun uploadPropertyImage(propertyId: String, image: Flux<Part>, exchange: ServerWebExchange) : Mono<ResponseEntity<Void>> {
    return image.next()
            .flatMap { firstPart ->
                val mediaType = firstPart.headers().contentType!!
                // 保留第一个Part的内容，再拼接后续Part的内容
                val allContents = firstPart.content().concatWith(image.flatMap(Part::content))

                DataBufferUtils
                    .join(allContents)
                    .flatMap { dataBuffer ->
                        // 正确读取字节数组并释放缓冲区
                        val imageAsByteArray = ByteArray(dataBuffer.readableByteCount())
                        dataBuffer.read(imageAsByteArray)
                        DataBufferUtils.release(dataBuffer)

                        propertyApiAdapter.uploadImage(propertyId, imageAsByteArray, mediaType)
                            .map { ResponseEntity.ok().build() }
                    }
            }
}

优化细节： #

• 避免Flux元素重复消费：先获取第一个Part后，直接读取其内容再拼接后续Part，确保所有上传数据被完整读取。
• 手动释放DataBuffer：Webflux中需手动释放缓冲区，避免云环境高并发场景下出现内存泄漏。
• 标准字节数组读取：替换自定义的imageAsByteArray()为标准API，保证兼容性。

额外注意事项 #

后续若遇到大文件上传问题，需检查Cloudflare的文件大小限制与超时配置；同时要确保GCP负载均衡的超时时间匹配文件上传的预期耗时。

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