图片外链优化：合作方更换域名时怎样核对迁移对应关系
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1e8c824406c6.html
📄
图片外链优化：合作方更换域名时怎样核对迁移对应关系
先给结论：合作方换域名后，不要只核对新首页或新文章页是否可访问，而要把“旧图片地址→新图片地址→承载页面”三层对应关系逐条对上。多数遗漏发生在图片文件本身换了目录或文件名，但页面链接只改了栏目路径，于是旧外链指向的图片返回错误或落到无关页面，而你在浏览器里看新站一切正常。
假设情境：一次只换域名、不改内容的迁移
假设合作方把站点从旧域名整体迁到新域名，页面标题、正文和图片内容都保持不变，只是域名变了。对方告诉你“已经做了全站跳转”，你打开新域名首页也能正常显示。此时你手上仍有一批指向旧域名的图片外链，需要判断这些链接迁移后是否还能对应到同一张图、同一个页面。这个情境的关键限制是：内容没变，变的是域名和可能的目录结构，所以核对重点不是内容匹配，而是地址映射是否完整。
第一步：建立三列对照，而不是只看跳转是否生效
把每个待核对的外链拆成三列记录：旧图片直链、该图片所在旧页面、新域名下对应的图片直链与页面。只记录“旧→新域名”是不够的，因为图片外链优化里真正被引用的是图片文件地址，页面只是它的上下文。若对方只把页面做了跳转，图片文件地址没有同步映射，访问旧图片地址时可能返回 404、返回一张占位图，或返回新站首页。后两种最容易被误判为“迁移成功”。
具体动作：随机抽取若干条旧图片直链，逐条请求，记录返回状态和最终落点。若最终落点不是同一张图片所在的页面，而是站点首页或栏目页，就说明映射只做到了域名级，没有做到资源级。这个结果会直接决定下一步：你需要向对方索要图片资源的路径对照表，而不是继续抽查页面。
第二步：区分三类失败，原因不同，处理也不同
核对时把异常归入三类，避免用同一种方式反复沟通：
- 协议或域名层失败：旧地址整体无法解析或跳转链过长。这通常是域名切换配置问题，与图片路径无关。
- 路径层失败：域名能通，但图片目录或文件名变了，旧图片地址返回 404。这需要对方提供旧路径到新路径的映射规则，例如目录整体平移还是按文件重命名。
- 页面层错配：图片能打开，但它所在的页面换了栏目，导致图片外链的上下文与原来不一致。这类问题不会报错，只能靠人工比对页面归属。
三类中，路径层失败最常被“全站跳转已生效”这句话掩盖。因为跳转通常配置在页面级，图片作为独立资源被请求时不经过同一套规则。
第三步：用可区分的证据判断映射是否真的完整
不要依赖“访问正常”这一条证据。可以同时看三组信号：旧图片地址的返回状态、最终落点地址、以及落点页面上图片的原始地址。如果三者能拼成一条完整链路，说明映射成立；如果最终落点地址与旧页面主题明显不符，或落点页面上图片地址与旧图片地址无规律对应，就说明映射是拼凑的。
这里要注意一个常见误判：某项请求量或抓取量在迁移后归零，不能单独证明对方处理错误。它也可能是统计口径切换、缓存未更新、或抓取节奏本身变化造成的。把统计归零当作唯一证据，容易把配置问题和统计问题混在一起，导致沟通方向跑偏。
第四步：要求对方给出映射规则，而不是逐条修补
如果抽样中路径层失败反复出现，正确动作是要求对方提供一条可验证的映射规则，例如“旧目录 /img/a/ 整体对应新目录 /assets/a/，文件名不变”。拿到规则后，你可以自行推导若干条旧地址的新地址，再实际请求验证。若规则成立，剩余核对可以批量推导；若规则不成立，说明对方是手工挑了几个页面处理，此时继续逐条核对成本会很高，应改为要求补齐资源级跳转或重新发布图片地址。
这个动作的结果会改变你的后续策略：规则可验证，就转入批量抽查；规则不可验证，就应暂停把新地址写入正式引用，避免把一批不稳定地址固化到页面里。
核对完成后仍需保留旧地址记录
即使新地址验证通过，也建议保留旧图片地址与对应页面的记录。合作方后续若再次调整目录，旧记录是判断“这次变化影响了哪些引用”的唯一依据。图片外链优化在这一步的取舍是：不追求一次性把所有引用换成新地址，而是确保每条引用都能追溯回它的来源页面和原始图片，这样下一次迁移核对才有起点。
