用Golang做站点可用性检测需并发控制、健壮HTTP客户端、分层结果判定及可靠上报：通过worker pool限并发，自定义http.Client设超时与连接复用，按网络/协议/业务层分类错误，耗时超阈值标记为慢或不可用，结果异步批量上报并本地落盘重试。
用 Golang 做站点可用性检测，核心是并发发起 HTTP 请求、统一判断响应状态、收集耗时与错误，并把结果可靠地上报。它不复杂，但容易忽略超时控制、连接复用、错误归类和上报失败重试等细节。
并发探测：用 goroutine + channel 控制节奏
别直接起几百个 goroutine，容易打爆本地文件描述符或被目标限流。推荐用带缓冲的 channel 做工作池（worker pool），限制并发数（比如 50），再用 WaitGroup 等待全部完成。
- 定义一个任务结构体，含 URL、超时时间、重试次数
- 用 channel 分发 URL 列表，每个 worker 从 channel 取任务、执行 HTTP 请求
- 用另一个 channel 收集结果（成功/失败/耗时/状态码/错误原因），避免共享变量锁竞争
- 设置全局 context.WithTimeout，确保整批探测有总超时（如 30 秒），防止某个 URL 卡死拖垮整体
请求健壮性：HTTP 客户端要自定义
默认 http.Client 不适合探测场景——没超时、不复用连接、忽略重定向可能误判。需显式配置：
- Transport 设置 MaxIdleConnsPerHost（建议 100）、IdleConnTimeout（30s）、TLSHandshakeTimeout（5s）
- Client 设置 Timeout（单次请求总超时，推荐 10s）、CheckRedirect（设为 http.ErrUseLastResponse 防止跳转干扰状态判断）
- 对 HEAD 请求优先（轻量），若返回 405 再 fallback 到 GET；注意有些站点 HEAD 返回 404 但 GET 正常，按业务需求决定是否接受
- 检查响应 Body 是否为空、Content-Length 是否为 0、是否返回了有效 HTML/JSON（可选关键字匹配，如 “200 OK” 或 “{“）
结果判定：不只是看 status code
200 不等于可用，503 也不一定不可用。建议分层判断：
立即学习“go语言免费学习笔记（深入）”；
- 网络层：连接失败、DNS 解析超时、TLS 握手失败 → 归为 “network_error”
- 协议层：HTTP 状态码 4xx/5xx → 记录具体 code，502/503/504 单独标记为 “gateway_error”
- 业务层：状态码是 200，但 body 为空、返回维护页 HTML、JSON 解析失败、关键字段缺失 → 标记为 “content_invalid”
- 耗时阈值：P95 耗时 > 2s 视为“慢”，> 5s 视为“不可用”（按实际 SLA 调整）
结果上报：异步 + 本地落盘 + 重试
上报服务（如 Prometheus Pushgateway、HTTP 上报接口、Kafka、或本地日志）可能临时不可用。不能丢数据：
- 探测结果先写入内存 slice 或带缓冲 channel，再由单独 goroutine 批量上报（如每 10 条或每 5 秒 flush 一次）
- 上报失败时，把原始结果序列化（JSON）追加到本地临时文件（如 /tmp/upcheck_20240512.log），启动时自动读取未上报记录重发
- 上报接口建议带签名或 token 鉴权；若用 HTTP，用 http.Client 设置重试（最多 3 次，指数退避），并忽略 4xx 错误（客户端问题不重试）
- 上报内容至少含：url、status、latency_ms、error_type、timestamp、probe_id（方便追踪）
基本上就这些。Golang 的并发模型和标准库足够支撑一个稳定、可控、可观测的可用性探测系统，关键是把边界情况想清楚，别让一个坏 URL 拖垮整组探测。
