外链图片加速合作方更换域名时怎样核对迁移对应关系

📍 WDQWDWQD987AAAAA:216.73.217.34
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /00506ac013da.html
📄

外链图片加速合作方更换域名时怎样核对迁移对应关系

结论先说：如果合作方只是把图片域名整体替换，旧链接通过 301 跳到新域名，那么核对重点是“旧图到新图的对应关系”是否一一成立；但如果对方把图片重新压缩、改名或换了目录结构，301 只能保证页面可达，不能保证你引用的那张图还是原来那张，这时必须逐条比对文件本身。下面给出可执行的核对顺序，以及一个会让整套方法失效的反例。

先确认迁移类型，再决定核对粒度

合作方换域名通常有三种形态，核对成本差别很大：

判断属于哪一种，最直接的动作是抽取一批旧图片 URL，用 curl -I 看返回的状态码和 Location 头。如果返回 301 且 Location 指向的新地址与旧地址仅域名不同，基本可归入第一种；如果 Location 指向一个哈希文件名，就落入第三种。这个动作的结果直接决定下一步：前两种可以批量脚本核对，第三种必须人工或图像比对。

核对对应关系时，真正要比的是四个字段

很多人只检查“链接是否还能打开”，这不够。图片迁移后即使能打开，也可能指向了另一张图。建议对每条外链记录以下四项：

  1. HTTP 状态与跳转链：确认没有跳转到首页、404 页或登录页。跳转到首页是常见的“假成功”，浏览器里能看到内容，但图片已经不在了。
  2. Content-Type：确认返回的是 image/*，而不是 text/html。后者说明服务器用错误页顶替了图片。
  3. Content-Length 或图像尺寸：同一张图迁移后大小可以有轻微差异，但如果差异明显，说明被重新压缩或替换了内容。
  4. 内容哈希：对图片文件计算哈希，是判断“是不是同一张图”最可靠的方式。前提是对方没有做无损重编码。

假设你有一批合作方提供的图片外链，迁移前记录了每张图的 SHA-256。迁移后抓取新地址并重新计算哈希：哈希一致，说明文件未变，可以放心保留原引用；哈希不一致但尺寸接近，可能是重新编码，需要肉眼确认；哈希不一致且尺寸差异大，应视为换图，重新评估这条外链是否还符合你的引用意图。这里的关键是，哈希只能证明“文件是否相同”，不能证明“这张图在你的页面里是否仍然合适”，后者仍需人工判断。

一个会让上述结论失效的反例

如果合作方采用按请求动态生成图片的架构，同一 URL 每次返回的字节可能不同，例如根据 Accept 头返回 WebP 或 AVIF，或根据参数裁剪尺寸。此时内容哈希天然不稳定，用哈希核对会得出大量“不一致”的假警报。

这种情况下，正确做法是固定请求条件：统一 Accept 头、统一 User-Agent、不带任何裁剪参数，再比较返回的像素尺寸和关键区域。另一个合理替代是比对图片的感知哈希（如 pHash），它对轻微重编码不敏感，但能识别出内容被替换。要说明的是，感知哈希存在碰撞可能，它降低误报的同时也可能漏掉小幅修改，因此只适合作为筛查，不适合作为最终判定。

旧链接暂时无响应，不等于迁移失败

迁移期间出现 404、超时或返回空内容，有多种合理解释：DNS 尚未完全生效、新域名 CDN 缓存未预热、对方在灰度切换、旧域名临时下线但保留回滚能力。这些现象单独出现，不能证明对方处理错误，也不能证明你的核对方法有问题。

可区分的证据是：同一批 URL 中，一部分正常返回、一部分失败，且失败集中在某个路径前缀或某个时间窗口，通常指向局部配置问题；如果全部失败且 DNS 解析异常，更可能是域名层面尚未就绪。此时不要急于删除或替换所有引用，而应保留旧记录，等待一个观察周期后再复测。观察周期多长取决于对方给出的迁移窗口，而不是固定天数。

下一步动作：建立映射表并分批切换

核对完成后，建议先产出一张映射表，字段包括旧 URL、新 URL、状态码、内容是否一致、处理结论。然后按结论分三批处理：

切换后不要立即删除映射表。保留它，可以在对方再次调整域名或路径时复用，也能在出现争议时说明你依据的是哪一次核对结果。整个流程的取舍在于：自动化核对快但可能误判动态图片，人工核对准但成本高，先判断迁移类型再选方法，比默认全量人工或全量脚本都更稳妥。

图1 图2
nginx