企业官网建设流程全解析

如何打造自动化链接检测器：no-cost-ai的GitHub Actions实现原理深度解析

【免费下载链接】no-cost-ai80+ free AI services for chat, image, video, voice & APIs (may sometimes include access to lead gen ai models for free)项目地址: https://gitcode.com/gh_mirrors/no/no-cost-ai

no-cost-ai是一个收录 80+ 免费 AI 服务的开源索引项目，覆盖免费 AI 聊天、AI 绘图、AI 语音与开发者 API。由于免费 AI 服务失效极快，该项目用 GitHub Actions 打造了一个自动化链接检测器，每天自动巡检所有链接并把死链变成 Issue。本文深度解析这套检测器的实现原理，帮你看懂它是如何做到"零人工维护链接有效性"的 🛠️

为什么免费 AI 资源库离不开链接检测器

no-cost-ai 的价值在于把散落各处的免费 AI 服务汇总到一张表里（见 README.md）。但这类项目有一个天然痛点：

• 免费服务说停就停，域名经常迁移
• 链接失效后没人发现，读者信任度迅速下降
• 人工逐个点开验证 80+ 链接，根本不现实

所以项目选择让GitHub Actions 工作流每天自动巡检，把"人工检查"变成"机器报告"。工作流定义在 .github/workflows/link-checker.yml。

三种触发方式：让检测器每天 9 点自动巡检

在 link-checker.yml 第 3-11 行 中，工作流配置了三种触发时机：

💡 这是新手最容易照搬的设计：定时兜底 + 变更触发。既保证日常巡检，又能在你更新服务列表后立刻验证新链接。

on: schedule: - cron: '0 9 * * *' # 每天 9 点自动跑 workflow_dispatch: # 允许手动触发

检测流水线：从提取链接到生成报告

核心检测逻辑在工作流的run步骤中以内联脚本生成（第 29-248 行），整个流程分四步：

第 1 步：提取并去重 README 中的外部链接

脚本先读取 README.md，用markdown-link-extractor抽出全部 Markdown 链接，再过滤出http://和https://开头的外部链接，并用 Set 去重（第 145-152 行）。内部锚点、mailto 一律跳过。

第 2 步：轮换 UA 模拟真实浏览器访问

很多站点会对"机器人特征"的请求返回 403，从而造成误判。检测器预置了 4 种真实浏览器的 User-Agent（Chrome / Firefox / Safari，第 49-55 行），每次重试轮换一个，并携带完整的浏览器请求头（Accept、Sec-Fetch-* 等），让请求"看起来像人"。

其他关键参数：

• 20 秒超时：避免单个慢站拖垮整个流程
• 最多跟随 10 次重定向：覆盖多层跳转的站点
• 每次重试间隔 3 秒：给临时故障恢复的机会
• 相邻请求间隔 1 秒（第 167-170 行）：礼貌限速，不"轰炸"对方服务器

第 3 步：四类结果分桶，精准定位问题

检测结果不是简单的"成功/失败"，而是分成四个桶（第 41-56 行）：

1. ✅正常—— 能收到响应
2. ❌不可达/损坏—— DNS 失败、拒绝连接等，需要处理
3. ⏱️超时—— 可能是临时网络波动，仅作警告
4. 🔄重定向循环—— 跳转死循环，仅作警告

只有第 2 类会被当作关键问题触发后续报障，其余降级为警告，避免误报刷屏。

第 4 步：生成 JSON 报告并存档

每次运行都会产出link-check-report.json（含时间戳、统计摘要、每个链接的详细状态），并通过actions/upload-artifact上传为构建产物（第 250-254 行），随时可以下载复查 📊

智能判定：为什么 403 / 500 不算死链

这是整套检测器最"反直觉"、也最值得学习的部分（第 87-90 行）：

• 只要服务器有响应（2xx~5xx），就认为链接"活着"。因为 403 可能是反爬策略，500 可能是服务端故障，都不代表站点下线
• 响应头过大也被判为存活：部分站点返回的 header 超出解析器限制（HPE_HEADER_OVERFLOW），检测器专门捕获该错误，记为"可达但 header 超限"（第 58-61 行、112-121 行）

核心思想：区分"服务器死了"和"服务器在挑人"。只有完全无法建立连接的链接才值得报警，这样 Issue 的数量保持在最低限度，每条都值得处理。

死链自动变 Issue：不重复、可追溯

当发现不可达链接时（broken_count > 0），工作流通过actions/github-script自动处理（第 256-335 行）：

1. 查找已有 Issue：先查询带broken-links标签、标题含 "Broken Links Detected" 的未关闭 Issue
2. 存在则追加评论：把最新检测报告以评论形式更新到旧 Issue
3. 不存在则新建 Issue：附上完整统计摘要 + 每个死链的错误码与状态

这套"查重 → 复用"逻辑保证了一个仓库里始终只有一个"死链清单" Issue，报告按日期累积在评论里，天然形成一份可追溯的巡检历史 📝

权限方面，工作流只申请了contents: read和issues: write（第 16-18 行），遵循最小权限原则，安全又规范。

新手可直接抄作业的 6 个自动化技巧

1. cron + push 双触发：定时巡检兜底，内容变更即时复检
2. UA 轮换 + 完整浏览器头：大幅降低被反爬误杀的假死链
3. 有限重试（2 次、间隔 3 秒）：过滤临时网络抖动
4. 分级告警：损坏/超时/重定向循环分开统计，只有真死链才报障
5. 最小权限：只授予任务必需的issues: write
6. Issue 幂等：查重后再创建或评论，避免自动化刷屏

项目文件资料速查

• 检测器工作流：.github/workflows/link-checker.yml
• 免费 AI 服务索引主清单：README.md
• MIT 开源协议：LICENSE

总结来说，no-cost-ai 的自动化链接检测器证明了一件事：一个不到 350 行的 YAML 工作流，就能替代人工完成"提取 → 访问 → 判定 → 报告 → 报障"的完整闭环。这套思路可以平移到任何以链接/文档为主的项目中，是新手学习 GitHub Actions 自动化的优秀范本 🚀

【免费下载链接】no-cost-ai80+ free AI services for chat, image, video, voice & APIs (may sometimes include access to lead gen ai models for free)项目地址: https://gitcode.com/gh_mirrors/no/no-cost-ai