必须启动本地http服务，因muffet默认仅处理http://和https://协议，直接扫描file://会跳过所有相对链接；需用python -m http.server 8000等启动服务，并确保html使用相对路径、加--timeout 5和--max-connections 20参数，配合--exclude过滤非html资源。
用 muffet 扫描本地 HTML 前必须起 HTTP 服务
muffet 默认只处理 http:// 和 https:// 协议，直接扫描 file:// 路径会静默跳过所有相对链接——你看到的“0 links checked”不是工具没运行，而是它根本没识别出那些 ./assets/js/main.js 或 ../blog/post.html 是有效链接。
正确做法是先启动本地服务：
-
python -m http.server 8000（Python 3）或php -S localhost:8000（PHP 内置服务器） - 确保 HTML 中的路径是相对路径（如
href="about.html"），而非以/开头的绝对路径（/about.html在本地服务下会解析成http://localhost:8000/about.html，但若项目不在网站根目录，就会 404） - 扫描命令加
--timeout 5和--max-connections 20，避免因本地文件响应慢被误判为超时 - 用
--exclude ".*\.(png|jpg|gif|svg|pdf)$"过滤静态资源，聚焦 HTML、CSS、JS 的链接有效性
如果报 connection refused，第一反应不是换工具，而是检查 localhost:8000 能否在浏览器打开；如果大量 404 但路径看起来没错，大概率是模板里混用了 /xxx 绝对路径。
离线跑 Python 脚本检查相对链接是否存在
适合 CI 流程、无网络环境或不想暴露未上线页面的场景。核心逻辑不是发 HTTP 请求，而是用文件系统验证路径是否真实存在。
关键点：
- 把 HTML 文件所在目录作为基准，用
pathlib.Path(html_path).parent / url拼出目标路径 - 跳过以
http://、https://、//开头的 URL（这些留给线上扫描） - 拒绝回退层级超出项目根目录的路径，比如
src="../../../bad.png"—— 这种应视为无效，不能靠os.path.normpath强行归一化 - 注意 Windows 路径分隔符兼容性，统一用
Path对象操作，别拼字符串
示例判断逻辑：
target = html.parent / url
if not target.is_absolute() and target.exists() and target.is_file():
pass # 链接有效
else:
print(f"MISSING: {url} (from {html.name})")
Linkinator 和 HTML-Proofer 怎么选
两者都能递归扫描，但定位不同：
-
linkinator专注 HTTP 层验证：支持重定向跟随、状态码分析、CSS @import 检查，适合已部署或可访问的站点；需 Node.js 环境，npx linkinator https://yoursite.com即用 -
htmlproofer专注文件层 + HTTP 混合验证：能扫本地生成的_site/目录，自动处理 Jekyll/Hugo 的 baseurl，也支持--check-html检查语法错误；需 Ruby 环境，htmlproofer ./_site --allow-hash-href - 都支持忽略特定 URL：
linkinator用--skip，htmlproofer用--only-4xx或--ignore-url - CI 中若要快速失败，
htmlproofer的--log-level :error更易集成；linkinator的 JSON 输出更适合后续做聚合分析
修复死链时最容易被忽略的三件事
修完链接不等于问题结束：
- 改了
href="old-page.html"→"new-page.html"，但没同步更新<base href="/">或 JS 动态拼接的路径，结果新页里所有相对链接全乱 - 用 301 重定向修复旧 URL，但没在 Google Search Console 提交新的 sitemap，搜索引擎仍缓存着旧的 404 状态
- 修复的是内部链接，却忘了检查外部引用——比如友链、媒体稿件、SEO 外链，这些不会出现在 muffet/linkinator 报告里，得靠 Ahrefs 或 Semrush 反向链接报告补漏
真正耗时间的从来不是发现死链，而是确认每个 404 是该删、该重定向、还是该返回 410 Gone；而最常被跳过的动作，是验证修复后的真实请求 URL——打开 Chrome Network 面板，筛选 Doc，看点击链接发出的到底是哪个地址，状态码是多少。这才是最终判决。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
