通过API Gateway向AWS Lambda传递CSV文件的最优方案及现有隐患

• Payload上限触达风险：API Gateway的HTTP API最大请求Payload为6MB、REST API为10MB，你当前5MB的CSV转成JSON字符串后，因为CSV中的换行、引号、特殊字符需要转义，体积会额外膨胀10%-50%，很容易超过API Gateway的Payload限制，直接返回413请求过大错误。
• 不必要的性能损耗：客户端侧需要把CSV文件序列化为JSON字符串、Lambda侧需要把字符串反序列化为可处理的CSV结构，两次额外的编解码会占用CPU和内存资源，拉长Lambda执行时长，增加不必要的成本。
• 编码兼容性问题：如果CSV文件包含非UTF-8编码的内容，转JSON字符串时很容易出现乱码，导致数据丢失或处理失败。
• 数据安全隐患：如果开启了API Gateway全请求日志、Lambda入参打印，CSV文件中的敏感数据会直接明文存储在日志中，有合规风险。

API Gateway和Lambda之间的调用是跨网络的序列化调用，没有原生的字节流传输上下文，Lambda收到的入参本身是API Gateway序列化后的JSON格式数据，不可能直接映射为编程语言里的InputStream对象，所以直接把入参模型的fileData定义为InputStream会直接反序列化失败。

方案1：适配现有架构调整（适合文件大小<=6MB的场景） #

1. 如果你想保留JSON请求结构：把fileData字段的内容从原始CSV字符串改为CSV二进制的Base64编码字符串，Lambda侧拿到后直接解码为字节数组，再封装为InputStream即可，示例Java代码如下：

   // 从event中拿到base64编码的文件内容
   String base64FileData = (String) event.get("fileData");
   // 解码转InputStream
   InputStream fileInputStream = new ByteArrayInputStream(Base64.getDecoder().decode(base64FileData));
   

   该方式比存原始CSV字符串的转义问题少，Base64的体积膨胀率固定为33%，更容易预估请求大小。
2. 如果你想进一步降低体积：在API Gateway开启二进制支持，将text/csv加入二进制媒体类型列表，请求改用multipart/form-data格式提交，元数据作为表单字段、CSV作为二进制文件字段上传，Lambda侧直接解码请求体即可拿到InputStream，额外体积开销几乎为0。

方案2：S3预签名URL模式（推荐所有场景长期使用） #

该方案完全规避API Gateway的Payload限制，且天然支持InputStream能力：

• 客户端先调用API接口上传所有元数据，接口内部调用S3生成有效期几分钟的预签名上传URL返回给客户端
• 客户端直接把CSV文件上传到该S3预签名URL，不需要走API Gateway
• 上传完成后可以配置S3的对象创建事件自动触发Lambda处理，Lambda直接从S3拉取文件，就能拿到原生的InputStream对象
  该方案还具备支持超大文件、无编码问题、日志不会泄露文件内容、支持断点续传等优势。

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