Firebase Dynamic Links生成的图片短链无法在img标签加载

核心原因是创建动态链接时开启了enableForcedRedirect: true配置，该配置触发的Firebase Dynamic Links（以下简称FDL）跳转逻辑，和<img>标签的资源加载规则完全不兼容：

• 开启强制跳转后，FDL不会返回标准3xx系列HTTP重定向响应，而是先返回状态码200、Content-Type为text/html的中间跳转页，靠页面内置的JS脚本、meta刷新标签实现跳转、移动端App唤起逻辑。
• 直接把短链粘贴到浏览器地址栏访问时，浏览器会完整加载中间页、执行JS、解析meta跳转规则，最终跳转到目标图片地址，因此可以正常加载显示。
• 但浏览器加载<img>标签的src资源时，不会执行响应内的任何JS脚本，也不会处理meta刷新逻辑，仅会自动跟随标准3xx HTTP重定向拉取资源。FDL返回的HTML中间页和预期的图片资源类型不匹配，浏览器会直接判定资源加载失败。

测试中bit.ly短链可以正常加载，是因为这类通用短链服务默认返回301/302状态的标准HTTP重定向，<img>标签加载时浏览器可以正常跟随重定向拿到最终图片资源，不存在逻辑冲突。

需要明确：FDL的强制跳转能力本身是为了解决移动端App Universal Link/App Links唤起失效的问题设计的，产品定位是服务于页面跳转、App唤起、流量归因，并非面向静态资源直链场景设计。

根据实际业务场景选择对应方案即可：

• 方案一（无特殊App唤起需求时首选）：创建动态链接时将navigationInfo.enableForcedRedirect字段设为false，关闭强制跳转后，FDL会对浏览器请求返回标准3xx重定向响应，<img>标签可正常跟随重定向加载图片。
• 方案二（长期稳定性最优）：不要用FDL承载静态图片的短链需求。FDL作为深度链接服务，中间跳转层会额外增加资源加载耗时，还存在各类边缘场景兼容问题；纯静态资源短链需求用通用短链服务、CDN自带的URL改写能力即可，稳定性更高、加载速度更快。
• 方案三（必须保留强制跳转能力时使用）：在自有服务端加一层代理逻辑，由服务端请求FDL链接解析出最终的真实图片地址，前端<img>标签直接引用自有服务的代理接口地址。该方案会额外增加服务端带宽与计算开销，非必要不采用。

内容的提问来源于stack exchange，提问作者D V Ramana