我有两台服务器（均可公开访问）。第一个是图像存储服务器。第二个生成链接（在node.js中编写的小脚本），指向图像存储服务器上的图像。
我有一个需要从图像存储服务器加载照片的前端网页。为此，需要联系“链接生成”服务器以获取链接。
我有三种方法可以做到这一点：
将图片ID数据存储在data-src标记中，作为<img>而非src标记的一部分，以便浏览器不会尝试将其作为图片加载。然后让一些javascript函数使用图像ID ping链接生成服务器，检索实际图像链接，然后将其放在src标记中。
使链接生成服务器重定向到相应的图像链接，而不是将链接作为文本返回，因此带有图像ID的图像生成服务器的链接可以放在src标记和浏览器中将通过重定向解析图像。 （我假设图像可以通过重定向解决？）
将链接生成服务器变为反向代理，该代理将加载生成的图像本身，然后将图像传回，而不是将链接作为文本返回。同样，带有图像ID的图像生成服务器的链接将放在src标记中，并且不需要特殊的JavaScript来解析图像。
我的问题是：在图像加载速度和“缓存能力”方面，这些中的任何一个都比另一个更令人满意吗？到目前为止，我发现重定向方法更加可取，因为它很干净，不需要任何特殊的javascript。但是使用这样的方法（如果它甚至可以工作），最终的图像是否无法在浏览器中缓存以便随后重新加载页面，因为浏览器将始终解析重定向以实际获得最终的图像链接？ / p>
非常感谢！
答案 0 :(得分：0)
由于您可能已经控制了图像服务器和链接生成器，因此我建议将它们组合到一个Web服务中。本质上，与选项＃3一样，无论是使用反向代理，还是将两个服务器应用程序组合到一个应用程序中，这可能会更高效（每个图像加载一个HTTP请求减少一个）。在我看来，这是一个更优雅的解决方案，可以创建一个简单的图像Web服务，而不会在客户端/浏览器中涉及重定向和多个HTTP请求。
关于图像src URL，是的，它们可以通过重定向来解析，如果缓存头是正确的，浏览器将缓存重定向URL的图像。 301重定向也可以缓存，具有正确的缓存头。同样，这种方法似乎更复杂的服务，但最终可能需要业务成本。
总之，我会一起远离＃1，因为它会在客户端上正确使用图像服务。无论你选择＃2还是＃3，都应该取决于选择其中一个的直接开发成本和长期维护成本。