解决OpenNext项目在AWS部署中二进制数据编码问题

问题背景

在OpenNext项目中使用NextJS的rewrite功能进行AWS部署时，开发人员遇到了二进制数据编码错误的问题。具体表现为通过rewrite获取的图片文件在本地开发环境可以正常显示，但在AWS云部署后会出现文件损坏现象。这个问题主要影响图片等二进制资源的正确传输。

问题复现与分析

通过对比测试可以清晰地观察到问题现象：

1. 直接从源服务器获取的原始图片文件大小为6.9KB
2. 本地开发环境通过rewrite获取的图片文件同样为6.9KB且MD5校验一致
3. 但在AWS云部署环境中获取的图片文件膨胀至12KB，且MD5校验不一致

通过十六进制分析发现，云环境中获取的文件头部被插入了EF BF BD字节序列，这是UTF-8编码中表示"替换字符"的字节序列，表明在传输过程中发生了编码转换错误。

临时解决方案探索

开发团队尝试了两种临时解决方案：

方案一：启用Lambda流式传输

通过配置open-next.config.ts启用AWS Lambda流式传输功能：

export default {
  default: {
    override: {
      wrapper: "aws-lambda-streaming"
    }
  }
}

此方案虽然解决了二进制数据损坏问题，但带来了两个新问题：

1. 所有响应内容类型被强制设置为application/json
2. 传输性能显著下降（1.3MB的JPEG文件需要8秒）

方案二：显式设置内容类型

通过在中间件中显式设置正确的内容类型头：

if (pathname.endsWith("ct_fixed")) {
  request.headers.set("Content-Type", "image/png");
}

这种方法解决了二进制数据损坏问题且不影响性能，但需要为每种文件类型手动设置内容类型，不够优雅。

根本解决方案

项目维护团队提出了一个更彻底的解决方案，通过修改OpenNext的AWS适配器代码，正确处理二进制数据的传输。该方案已经通过Pull Request提交，测试表明可以完美解决原始问题。

对于使用SST框架的项目，需要通过以下方式应用修复：

new sst.aws.Nextjs('MyWeb', {
  buildCommand: 'pnpx https://pkg.pr.new/@opennextjs/aws@698 build',
});

技术要点总结

1. 二进制数据传输：在Web应用中正确处理二进制数据（如图片）需要确保传输过程中不发生编码转换。

2. 内容类型头的重要性：正确的内容类型头不仅影响浏览器行为，在某些框架中还会影响数据的传输编码方式。

3. 云环境差异：本地开发环境与云部署环境在请求处理流程上可能存在差异，需要特别注意。

4. 流式传输权衡：虽然流式传输可以解决某些问题，但需要权衡其对性能和功能的影响。

这个问题及其解决方案为开发者在类似场景下处理二进制数据传输提供了有价值的参考。