net.dialtimeout 更适合端口扫描，因其可精确控制连接超时（如500ms），避免系统默认长超时阻塞并发；需合理设值防误判，配合waitgroup与令牌桶限流，并通过类型断言准确区分open/filtered/closed状态。
为什么 net.DialTimeout 比 net.Dial 更适合端口扫描
直接用 net.Dial 扫描大量端口时，超时不可控——它默认依赖系统 TCP 连接超时（Linux 通常 2–3 分钟），扫一个死端口就卡住几十秒，根本没法并发。而 net.DialTimeout 允许你精确控制连接尝试时长，比如设成 500 * time.Millisecond，既避开防火墙的 SYN flood 检测，又不让 goroutine 僵死。
- 必须显式传入
time.Duration，不能写500，否则是纳秒级，实际等于立刻失败 - 超时值太短（如
10ms）会导致局域网内正常端口误报为关闭；太长（如2s）会拖慢整体扫描速度 - 注意：Windows 下某些高并发场景中，
DialTimeout可能触发WSAENOBUFS错误，需配合runtime.GOMAXPROCS限流
如何用 sync.WaitGroup 安全控制并发 goroutine 数量
不加限制地为每个端口启一个 goroutine，轻松创建上万协程，内存暴涨、调度开销大，还可能被目标主机或中间设备限速/拦截。用 sync.WaitGroup + channel 控制并发数，是最轻量且可靠的方式。
- 别把
WaitGroup.Add(1)放在 goroutine 内部——容易漏调或重复调，应在启动前调用 - 务必在 goroutine 结束前调用
wg.Done()，哪怕遇到错误也要执行，否则wg.Wait()永远阻塞 - 推荐搭配带缓冲的 channel 做“令牌桶”：先从
sem := make(chan struct{}, 100)拿令牌，扫描完再放回，比单纯靠WaitGroup更易控峰
怎么判断 net.DialTimeout 返回的是“端口关闭”还是“网络不可达”
错误类型不是只看字符串是否含 "timeout" 或 "refused"——底层错误可能是 *net.OpError 套着 *os.SyscallError，直接 err.Error() 匹配极易漏判或误判。
- 用类型断言检查：
if opErr, ok := err.(*net.OpError); ok && opErr.Err != nil - 真正表示端口关闭的是
opErr.Err.Error() == "connection refused"（Linux/macOS）或包含"WSAECONNREFUSED"（Windows） - 网络不可达、主机无响应、防火墙静默丢包等情况，通常表现为
opErr.Err是*os.SyscallError且Err == syscall.EHOSTUNREACH或syscall.ENETUNREACH - 别忽略
opErr.Timeout()方法，它比字符串匹配更准，能统一识别所有超时类错误
为什么扫描结果要区分 “open”、“filtered”、“closed”，而不是只标 “open/closed”
真实网络环境中，很多防火墙会静默丢弃 SYN 包（不回 RST），导致你收不到任何响应——这不是端口开着或关着的问题，而是路径被过滤了。只分两类会严重误导判断。
立即学习“go语言免费学习笔记（深入）”；
-
open：收到 SYN-ACK → 确认服务监听 -
closed：收到 RST → 确认端口无服务 -
filtered：超时且无 RST → 无法确认，可能是防火墙、ACL、NAT 设备拦截 - 实践中，
filtered出现频率远高于预期，尤其在云环境或企业内网；忽略它，相当于把盲区当安全区
端口扫描真正的难点不在发包，而在对各种中间设备行为的容忍和归因——同一段代码，在本地 Docker 网络里跑得飞快，在 AWS Security Group 后面可能全变成 filtered，这时候看日志里满屏 timeout 就该想到：不是你的代码慢，是网络在说话。
