Go net.ListenConfig 怎样在监听前判断端口是否可用

Go 中判断端口是否可用，最可靠的做法不是先探测再监听，而是直接调用 net.ListenConfig.Listen 尝试绑定。调用成功，当前进程才真正取得监听权；调用失败，就按返回错误处理。先用另一个连接或临时监听器做“预检查”再关闭，会留下检查与正式绑定之间的竞态。

官方地址：https://pkg.go.dev/net#ListenConfig

把“端口可用”理解成一次绑定结果

端口是否可用同时取决于 network、地址族、绑定地址、操作系统状态和其他进程的占用情况。一个独立的检查即使刚刚成功，正式监听前也可能被其他进程抢走。因此不要把 net.Dial 成功、查看某个端口列表或先监听再关闭当成最终结论。真正有用的结论只有正式调用 Listen 的返回值。

用 ListenConfig 申请固定端口

固定端口场景直接把监听动作当作判断动作。context.Context 用于地址解析阶段；官方文档明确说明，它不会影响已经返回的 Listener。下面的示例只展示包和错误边界，正文没有执行这段代码。

package main

import (
    "context"
    "errors"
    "fmt"
    "net"
)

// openListener 把“端口是否可用”收敛为一次正式绑定。
func openListener(ctx context.Context, network, address string) (net.Listener, error) {
    var lc net.ListenConfig
    ln, err := lc.Listen(ctx, network, address)
    if err != nil {
        var opErr *net.OpError
        if errors.As(err, &opErr) {
            // 保留底层网络和地址，便于区分绑定目标与其他错误。
            return nil, fmt.Errorf("监听 %s %s 失败: %w", opErr.Net, opErr.Addr, err)
        }
        return nil, err // 非 OpError 也不能被当成端口可用。
    }
    return ln, nil // 返回的 Listener 就是当前绑定成功的凭据。
}

func main() {
    ln, err := openListener(context.Background(), "tcp4", "127.0.0.1:8080")
    if err != nil {
        fmt.Println(err)
        return
    }
    defer ln.Close() // 不再提供服务时释放监听器。
    fmt.Println("监听地址:", ln.Addr().String())
}

如果 8080 已被占用，程序应把错误写入日志并决定退出、重试其他明确端口，或交给配置层重新选择。不要为了让程序“看起来可用”而吞掉错误，也不要在错误发生后继续使用可能为 nil 的 Listener。错误包装后仍可使用 errors.As 继续提取 *net.OpError。

不需要固定端口时使用 :0

测试服务、临时代理和并行任务通常不需要预先猜一个端口。把端口写成 0，让操作系统在正式绑定时选择可用端口，再从返回的 Listener 读取地址。这里同样不能马上关闭 Listener 后再用同一个地址重新监听，因为那会重新引入竞态。

package main

import (
    "context"
    "fmt"
    "net"
)

func dynamicPort() error {
    var lc net.ListenConfig
    ln, err := lc.Listen(context.Background(), "tcp", "127.0.0.1:0")
    if err != nil {
        return fmt.Errorf("申请临时端口失败: %w", err)
    }
    defer ln.Close() // 使用期间保持 Listener 存活，结束后再释放。

    address := ln.Addr().String()
    fmt.Println("系统分配的监听地址:", address)
    // 在这里启动服务或把 address 交给同一测试流程。
    return nil
}

理解 Control 与排查边界

ListenConfig.Control 会在创建网络连接后、绑定到操作系统之前被调用，适合设置底层 socket 选项。它不是“先检查端口再决定是否监听”的回调：最终能否绑定，仍由 Listen 返回的错误决定。若 Control 自己返回错误，程序也应把它当作监听失败处理。

排查时先固定三件事：使用的是 tcp、tcp4 还是 tcp6；地址是回环地址、空主机还是具体网卡；失败发生在地址解析、socket 选项还是 bind。日志至少记录 network、address 和包装后的错误。这样比写一个“端口探测函数”更接近真实绑定条件。

监听成功后可以只保存端口号吗？

如果绑定的是 :0，应保存 ln.Addr() 返回的完整地址；只保存端口号可能丢失地址族和绑定主机信息。

先用 net.Dial 判断端口没人用可以吗？

不可以把它当成正式判断。Dial 反映的是当时是否有可连接服务，不能保证随后本进程一定能绑定。

ListenConfig 的 context 能让 Accept 超时吗？

不能。它只参与监听地址解析阶段；要控制连接接收或服务生命周期，应单独设计 Listener 的关闭和服务退出逻辑。

记住一句话：固定端口用一次正式 Listen 判断，临时端口用 :0 让系统选择；成功后保留 Listener，失败时记录原始错误，不要依赖有竞态的预检查。