为何Gorilla WebSocket服务器需客户端关闭连接后才处理接收的消息？

先帮你拆解下导致“所有消息仅在连接关闭后才开始处理”假象的核心原因，再给出针对性的修复方案：

1. 时间记录位置错误，导致判断偏差 #

你在handleMessage开头记录的t := time.Now()，是goroutine开始执行的时间，而非服务器收到这条消息的真实时间。Go的goroutine调度虽高效，但如果处理逻辑（解压、解析protobuf）是CPU密集型，或当前goroutine队列有积压，这些goroutine可能会被延迟调度。这就造成了日志时间挤在一起的错觉，但实际上服务器是收到一条消息就启动一个goroutine的。

修复方式：在socketHandler收到消息的瞬间记录时间，再传递给handleMessage：

func socketHandler(w http.ResponseWriter, r *http.Request) {
 enableCors(&w)
 upgrader.CheckOrigin = func(r *http.Request) bool { return true } // 注意：生产环境必须替换为严格的跨域校验！
 conn, err := upgrader.Upgrade(w, r, nil)
 if err != nil {
  log.Print("Error during connection upgrade:", err)
  return
 }
 log.Println("Client connected to websocket")
 defer conn.Close()
 streamedBytes := 0
 for {
  messageType, message, err := conn.ReadMessage()
  if err != nil {
   log.Println("Error during message reading:", err, messageType, message)
   break
  }
  streamedBytes += len(message)
  receiveTime := time.Now() // 在这里记录消息接收时间
  go handleMessage(message, receiveTime)
 }
 log.Printf("Streamed %v megabytes", float64(streamedBytes)/1000000.0)
}

同步修改handleMessage函数：

func handleMessage(message []byte, receiveTime time.Time) {
 b := bytes.NewReader(message)
 z, err := zlib.NewReader(b)
 if err != nil {
  log.Printf("Error creating zlib reader: %v", err) // 替换log.Fatal，避免单条消息错误导致整个服务崩溃
  return
 }
 defer z.Close()
 p, err := io.ReadAll(z) // Go 1.16+推荐用io.ReadAll替代已废弃的ioutil.ReadAll
 if err != nil {
  log.Printf("Error unzipping content: %v", err)
  return
 }
 chunk := &DtmChunk{}
 if err := proto.Unmarshal(p, chunk); err != nil {
  log.Printf("Failed to parse chunk: %v", err)
  return
 }
 points := chunk.GetPoints()
 log.Printf("Received at %v | Processed %v points", receiveTime, len(points))
}

2. 日志输出缓冲问题（Windows环境尤为明显） #

如果你的服务器在Windows上运行，默认控制台输出是带缓冲的——log.Printf的内容不会实时显示，而是先存在缓冲区，直到缓冲区满、程序结束或强制刷新才会批量输出。这会让你误以为所有处理都是在连接关闭后才执行，但实际上goroutine早就完成了，只是日志被攒到一起显示。

修复方式：

• 给log包添加微秒级时间戳，并强制输出到无缓冲的标准错误流：

  func init() {
    log.SetFlags(log.LstdFlags | log.Lmicroseconds)
    log.SetOutput(os.Stderr)
  }
  

• 或者直接使用第三方日志库（如zap、logrus），它们默认会实时刷新输出，避免缓冲问题。

3. 错误处理过于激进：log.Fatal会直接终止整个服务 #

你在handleMessage中多次使用log.Fatal，这个函数会直接调用os.Exit(1)——只要有一条消息处理出错，整个WebSocket服务器就会崩溃，所有连接都会断开。这在生产环境是绝对不可接受的，必须换成log.Printf记录错误后返回。

额外验证：客户端发送逻辑 #

虽然你提到Wireshark看到数据按间隔发送，但仍需确认客户端的send函数是否真的被间隔调用。比如在调用send的业务代码中，要确保加上延迟：

// 示例：在组件中批量发送数据块
async function sendDatasetChunks(chunks: any[]) {
  for (const chunk of chunks) {
    await this.fileUploadService.send(chunk);
    // 1-2秒随机间隔
    await sleep(Math.floor(Math.random() * 1000) + 1000);
  }
  this.fileUploadService.finaliseFileStream();
}

最后提醒：upgrader.CheckOrigin = func(r *http.Request) bool { return true }这种完全放开跨域的设置仅适合开发环境，生产环境必须根据实际域名配置严格的跨域校验，否则会存在安全风险。

内容的提问来源于stack exchange，提问作者mrscruff