应使用 net.DialTimeout 进行 TCP 端口探测，超时设为 500ms 以区分 connection refused（端口关闭）与 i/o timeout（状态未知），避免用 localhost 导致 DNS 延迟，地址格式必须为 "host:port"，且需及时 close 连接防 fd 泄露。
用 net.DialTimeout 做快速端口探测，但得避开常见超时陷阱
直接用 net.DialTimeout 尝试连接是最轻量的检测方式，但它不是“判断端口是否被监听”的等价操作——它测的是“能否建立 TCP 连接”，而监听进程可能只响应特定协议或拒绝非预期数据。所以它适合快速探活，不适合精确判定服务是否就绪。
关键陷阱在于：默认超时太长（如 30 秒），且 DNS 解析失败也会卡住；本地回环地址（127.0.0.1）和 localhost 行为不一致（后者触发 DNS 查找）；IPv6 地址未显式指定时可能 fallback 失败。
- 始终用
net.ParseIP验证 IP，避免传入localhost导致解析延迟或失败 - 超时设为
500 * time.Millisecond足够区分“拒绝连接”和“无响应” - 连接目标格式固定为
"host:port"，例如"127.0.0.1:8080"，不要加协议前缀
为什么 net.Listen + defer ln.Close() 不可靠
很多人想用 net.Listen("tcp", ":8080") 看是否 panic 来判断端口占用，这在 Linux 上看似可行，但实际问题很多：即使端口空闲，也可能因 SO_REUSEADDR 或 TIME_WAIT 状态导致监听成功，而真正服务启动时仍冲突；Windows 下对已绑定端口再次监听会直接报错，但错误类型和文本不统一（"address already in use" vs "An operation was attempted on something that is not a socket"）；而且监听后不立即 close 可能阻塞后续测试。
- 该方法本质是“尝试抢占端口”，不是探测，结果不可预测
- 错误字符串依赖系统 locale 和 Go 版本，无法稳定匹配
- 若忘记
defer ln.Close()，会导致 goroutine 泄露或端口持续占用
跨平台兼容的关键：用 net.ListenTCP + ln.Addr().(*net.TCPAddr).Port
如果必须通过监听方式探测（比如要确认端口可被绑定），唯一较稳的方式是用 net.ListenTCP 并检查返回的 *net.TCPAddr 的 Port 字段——当指定端口为 0 时系统自动分配，若返回端口等于你请求的端口，说明绑定成功；否则说明被占。这种方式绕过了字符串错误匹配，也规避了 UDP/Unix domain socket 的干扰。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 只对
"tcp"协议调用，避免net.Listen("tcp4", ...)在 IPv6-only 环境失败 - 监听地址用
":0"让系统选空闲端口，再对比目标端口是否被分配到 - 务必用
ln.Close()（非 defer）并在判断后立即释放，防止资源残留
生产环境建议：组合策略 + 缓存探测结果
单次探测误差率不低，尤其在高负载或容器网络中。真实场景下应把 net.DialTimeout 探测封装成带重试（最多 2 次）、指数退避的函数，并缓存最近 30 秒的结果，避免高频轮询触发连接限制或被防火墙限速。
- 首次探测失败后，间隔 100ms 再试一次，排除瞬时丢包
- 缓存键用
"host:port"字符串，值为bool+time.Time时间戳 - 对 Docker 容器内服务，优先探测容器网关 IP（如
172.17.0.1）而非localhost，避免 host network 模式误判
最易被忽略的是：探测目标地址的路由可达性。比如在 Kubernetes Pod 中，127.0.0.1:3306 永远不通（MySQL 在另一 Pod），但 net.DialTimeout 报错是 "connection refused"，和真被占用一模一样——得先确认服务发现路径是否正确，再谈端口探测。
