go 程序中启动多个 tcp 客户端 goroutine 后，若主函数未等待它们完成便直接结束，会导致客户端逻辑（如读取响应、打印日志）被强制中断——`fmt.println("is reached")` 不输出正是此现象的典型表现。
在 Go 中，main 函数返回即代表整个程序终止，所有正在运行的 goroutine 会被立即强制停止，无论其是否执行到 defer、io.ReadFull 或后续语句。你遇到的问题根本原因正在于此：go client(...) 启动后，主 goroutine 迅速执行完循环并退出，而 client 中尚未完成的网络 I/O（尤其是阻塞在 io.ReadFull 的读取操作）和后续 fmt.Println 都被无情截断。
✅ 正确做法：使用 sync.WaitGroup 同步主协程与工作协程
WaitGroup 是 Go 标准库提供的轻量级同步原语，专为“等待一组 goroutine 完成”场景设计。你需要：
- 在 main 中声明 wg := sync.WaitGroup{}；
- 每次 go client(...) 前调用 wg.Add(1) 增加计数；
- 在 client 函数开头（推荐）或结尾通过 defer wg.Done() 标记完成；
- 主循环结束后调用 wg.Wait() —— 此调用会阻塞直到所有 Done() 被调用。
以下是修正后的完整结构示例：
func client(wg *sync.WaitGroup, servId uint16, servAddr string) {
defer wg.Done() // 确保无论成功/失败都计数减一
tcpAddr, err := net.ResolveTCPAddr("tcp", servAddr)
if err != nil {
log.Printf("resolve addr %s failed: %v", servAddr, err)
return
}
conn, err := net.DialTCP("tcp", nil, tcpAddr)
if err != nil {
log.Printf("dial %s failed: %v", servAddr, err)
return
}
defer conn.Close() // 避免连接泄漏
_, err = conn.Write(handshake(servId, 1500))
if err != nil {
log.Printf("write handshake to %s failed: %v", servAddr, err)
return
}
init := make([]byte, 8)
_, err = io.ReadFull(conn, init)
if err != nil {
log.Printf("read init from %s failed: %v", servAddr, err)
return
}
// ✅ 现在这行一定能执行并打印
fmt.Println("is reached")
fmt.Println("init bytes:", init)
}
func main() {
var (
c, startId, servId uint16
wg sync.WaitGroup
)
for s := range config.Servers {
for c = 0; c < config.Total_clients; c++ {
startId = config.Server_id * config.Total_clients
servId = startId + c
servAddr := fmt.Sprintf("%s:%d", config.Servers[s].Host, config.Servers[s].Port)
wg.Add(1)
go client(&wg, servId, servAddr)
}
}
wg.Wait() // ? 关键：主 goroutine 在此处阻塞，等待全部 client 完成
fmt.Println("All clients finished.")
}⚠️ 注意事项与最佳实践
- 永远 defer conn.Close()：避免 TCP 连接泄露，尤其在并发场景下易导致 too many open files 错误。
- 错误处理不可省略：原始代码中 check(err) 未定义且无日志，实际应显式判断并记录错误（如上例所示），否则失败时静默退出，调试困难。
- 不要依赖 time.Sleep 替代同步：它不可靠（可能过长或过短），且违背 Go 的并发哲学。
- WaitGroup 必须传指针：wg.Add() 和 wg.Done() 操作的是同一实例，传值会导致副本操作无效。
- 考虑超时控制：io.ReadFull 可能永久阻塞（如服务端不响应），建议对 conn 设置 SetReadDeadline 或改用带上下文的 net.Conn 方法（如 conn.SetReadDeadline(time.Now().Add(5 * time.Second))）。
通过正确使用 sync.WaitGroup 并辅以健壮的错误处理与资源管理，你的 TCP 客户端将稳定执行至最后一行，不再“神秘消失”。
