Go io.CopyN 从网络连接复制固定块时怎么处理超时

用 Go 从网络连接接收一个固定大小的数据块时，io.CopyN 只负责“最多复制 n 个字节”，不会替你解决网络一直不发数据的问题。实用的判断是：written == n && err == nil 才算完整；连接的时间边界要提前用 SetReadDeadline 设置；如果超时只复制了一部分，除非协议支持从明确偏移续传，否则应丢弃这半块并重新获取。

先把完整数据块的判断条件写死

io.CopyN(dst, src, n) 返回实际写入的字节数和复制期间最早出现的错误。官方契约是：返回时 written == n 当且仅当 err == nil。如果源连接提前关闭，复制量小于 n 且没有更具体的错误，常见结果是 io.EOF；如果底层网络读先超时，调用方应保留这个错误。

func copyBlock(dst io.Writer, src io.Reader, size int64) error {
	// written 是已经交给目标 Writer 的字节数，不能只看 err。
	written, err := io.CopyN(dst, src, size)
	if written != size {
		// 半块不能继续按完整协议解析，保留实际数量便于排查。
		return fmt.Errorf("short block: written=%d expected=%d err=%w", written, size, err)
	}
	if err != nil {
		// 写满但仍有错误时也按失败处理，避免吞掉底层故障。
		return fmt.Errorf("copy block: %w", err)
	}
	return nil
}

这里的目标可以是临时缓冲区、文件或消息存储，但成功门槛相同。实际项目还应把块编号、请求 ID 和远端地址放进错误上下文，方便区分源不足、超时和目标写失败。

在 io.CopyN 前给网络读设置时间边界

net.Conn.SetReadDeadline 设置的是一个绝对时间，影响后续和当前阻塞中的读操作；时间到了以后，读方法会返回包装了 os.ErrDeadlineExceeded 的错误。它不是“本次 Read 调用再等 3 秒”的隐式计时器，所以每个数据块开始前要明确这 3 秒属于整块预算，还是属于下一次空闲等待。

func copyWithDeadline(conn net.Conn, dst io.Writer, size int64, wait time.Duration) error {
	// 这个 deadline 给整块复制一个绝对时间上限。
	if err := conn.SetReadDeadline(time.Now().Add(wait)); err != nil {
		return fmt.Errorf("set read deadline: %w", err)
	}

	written, err := io.CopyN(dst, conn, size)
	if err != nil {
		// DeadlineExceeded 只说明读被时间边界打断，还要结合 written 判断半包。
		if errors.Is(err, os.ErrDeadlineExceeded) {
			return fmt.Errorf("block timeout after %d/%d bytes: %w", written, size, err)
		}
		return fmt.Errorf("copy from connection after %d/%d bytes: %w", written, size, err)
	}
	if written != size {
		// 无错误但没写满，通常是源提前结束，不能当作成功。
		return fmt.Errorf("incomplete block: %d/%d bytes", written, size)
	}
	return nil
}

调用方最好在连接关闭前再设置一次不需要的 deadline，或由连接的生命周期统一管理；不要因为上一块设置过很近的绝对时间，就让下一块在一开始立即超时。

超时后不要从半块当前位置盲目重试

超时发生时，written 可能已经大于零。对于压缩块、消息帧、文件头这类必须完整的数据，半块不能直接交给下一层。更稳妥的做法是把本次目标写入临时缓冲或临时文件，只有完整复制后才提交；重试时重新建立连接并从协议允许的起点请求。

只有协议明确提供“块编号 + 偏移 + 可续传”的语义，才可以把已收到的字节交给续传逻辑。TCP 本身保证字节顺序，不代表业务消息已经完整，也不代表重新拨号后从当前位置继续读是安全的。

固定总时限和空闲超时要分开设计

如果需求是“这个块最多占用 5 秒”，在 CopyN 前设置一次 deadline 即可；如果需求是“只要每 2 秒收到一点数据就继续”，则需要在每次成功读取后刷新 deadline。直接把整次读取的 deadline 不断延后，会失去总时限；完全不刷新，又可能把慢但持续有数据的连接误判为超时。

无论采用哪种策略，都建议将 SetReadDeadline、io.CopyN、errors.Is 和临时结果提交放在同一个边界函数中。这样超时处理不会散落在业务代码里，也不会因为忘记检查 written 而留下难以复现的半包问题。

常见问题

io.CopyN 超时后能不能继续调用一次 CopyN？

只有协议明确允许从当前偏移继续，且 Reader 仍代表同一条可恢复数据流时才可以。普通请求更安全的做法是丢弃半块，重新建立连接并从块起点获取。

SetDeadline 和 SetReadDeadline 怎么选？

只限制读操作时用 SetReadDeadline；需要同时限制读写时用 SetDeadline。两者设置的都是绝对时间，并会影响对应的阻塞 I/O。

written 等于 size 但 err 不为空怎么办？

仍按失败处理。固定块的提交条件要求错误为空；保留错误并检查目标 Writer 或关闭阶段，不要只凭长度提交。