传统方式： 怎么运行的： 用户将文件上传到应用服务器。 应用服务器将上传的内容保存到临时空间进行处理。 应用程序将文件传输到数据库、文件服务器或对象存储以进行持久存储。
优点和缺点： 虽然该过程很简单，但它可能会对繁忙应用程序中 Web 服务器的性能产生显着的副作用。媒体上传通常很大，因此传输这些内容可能会占用大量网络 I/O 和服务器 CPU 时间。您还必须管理传输状态以确保整个对象成功上传，并管理重试和错误。 这对于具有尖峰流量模式的应用程序来说是一个挑战。例如，在专门发送节日祝福的 Web 应用程序中，它可能仅在节假日期间经历大部分流量。如果成千上万的用户尝试在同一时间上传媒体，则需要您扩展应用程序服务器并确保有足够的网络带宽可用。
与客户端共享信用，以便客户端可以使用aws的sdk直接将文件上传到s3。但这很糟糕，因为 js 可以被提取并且信用可以被泄露。（非常愚蠢的方式，但至少负载不会到达我们的服务器）
无服务器上传： API-网关->lambda 函数（最大 512MB）->s3 优点和缺点：
优点与传统方式相同，只是不会加载到服务器上。 时间限制和内存限制是可配置的，但如果由于流量原因，成本可能会很高，因为 lambda 充电器会影响执行所需的时间以及执行期间消耗的总内存。
API网关->s3 优点和缺点：
了解不多，但 auth/api-key 可以在传出网络调用中看到，并且可以复制，然后我们的磁盘和每个人（未经授权）都在使用它，尽管我们可以通过更改分配的角色策略来限制他们可以执行的操作，但仍然有漏洞太多了
我们可以做的是我们可以拥有自己的服务器，它将生成一个预签名的 URL 并将其提供给客户端，然后客户端可以使用该签名的 URL 上传到 s3，完成后客户端必须再次访问我们自己的服务器将完整的上传内容以及从客户端收到的所有电子标签发送到该上传 ID。
现在用 js 编写的整个代码可以使用任何语言编写，因为该语言存在 aws-sdk。
如果您想要完整的上下文，我可以分享我的代码（因为它不是专有的，我只是缝合了每个小部分（我通过阅读文档或不同的博客从互联网上获得的）以获得完整的解决方案）。已经完成了 k6 负载测试，但仍然
有人解答并消除我的疑虑
您不应该与您的客户共享任何凭证，通过 lambda 上传实际上是在浪费金钱，即使 AWS 很乐意您付费，他们也不会推荐它，因为这是无缘无故的诈骗。
预签名 url 方法是最安全的。该 URL 是一次性的，除了上传之外不提供任何访问权限。 创建预签名 URL 时，将一些标签附加到对象，如 here。
然后，您可以将侦听器附加到 s3 以在上传文件时处理文件。对象标签和/或位置可帮助您在此阶段将上传的文件映射到原始请求。
如果您期望非常高的并发负载，您可以在签名 URL 创建阶段对请求进行排队。