Go TCPConn CloseWrite 半关闭后服务端为什么还收到数据

调用 TCPConn.CloseWrite() 后，服务端还能收到数据，通常不是关闭失败，而是把“关闭本地写方向”误解成了“立即关闭整条 TCP 连接”。CloseWrite 只结束客户端继续写入的能力；在它之前已经交给连接的数据仍会发送，对端也仍然可以沿反方向写回响应。服务端读完请求后，才会在后续读取中观察到 io.EOF。

CloseWrite 关闭的是哪一半

一条 TCP 连接有两个相互独立的方向。客户端调用 CloseWrite 后，本地不能再把新的业务数据写入发送流，但本地读取方向仍然存在；服务端收到 FIN 后，也只是知道客户端不会再发送更多字节，并不代表服务端必须立即断开。

可以把它理解成“我说完了，请你继续回答”。这正是半关闭的用途：客户端先发送完整请求，再用 FIN 表示请求结束，同时保留接收响应的能力。

为什么服务端先收到数据，之后才看到 EOF

Write 成功表示数据已经被连接接受，CloseWrite 再表示发送流结束。接收端的读取顺序因此可能是：第一次 Read 得到请求内容，继续读取时仍可能得到剩余内容，所有数据读尽后，下一次读取才返回 io.EOF。EOF 是“后面没有更多数据”的信号，不是“之前的数据不存在”。

排查时不要把“看到 EOF”写成“没有读到数据”。应先判断 n，再处理 err；一次读取可能同时带回最后一段数据和一个边界错误，业务代码不能只看错误值。

发送完请求后继续读取响应的 Go 写法

下面的示例表达一个常见协议：客户端发送请求体，明确结束发送，然后等待服务端响应。示例只展示语义，不代表图中的输出已经在本机执行。

package main

import (
    "fmt"
    "io"
    "net"
    "time"
)

func request(conn *net.TCPConn, body []byte) error {
    // 先发送完整请求；Write 返回的字节数不足时不能静默丢弃尾部。
    n, err := conn.Write(body)
    if err != nil {
        return fmt.Errorf("写入请求失败: %w", err)
    }
    if n != len(body) {
        return fmt.Errorf("请求未写完: %d/%d", n, len(body))
    }

    // 只结束客户端到服务端的发送方向，保留读取响应的能力。
    if err := conn.CloseWrite(); err != nil {
        return fmt.Errorf("关闭写方向失败: %w", err)
    }

    // 逐段读取响应；数据和 EOF 要分别处理。
    if err := conn.SetReadDeadline(time.Now().Add(5 * time.Second)); err != nil {
        return fmt.Errorf("设置读取截止时间失败: %w", err)
    }
    buf := make([]byte, 4096)
    for {
        n, err := conn.Read(buf)
        if n > 0 {
            fmt.Printf("收到响应: %s", buf[:n])
        }
        if err == io.EOF {
            return nil
        }
        if err != nil {
            return fmt.Errorf("读取响应失败: %w", err)
        }
    }
}

真实项目还要在外层负责 conn.Close()，并根据协议决定是否允许服务端也半关闭。若客户端在 CloseWrite 后继续调用 Write，应把返回错误当作状态边界，而不是重新建立一条隐含的发送通道。

哪些情况不该使用半关闭

如果协议要求双方同时结束，或连接只承载一次短请求且不需要读取后续响应，使用 Close 更直接。还要注意，网络库、代理和自定义协议可能对半关闭的支持方式不同；不要仅凭客户端调用成功就推断服务端业务已经完成，服务端仍需读到 EOF、校验请求格式并决定何时回包。

常见问题

CloseWrite 后本地还能 Read 吗？

能。它只关闭本地写方向，读取方向仍可用，直到对端关闭发送方向或连接发生错误。

服务端收到 FIN 就应该立刻 Close 吗？

不应该一概而论。若协议是半关闭请求，服务端应先读完请求、校验内容，再写回响应；只有协议明确要求结束连接时才调用 Close。

为什么抓包里数据和 FIN 看起来很接近？

发送缓冲和 TCP 分段由系统处理，数据与 FIN 的报文边界不应当被应用代码当成固定时序。应用层只应依赖 Read 返回的数据、EOF 和错误语义。