AWS Amplify Storage 在 Next.js 服务端渲染中的 XMLHttpRequest 问题解析

问题背景

在使用 AWS Amplify Storage 模块的 getUrl 方法时，如果启用了 validateObjectExistence 选项，在 Next.js 的服务端渲染环境中可能会遇到 "ReferenceError: XMLHttpRequest is not defined" 的错误。这个问题特别出现在 Next.js 的 Edge Runtime 环境中。

技术原理分析

AWS Amplify Storage 模块在设计上为了支持更好的上传进度跟踪功能，在浏览器环境中会优先使用 XMLHttpRequest (XHR) 而不是 Fetch API。这种设计选择在客户端环境中是完全合理的，因为 XHR 提供了更细粒度的进度控制。

然而，在服务端环境中，特别是 Node.js 运行时，XMLHttpRequest 并不是原生可用的 API。当 Storage 模块被配置为验证对象存在性（validateObjectExistence: true）时，它会尝试发起一个 HTTP 请求来确认对象是否存在，这时就会触发 XHR 的使用。

问题复现场景

这个问题在以下配置组合下会出现：

1. 使用 Next.js 应用
2. 在 API 路由或页面中使用了 Amplify Storage 的 getUrl 方法
3. 启用了 validateObjectExistence 选项
4. 运行在 Edge Runtime 环境中

特别值得注意的是，Next.js 在构建 Edge Runtime 的 bundle 时会使用 "browser" 字段的配置，这会导致 Storage 模块选择 XHR 实现而非服务端友好的 HTTP 客户端。

解决方案

针对这个问题，开发者可以采取以下几种解决方案：

1. 避免在 Edge Runtime 中使用 Storage API： AWS Amplify 官方文档明确指出 Storage API 不支持 Next.js 的 Edge Runtime 环境。开发者应确保相关代码运行在标准的 Node.js 运行时中。

2. 禁用对象存在性验证： 如果业务场景允许，可以将 validateObjectExistence 选项设置为 false，这样就不会触发额外的 HTTP 请求验证。

3. 自定义 HTTP 客户端： 高级开发者可以通过配置自定义的 HTTP 客户端实现，替换默认的 XHR 实现，使其适应服务端环境。

最佳实践建议

对于需要在 Next.js 中使用 AWS Amplify Storage 的开发者，建议遵循以下最佳实践：

1. 明确区分客户端和服务端代码
2. 对于服务端操作，考虑使用 AWS SDK 直接与 S3 交互
3. 仔细评估是否需要对象存在性验证
4. 避免在 Edge Runtime 中使用 Storage 相关功能

总结

这个问题揭示了在跨环境（浏览器/服务端）JavaScript 开发中的一个常见挑战 - API 兼容性。AWS Amplify Storage 模块主要设计用于客户端环境，在服务端使用时需要特别注意其实现细节和限制。开发者应当充分理解所使用的工具在不同环境下的行为差异，才能构建出稳定可靠的应用程序。