net.DialTimeout 更适合端口扫描因其强制超时保障并发节奏；建议局域网超时设为500ms–2s，避免漏判；需限流并发、及时关闭连接、绕过防火墙干扰，并合理控制goroutine数量（20–50为宜）。
为什么 net.DialTimeout 比 net.Dial 更适合端口扫描
因为端口扫描本质是大量快速试探，阻塞式连接会拖垮整个流程。用 net.Dial 默认无超时，一个卡住的主机可能让后续几十个探测全挂住；而 net.DialTimeout 能强制在几秒内返回，保障整体节奏。
实操建议：
- 超时值别设太短——局域网内建议
500 * time.Millisecond到2 * time.Second，低于 200ms 容易漏掉响应稍慢的设备（比如嵌入式设备或高负载虚拟机） - 别复用同一个
net.Conn：每次调用net.DialTimeout都新建连接，扫描完立即关闭，避免 fd 耗尽 - 注意系统限制：Linux 默认单进程最多 1024 个 socket，开 goroutine 扫描时得加限流（比如用带缓冲的 channel 控制并发数）
如何避免被本地防火墙/iptables 干扰扫描结果
很多新手扫不到本机开放的 80 或 22 端口，不是代码问题，而是系统拦截了 SYN 包。Linux 上 iptables 或 nftables 可能默认丢弃未匹配规则的入向连接请求，导致你发出去的 SYN 没回包，误判为“端口关闭”。
验证和应对方法：
立即学习“go语言免费学习笔记（深入）”；
- 先用
sudo ss -tln确认目标端口确实在监听 - 临时清空规则测试：
sudo iptables -P INPUT ACCEPT && sudo iptables -F（仅测试环境！） - 更稳妥的做法是加一层本地探测逻辑：对
127.0.0.1或本机局域网 IP 单独走net.Listen+net.Dial组合验证连通性，绕过中间链路干扰
并发扫描时 runtime.GOMAXPROCS 和 goroutine 数量怎么配
设太高不等于扫得快。Goroutine 是轻量，但每个仍要分配栈、触发调度、竞争网络 fd。局域网扫描瓶颈通常不在 CPU，而在系统 socket 缓冲区、ARP 解析延迟和交换机转发能力。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操经验：
- 局域网（
/24网段）下，20–50 个 goroutine 并发足够，再高吞吐不增反降 - 别盲目调
runtime.GOMAXPROCS：默认值（通常是 CPU 核心数）已够用，调成 100 不会让扫描变快，反而增加调度开销 - 用带缓冲的 channel 做并发控制，比如
sem := make(chan struct{}, 30)，每启一个 goroutine 先sem ，结束时 <code>
connection refused 和 i/o timeout 的真实含义差别
这是端口扫描里最常混淆的两个错误，直接决定你是否该继续探测其他端口。
connection refused 表示目标主机收到了 SYN，且明确回复了 RST——说明端口确实没服务在监听，或者被防火墙主动拒绝（如 REJECT 规则）。这是“确定关闭”的信号。
i/o timeout 表示发了 SYN 后没收到任何响应——可能是主机关机、IP 不存在、中间防火墙静默丢包、或端口被 DROP 规则拦截。不能等同于“端口关闭”，只代表“当前不可达”。
所以：
- 遇到
connection refused，可以放心跳过这个端口 - 遇到
i/o timeout，建议重试 1–2 次（间隔 300ms），尤其对关键端口如22、80 - 别把
i/o timeout当作“主机离线”——同一主机上有的端口超时、有的能连通，很常见
真正麻烦的是 ARP 缓存未命中时的首次探测延迟，它不报错也不返回，就卡在那儿等邻居发现完成。这个时间点没法靠 Go 代码控制，得接受它存在。
