您可以使用service_url创建指向您资源的直接链接。

我们在项目中不使用Rails视图，因此我对视图层的了解是生锈的。我认为您可以将其放在专用的帮助器中，然后从您的角度使用它。

经过几天的推理和测试，我对最终的解决方案感到非常兴奋，下面将对此进行解释。这是一种自以为是的图像处理方法，可能无法代表当前的Rails Way™️，但是对于提供许多公共图像的网站而言，它具有不可思议的优势，尤其是：

1. 当您为包含N张图片的网页提供服务时，您不会收到对应用服务器的1个+ N个请求，相反，您对该网页只收到1个请求
2. 通过CDN提供图像，这可以缩短加载时间
3. 存储桶不是完全公开的，而是受Cloudflare保护的
4. Cloudflare缓存了图像，这大大减少了您的S3账单
5. 您将API请求（即存在）的数量大大减少到S3
6. 此解决方案不需要对Rails进行大的更改，因此在出现问题时可以直接切换回Rails的默认行为

这是解决方案：

1. 创建一个s3存储桶并将其配置为host a public website（即称为storage.example.com）-您甚至可以在存储桶级别禁用公共访问，并使用存储桶策略仅允许访问Cloudflare ips
2. 转到Cloudflare并为storage.example.com配置指向您的域的CNAME；您需要使用弹性SSL（您可以将页面规则用于子域）；使用页面规则来设置高速缓存：设置“全部缓存”，并为浏览器缓存TTL和边缘缓存TTL设置一个非常长的值（例如1年）
3. 在您的Rails应用程序中，您可以继续使用私有存储/ acl，这是默认的Rails行为
4. 每次@post.variant(...).processed更新或创建后，在Rails应用程序中调用@post；然后在您的视图中使用'https://storage.example.com/' + @post.variant(...).key'（请注意，在这里我们不会在视图中调用processed，以避免在s3中进行其他检查）；如果需要重新生成变体，还可以有一个rake任务，在每个对象上调用processed；如果您很少更改一些变体（例如，每个帖子1张图片/变体），则此方法非常理想

以上大多数步骤都是可选步骤，因此您可以根据需要将它们组合在一起。