OpsKitPro logo
OpsKitPro_
返回部落格
实现2026-04-207 min

網站診斷模組怎麼做:website-check 的實作拆解

目標歸一化、並行探測、部分成功回退與摘要優先,是這套診斷頁的核心。

這裡是主站的整理版,必要時可以回到下方文章列表繼續看。
瀏覽文章列表
網站診斷模組怎麼做:website-check 的實作拆解
關於正文

這裡按主站文章來整理,保留要點與結構,方便快速閱讀。

正文

先把目标“整理对”

01

website-check 的第一步不是发请求,而是把输入规范化。用户可能输入域名、完整 URL、带路径的链接,甚至夹着多余的尾斜杠。前端和后端都需要把这些输入统一收成真正的主机名,否则同一个目标会被当成多个对象。

这一层小逻辑非常重要,因为它决定了诊断结果是否稳定,也决定了缓存和测试能不能复用。

參考檔案src/app/tools/website-check/WebsiteCheckClient.tsxsrc/app/api/diagnostic/route.ts

并行探测比串行更适合这个页面

02

这类工具最常见的问题,是把 DNS、HTTP、SSL、CDN 拆成一条长流程,用户会先看见漫长的“第 1 步、第 2 步、第 3 步”。但真实的诊断更像并行工作:多个信号一起看,最后再汇总出结论。

所以当前页面改成了摘要先行、明细折叠的结构。结果区先给出判断,再让用户根据需要展开 DNS、SSL、证书链或原始 JSON。

參考檔案src/app/tools/website-check/WebsiteCheckClient.tsxsrc/app/tools/website-check/page.tsx

部分成功比“完全失败”更有用

03

在边缘环境里,外部服务不稳定是常态。与其让页面直接白屏或者返回一行错误,不如把能确认的部分先展示出来,再把不可用的部分明确标记为待确认。

这也是我一直坚持“部分成功态”的原因:用户至少能知道 DNS、HTTP、SSL、CDN 中哪一环已经确认,接下来该往哪里看。

參考檔案src/app/api/diagnostic/route.tssrc/lib/api-contracts.tssrc/app/tools/website-check/WebsiteCheckClient.tsx