不能在gin handler中直接调用net.dialtimeout，因其同步阻塞会卡住goroutine长达数秒，高并发下易耗尽资源导致服务假死；必须结合context.withtimeout和带超时的net.dialer，并配ip限流与参数校验等安全措施。
直接用 net.DialTimeout + gin.HandlerFunc 就能做，但别在 handler 里直接阻塞调用——否则一个慢端口会拖垮整个 API 的并发能力。
为什么不能在 Gin handler 中直接 dial？
Gin 默认每个请求分配一个 goroutine，但 net.DialTimeout 是同步阻塞的。如果探测目标端口响应慢（比如超时设为 5s），这个 goroutine 就卡住 5 秒，期间无法处理其他请求。高并发下容易耗尽 goroutine 资源，触发 runtime: goroutine stack exceeds 1000000000-byte limit 或服务假死。
- 错误写法：
c.Request.Context()不会自动取消底层 socket 连接，超时后仍占用系统资源 - 必须用带 context 控制的
net.Dialer，且显式设置Timeout和KeepAlive - 建议最大并发探测数限制在 50–100，避免瞬时大量 outbound 连接打满本地 ephemeral 端口
如何安全地并发探测多个端口？
用 sync.WaitGroup + context.WithTimeout 控制单个探测，再用 channel 收集结果。不要用 go func() { ... }() 直接起 goroutine，必须绑定到 request context 防止请求取消后还在跑。
- 每个探测任务启动前：
ctx, cancel := context.WithTimeout(c.Request.Context(), 3*time.Second) - 用
&net.Dialer{Timeout: 3 * time.Second, KeepAlive: 30 * time.Second}实例 dial - 探测完成后立刻
cancel()，释放 context 资源 - 结果写入
chan map[string]interface{}，主 goroutine 用select+default防死锁
POST 请求怎么传目标和超时参数？
别用 query string 传一堆 host:port，用 JSON body 更清晰、可读性强，也方便加校验。
- 期望 body：
{"targets": ["127.0.0.1:80", "10.0.1.5:22", "google.com:443"], "timeout_ms": 2000} - 用
c.ShouldBindJSON(&req)解析，对req.Targets做长度限制（如 ≤ 50）和格式校验（正则匹配^([a-zA-Z0-9.-]+:\d+)$） -
timeout_ms必须落在 500–5000 范围内，防止用户传 0 或极大值导致失控 - 响应字段统一为：
{"host":"127.0.0.1","port":80,"status":"open","latency_ms":12.4}或"closed"/"timeout"
生产环境必须加什么保护？
这个 API 天然容易被滥用成端口扫描工具，不加限流等于裸奔。
- 必须用 Gin 中间件做 IP 级限流，例如每分钟最多 10 次请求（
golang.org/x/time/rate） - 禁止从公网直接暴露该接口，Nginx 层加
allow/deny或只允许内网 CIDR 访问 - 日志里记录 source IP、target 列表长度、总耗时，但**不记录具体 targets**（防敏感信息泄露）
- 返回体里去掉任何可能暴露网络拓扑的信息，比如不返回 ICMP 类型、TTL、服务 banner
真正难的不是 dial 成功与否，而是让 100 个并发探测互不干扰、不拖垮服务、不被滥用——控制权必须交给 context，而不是靠 sleep 或全局锁。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
