最直接可靠的端口占用检测方式是用 net.listen 尝试绑定，成功即可用，失败需判断错误类型；仅当底层 errno 为 eaddrinuse 或含“address already in use”才表示被占，其他错误如地址不可用、权限不足等须排除。
用 net.Listen 尝试监听是最直接的检测方式
Go 没有内置“检查端口是否被占用”的函数，net.Listen 是最贴近底层、最可靠的判断手段——不是查进程或端口列表，而是真正尝试绑定。成功说明可用，失败再看错误类型。
关键在于区分错误：不是所有 Listen 失败都代表端口被占。常见干扰包括地址不可用、权限不足、协议不支持等。
- 只对
"tcp"或"tcp4"类型调用，避免"tcp6"因 IPv6 配置问题误报 - 监听地址建议用
"127.0.0.1:PORT"而非":PORT"，减少因系统防火墙或 bindaddr 策略导致的假失败 - 务必调用
ln.Close()，否则可能残留监听句柄，影响后续测试
errors.Is(err, net.ErrClosed) 不适用，要匹配 os.SyscallError 和具体 errno
Go 的 net.Listen 错误不是标准 error wrapper，不能靠 errors.Is(err, net.ErrClosed) 判断端口占用。真实场景中，被占用时通常返回 *os.SyscallError，底层 errno 为 EADDRINUSE（Linux/macOS）或 WSAEADDRINUSE（Windows）。
- 用
strings.Contains(err.Error(), "address already in use")最简单，但不跨平台稳定 - 更稳妥的做法是类型断言：
if opErr, ok := err.(*net.OpError); ok && opErr.Err != nil，再检查opErr.Err是否含"address already in use"或是否为*os.SyscallError - Windows 下注意：即使端口空闲，若启用了“快速端口回收”（TIME_WAIT 复用），也可能短暂返回占用错误
别用 net.Dial 反向探测，它测的是连通性，不是监听权
有人会想：我 dial 一下，能连上是不是就说明被占了？不对。net.Dial("tcp", "127.0.0.1:8080") 成功，只能说明那里有个服务在 listen 并接受连接，但无法区分是本进程刚 bind 还是别的进程占着；而 dial 失败更不可靠——目标服务可能关了、防火墙拦了、甚至只是没响应 SYN ACK。
立即学习“go语言免费学习笔记（深入）”；
-
Dial是客户端行为，和“能否 bind”无直接关系 - 若目标服务设置了
SO_LINGER或处于TIME_WAIT，dial 可能失败，但端口实际已释放 - 某些容器/网络命名空间下，dial 路径和 listen 路径不一致，结果完全失真
并发检测时要注意 TIME_WAIT 和端口复用竞争
高频调用 net.Listen 做端口扫描或自动端口发现时，容易撞上内核的 TIME_WAIT 状态窗口（默认几十秒），导致连续失败。这不是 bug，是 TCP 正常行为。
- 不要依赖单次
Listen结果做最终决策，尤其在自动化选端口场景下，应加 retry + 随机偏移 - 如需快速复用，可在
ListenConfig中设置Control函数调用setsockopt(SO_REUSEADDR)，但注意：这仅降低冲突概率，不改变“是否已被监听”的事实判断逻辑 - 生产环境避免轮询检测，优先用配置指定端口，或由外部服务（如 systemd socket activation）统一管理
net.Listen 的方案，要么不准，要么多一层间接假设。真正难的不是写代码，是理解为什么必须亲自 bind 一次。 
