go中判断端口是否被占用最可靠方式是用net.listen尝试绑定，仅当错误为eaddrinuse或含“address already in use”才表示被占，其他失败原因（如权限不足、地址不可用）须排除；成功后必须调用ln.close()防止句柄泄露。
go 没有“端口是否被占用”的现成布尔函数，net.listen 尝试绑定失败且错误类型匹配 eaddrinuse（或含 "address already in use"）才是可靠依据——其他失败原因（如地址不可用、权限不足、ipv6 配置异常）不能等同于“被占”。
用 net.Listen 检测时只认 EADDRINUSE 错误
不是所有 net.Listen 失败都代表端口被占。必须做错误类型判断：
- 用
errors.Is(err, syscall.EADDRINUSE)跨平台不稳，Linux/macOS 可行，Windows 是syscall.WSAEADDRINUSE，且 Go 1.13+ 后syscall已逐步弃用 - 更稳妥的是类型断言：
if opErr, ok := err.(*net.OpError); ok && opErr.Err != nil，再检查opErr.Err.Error()是否含"address already in use" - 避免用
strings.Contains(err.Error(), "address already in use")直接判断——某些语言环境或自定义 error 包可能翻译该字符串 - 监听地址建议用
"127.0.0.1:PORT"而非:PORT，减少因系统 bind 策略（如net.ipv4.ip_nonlocal_bind）或防火墙导致的误判
net.DialTimeout 不是端口占用检测手段
net.DialTimeout 测的是“能否连上远端服务”，和“本地能否绑定”完全无关：
- 对
127.0.0.1:8080成功 dial，只能说明那里有个 listen socket，但无法区分是本进程刚 bind 还是别的进程在用 - dial 失败更不可靠：目标服务崩溃、防火墙 DROP、SO_LINGER 导致的 TIME_WAIT 延迟、甚至 DNS 解析失败，都会返回错误
- 某些容器或 network namespace 下，dial 走 host 网络而 listen 在隔离网络，结果彻底失真
- 若真要用 dial 辅助验证，仅限已知服务存在且稳定运行的场景（如健康检查），绝不能用于“能否启动”的决策依据
并发检测时 TIME_WAIT 会导致连续误报
高频调用 net.Listen（比如自动端口发现循环）容易撞上内核的 TIME_WAIT 窗口（默认几十秒），表现为“刚释放的端口立刻又报被占”：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 这不是 bug，是 TCP 正常行为：主动关闭方需维持
TIME_WAIT以防止旧包干扰新连接 - 不要加
time.Sleep等待——不可控，且浪费时间；应改用随机端口探测（net.Listen("tcp", ":0")）或预分配端口池 - 开发阶段可启用
SO_REUSEADDR（Go 的net.Listen默认已设，但某些嵌入式系统或老内核需显式确认） - 若必须重试，建议指数退避 + 最大重试次数（如 3 次），而非固定间隔轮询
别依赖 lsof 或 netstat 命令封装
用 exec.Command("lsof", "-i", ":8080") 这类方式看似直观，但问题很多：
- 跨平台差：macOS/Linux 用
lsof，Windows 用netstat -ano，需分别适配解析逻辑 - 权限问题：普通用户无法看到 root 进程监听的端口，
lsof可能漏报 - 竞态条件：命令执行到实际
Listen之间存在时间窗口，检测“空闲”后仍可能被其他进程抢占 - 容器/命名空间下，宿主机
lsof看不到容器内进程，结果无效 - 真正需要的不是“谁在用”，而是“我能不能 bind”——只有
net.Listen能给出确定答案
最易被忽略的一点：每次 net.Listen 成功后务必调用 ln.Close()，否则句柄残留会干扰后续检测，尤其在循环测试中容易积累 fd 泄露。这不是可选操作，是必须步骤。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
