AWS SDK for Java v1中TransferManager上传文件时bucketKeyEnabled设置失效问题分析

在AWS SDK for Java v1的使用过程中，开发人员发现了一个关于对象存储加密功能的重要问题。当使用TransferManager进行大文件上传时，如果触发了分片上传机制，对象级别的S3存储桶密钥设置（bucketKeyEnabled）会出现失效的情况。

这个问题主要影响需要同时使用以下两种功能的场景：

1. 使用TransferManager进行大文件上传（超过分片阈值）
2. 需要为单个对象启用S3存储桶密钥加密

经过分析，问题的根源在于TransferManager内部实现时，没有将PutObjectRequest中的bucketKeyEnabled参数正确传递到InitiateMultipartUploadRequest中。具体来说，在UploadCallable类的initiateMultipartUpload方法中，虽然复制了SSE加密参数等配置，但遗漏了bucketKeyEnabled这个重要属性。

这个问题的典型表现是：

• 当上传小文件（未触发分片）时，bucketKeyEnabled设置正常工作
• 当上传大文件（触发分片）时，bucketKeyEnabled设置被忽略
• 无论存储桶级别的bucketKeyEnabled设置如何，对象级别的设置都会失效

对于仍在使用AWS SDK for Java v1的用户，建议的解决方案是：

1. 检查所有使用TransferManager上传大文件的代码
2. 确认这些上传操作是否依赖bucketKeyEnabled设置
3. 考虑迁移到AWS SDK for Java v2，该版本已经修复了这个问题

值得注意的是，AWS官方已经宣布将在2025年底停止对Java SDK v1的支持。对于新项目，强烈建议直接使用v2版本，它不仅修复了这个bug，还提供了更好的性能和更多新特性。对于必须使用v1版本的现有系统，开发人员需要自行处理这个兼容性问题，或者调整业务逻辑以适应这个限制。

从技术实现角度看，这个问题的修复其实很简单 - 只需要在初始化分片上传请求时，将原始请求中的bucketKeyEnabled值复制过去即可。但考虑到v1版本已进入维护期，官方可能不会发布针对这个问题的修复补丁。

这个案例也提醒我们，在使用任何SDK的高级封装方法时，都需要仔细验证所有功能参数是否都能正确传递到底层实现，特别是在涉及安全相关配置时，更需要格外小心。