商品详情页失效链接90%源于HTML路径拼错、相对路径未适配嵌套层级或JS动态生成URL漏根路径；应直接用Chrome Network面板抓取标红404请求，确认Request URL与Status，再针对性修复路径或配置。
商品详情页的失效链接，90% 不是 CDN 或广告平台的问题，而是 HTML 里路径拼错、相对路径没适配嵌套层级、或 JS 动态生成 URL 时漏了根路径前缀。直接看 Chrome Network 面板里标红的 404 请求，比任何扫描工具都快、准、可验证。
用 Chrome Network 面板实时抓出真实 404 请求
这是最可靠的第一步，不依赖工具、不误报、不漏报，尤其适合带参数或 JS 跳转的商品链接（如 href="product?id=123" 或 location.href = "buy?sku=" + sku）。
- 必须用本地 HTTP 服务访问页面（如
http://localhost:8080/product.html），file://协议下 Network 不发请求，根本看不到 - 按 F12 → 切到 Network → 勾选 Preserve log → 刷新页面
- 点击商品页上的“加入购物车”“查看视频”“跳转规格表”等关键链接，立刻扫一眼标红条目
- 重点看三列：
Name（是否为video.mp4或spec.json）、Status（是不是 404）、Initiator（是否指向你写的<script></script>行号或onclick属性） - 右键红条 →
Copy → Copy link address，粘贴出来看浏览器最终解析的完整 URL —— 这个才是你要对齐的目标路径
修复 href/src 中的相对路径陷阱
商品页常放在多级目录下（如 /products/electronics/phone-123.html），此时写 href="detail.html" 或 src="images/spec.png" 会被自动补成同级路径，而非你预期的根路径或资源目录。
- 要跳转到站点根目录？开头加斜杠：
href="/detail.html"、src="/assets/images/spec.png" - JS 动态拼接更稳妥：
new URL("video.mp4", window.location).href，它会按当前页面上下文自动解析，避免手误 - 别依赖
./前缀：旧版 Webpack Dev Server、某些静态托管平台（如 GitHub Pages）会忽略它，行为不统一 - 检查
<base href="/>%20%E6%98%AF%E5%90%A6%E7%BC%BA%E5%A4%B1%E6%88%96%E9%94%99%E8%AF%AF%EF%BC%9A%E8%8B%A5%E9%A1%B5%E9%9D%A2%E7%94%A8%E4%BA%86%20<base%20href=">，所有相对路径都会被强制拼在该前缀下，极易导致src="video.mp4"实际请求/products/video.mp4
处理 JS 动态生成的失效链接
商品页大量依赖 JS 渲染跳转逻辑（如 “选择颜色后跳转对应 SKU 详情”），这类链接不会出现在原始 HTML 的 href 中，Network 里却可能报 404 —— 因为拼接逻辑错了。
立即学习“前端免费学习笔记（深入）”；
- 在控制台执行
console.log(location.href)或打断点，确认 JS 执行时skuId、color等变量是否有值、是否为空字符串或未定义 - 检查拼接方式：
location.href = "item?sku=" + sku在/products/下会跳到/products/item?sku=...，应改为location.href = "/item?sku=" + sku - 留意 URL 编码问题：若
sku含特殊字符（如ABC#123），直接拼接会导致截断，需用encodeURIComponent(sku) - 广告位或第三方组件（如评论插件、视频 SDK）常通过
data-src或自定义属性加载资源，Network 里看到的 404 可能来自它们的内部逻辑，需查其文档是否要求配置baseURL或cdnHost
区分真 404 和软 404，避免白改
有些服务器把本该返回 404 的路径，错误地返回 200 OK + 一段“页面未找到”的 HTML。Network 里看着没红，但搜索引擎和用户都当它失效了 —— 这类问题 HTML 改了也没用，得动服务端。
- 点开那个看似正常的请求（比如
spec.json）→ 左侧 Headers 标签 → 查Response Headers区域里的Status行 - 如果显示
HTTP/1.1 200 OK，哪怕内容是空或“Not Found”，它也是软 404 - 图片类资源还要注意：某些 CDN 或 Nginx 对
HEAD请求返回 404、只对GET返回 200，htmlproofer 默认发 HEAD 就会误报；此时应人工用curl -I测，或改用浏览器发起 GET 请求验证 - 后端路由拦截前端跳转（如 Express 把
/product/123当 API 处理了）也会导致软 404，看响应头Content-Type是application/json还是text/html就能快速判断
真正难处理的不是找不到错在哪，而是链接背后混着 JS 动态逻辑、CDN 配置、服务端重定向和前端路由四层机制——Network 里一个红条，可能横跨三个技术栈。盯住 Request URL 和 Status，比猜代码更省时间。
