最稳的单端口扫描方式是用 net.DialTimeout 并合理设超时（内网200ms/外网2s），并发需控速（内网50–100/外网5–20），区分错误类型，对 timeout 端口轻量重试+ICMP验证，避免盲目全端口扫描或反向监听。
Go 里用 net.DialTimeout 扫单个端口最稳
直接用 net.DialTimeout 是 Go 做端口扫描的底线选择，比 net.Dial 多一个超时控制，避免卡死。TCP 层面只要能建立连接（SYN+SYN-ACK+ACK），就说明端口开放；连不上或超时，基本就是关着或被丢包。
常见错误是设了 1 秒超时但并发一高就全挂——不是代码错，是系统级限制：Linux 默认每秒新建连接数有限，加上 TIME_WAIT 占资源，扫太快反而大量 dial tcp i/o timeout 或 connection refused 混在一起难区分。
-
net.DialTimeout第三个参数是time.Duration，别传1 * time.Second就完事，内网建议 200ms，外网至少 2s 起步 - 别在循环里反复
defer conn.Close()——连接没建成就 panic，defer不会执行，得手动判空 - 错误类型要拆开看：
err != nil && strings.Contains(err.Error(), "timeout")是真超时；"connection refused"是端口明确关闭；"no route to host"往往是目标关机或防火墙 DROP
并发扫多个端口必须控速，别信 goroutine 数量自由
起 1000 个 goroutine 同时 dial，结果往往不是快，而是触发本地端口耗尽（too many open files）或被中间设备限速/拉黑。Go 的 goroutine 轻量，但底层 socket 是操作系统资源，受 ulimit -n 和 TCP 栈参数约束。
实测下来，稳定吞吐和准确率平衡点在：内网 50–100 并发、外网 5–20 并发。关键不是压数量，是压住重试和排队逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 用带缓冲的 channel 当信号量，比如
sem := make(chan struct{}, 20)，每个 goroutine 开始前sem <- struct{}{}，结束后<-sem - 别用
time.Sleep控频——它不解决资源竞争，只让时间变长；要用sync.WaitGroup配合 channel 等待完成 - 如果目标 IP 固定、只扫常用端口（如 22, 80, 443, 3306），优先做
portList := []int{22, 80, 443, 3306}，别扫 1–65535
扫到 i/o timeout 不等于端口关，得结合 ICMP 和重试判断
i/o timeout 是最模糊的返回值：可能是防火墙静默丢包、网络拥塞、中间 WAF 拦截，甚至目标主机负载太高没响应 SYN-ACK。单次 timeout 就标“closed”，误报率极高。
真实生产环境里，需要加一层轻量验证逻辑：对 timeout 的端口，最多重试 1 次（间隔 500ms），且只对特定 IP 做；同时发一个 icmp.Echo 包确认主机在线（用 golang.org/x/net/icmp），避免把宕机主机当成“全端口关闭”。
- 重试逻辑必须带 jitter，比如第二次 dial 超时设为
1.5 * baseTimeout，防止雪崩式重连 - 不要对所有 timeout 都重试——HTTP 类服务（80/443）值得试，数据库端口（3306/5432）重试意义不大，大概率是防火墙规则挡死
- ICMP 检测要开 root 权限（Linux/macOS），普通用户跑会报
operation not permitted，上线前得提前检查权限或降级处理
别用 net.Listen 反向监听来“验证开放”，那是自欺欺人
有人想“既然我连不上，那我在本地 listen 一个端口，看对方能不能 callback”，这完全误解了 TCP 连接方向：net.Dial 是主动发起连接，net.Listen 是被动等待入站——二者不在同一通道上，也绕不过 NAT、防火墙策略、运营商封锁。
这种写法唯一作用是让你多占一个本地端口，还可能因未 close 导致后续测试失败。真正的验证只有两种：能 Dial 成功，或者有业务层响应（比如 HTTP 返回 200）。
- 扫 SSH 端口，
Dial成功后可以立刻bufio.NewReader(conn).ReadString('\n')看是否返回SSH-字样，比纯连通性更准 - 扫 HTTPS，
Dial成功后别急着发 HTTP 请求，先做 TLS 握手（tls.Client(conn, cfg)），否则容易被 Nginx 等直接 reset - 所有连接建立后，务必设
conn.SetDeadline，防止后续读写卡住，尤其在解析 banner 时
端口扫描真正难的不是发包，是区分“没响应”背后的不同原因。超时、拒绝、无路由、ICMP 不通、TLS 握手失败……每种都要单独路径处理，混在一起只会越扫越迷。
