我已经看到很多代码示例/插件促进将资产直接上传到 S3。例如，如果您有一个带有头像的用户对象，则文件上传字段将直接加载到 S3。
我认为这是可能的唯一方法是，如果用户对象已经在数据库中创建并且您的 S3 存储桶 + 路径类似于
user_avatars.domain.com/some/id/partition/medium.jpg
但是，如果您有一个图像标签在未上传头像时尝试访问该 URL，则会产生错误的结果。您将如何处理检查存在性？
此外，对于大多数有许多协会来说，这似乎并不适用。例如，如果用户有很多歌曲/mp3，您将在哪里存储它们以及如何访问它们。
此外，您的验证将被拍摄。
我很难想到直接上传到 S3（或任何云）是一个好主意的情况，并希望人们能够澄清正确的用例，或者告诉我为什么我的逻辑不正确。
为什么要为存储/带宽/备份/等付费。什么时候可以让云中的某个人为您处理？
S3（和其他基于云的存储选项）为您处理所有令人头疼的问题。您可以获得所需的所有存储、良好的分发网络（几乎肯定比您自己拥有的要好，除非您为高级 CDN 付费）和备份。
允许用户直接上传到 S3 可以减轻您的带宽负担。我可以看到跟踪问题，但 S3 可以很容易地处理这种情况。如果您查看直接上传方法，您会发现可以在成功上传时强制重定向。
然后亚马逊会将以下内容传递给重定向处理程序：bucket, key,etag
这应该为您提供成功后跟踪上传资产所需的内容。直接上传让您两全其美。你得到你的跟踪信息，它会卸载你的带宽。
查看此链接了解详细信息：Amazon S3：使用 POST 的基于浏览器的上传
如果您在 Heroku 上托管 Rails 应用程序，原因很可能是 Heroku 不允许上传大于 4MB 的文件：http:
//docs.heroku.com/s3#direct-upload
因此，如果您希望您的用户能够上传大文件，这是唯一的出路。
记住网络服务器是如何工作的。
除非您正在使用一种异步 Web 设置，就像您可以使用 Node.JS 或 Erlang（仅 2 个示例）实现的那样，否则您的 Web 应用程序服务的每个上传请求都会在文件上传时占用整个进程或线程。
想象一下，您正在上传一个有几兆字节的文件。大多数互联网用户没有非常快速的上行链路，因此您的网络服务器花费大量时间无所事事。虽然它什么也没做，但它不能服务任何其他请求。这意味着您的用户开始收到来自服务器的长时间延迟和/或错误响应。这意味着他们开始使用其他网站来完成同样的事情。你总是可以有更多的进程和线程在运行，但是每个都需要额外的内存，这最终意味着额外的 $。
通过直接上传到 S3，除了 Justin Niessner 提到的带宽节省和 Thomas Watson 提到的 Heroku 解决方法之外，您还可以让 Amazon 担心这个问题。您可以让单进程网络服务器有效地处理非常大的上传，因为它将实际功能推给亚马逊。
所以，是的，设置起来更复杂，你必须处理回调来跟踪事情，但是如果你处理的不是非常小的文件（甚至在那些情况下），为什么要花更多的钱呢？
编辑：修正错别字