必须采用流式序列化而非 gob 或 encoding/binary.Write 全量加载：先写长度头，再用 unsafe.Slice 获取数值数组字节视图分块写入，结构体切片需手动展开字段并处理对齐，HTTP 传输应使用自定义 io.Reader 避免内存副本。
直接用 gob 或 encoding/binary.Write 处理超大规模数组（比如 100MB+ 的 []int64 或结构体切片）极易触发 OOM 或严重 GC 压力——根本原因不是“不会写”，而是默认序列化路径会一次性把整个数组加载进内存再编码。必须绕过中间缓冲，走“边序列化边写入”的流式路径。
为什么不能直接用 gob.Encoder 写大数组？
gob.Encoder 本身支持流式，但常见误用是先写进 bytes.Buffer 再整体写文件或网络连接。这等于又建了一次全量内存副本。更隐蔽的问题是：gob 对切片的编码会递归写入每个元素，且带类型头和长度字段，对纯数值数组来说冗余极大、速度慢、体积膨胀明显。
- 典型错误：用
bytes.Buffer接收gob.Encoder输出，再调buf.Bytes()—— 这一步就已把全部数据拷进内存 - 真实瓶颈：即使你用
os.File直接接gob.NewEncoder，gob内部仍会对大 slice 做多次小块 write，底层 syscall 频繁，吞吐受限 - 兼容性代价：gob 不跨语言，无法用于和 Python/JS 服务交互；升级 Go 版本后旧 gob 数据可能无法解码
手动实现流式数值数组写入器（以 []float64 为例）
核心思路：跳过所有反射和元数据，用 binary.Write 分块写入原始字节，配合 io.Writer 接口直接落盘或发 HTTP body。
- 先写长度头（
uint64，8 字节），避免读端无法预分配 - 用
unsafe.Slice(unsafe.Pointer(&data[0]), len(data)*8)获取底层数组字节视图（仅限数值类型且已确认非 nil） - 调
io.Copy或循环w.Write()分批写入，每批控制在 64KB–1MB，平衡 syscall 开销与内存驻留 - 不依赖
gob或json，无 GC 压力，写入速度接近磁盘/网络极限
func WriteFloat64Array(w io.Writer, data []float64) error {
if err := binary.Write(w, binary.LittleEndian, uint64(len(data))); err != nil {
return err
}
if len(data) == 0 {
return nil
}
// 注意：仅适用于已知连续内存的数值切片
buf := unsafe.Slice(unsafe.Pointer(unsafe.Slice(&data[0], 1)[0]), len(data)*8)
_, err := w.Write(buf)
return err
}
结构体切片的流式序列化：必须显式展开字段
对 []MyStruct，encoding/binary 不能直接写切片——它不处理 slice header。你必须手动遍历，并为每个 struct 字段逐个写入，同时严格控制顺序、大小端和填充。
立即学习“go语言免费学习笔记（深入）”；
- 禁止使用匿名字段，否则字段顺序不可控
- 字符串/切片字段必须前置长度字段（如
uint16），再写内容字节，不能直接binary.Write(r, &s.Msg) - 若 struct 含
int32+byte，需手动补 3 字节 padding 或用#[repr(packed)]思路（Go 中靠unsafe或手写 offset 计算） - 推荐封装成
MarshalTo(w io.Writer) error方法，而非全局函数，便于版本演进
HTTP 请求中流式发送大数组：别碰 bytes.Buffer
想 POST 一个 200MB 的浮点数组？不要把它塞进 bytes.Buffer，而应让 HTTP client 直接消费一个自定义 io.Reader。
- 实现
Read(p []byte) (n int, err error)，内部按需从数组切片中拷贝数据到p - 每次只读取当前
p容量能容纳的部分，维护一个偏移量游标 - 在
http.NewRequest中直接传入该 reader，client 会分块调Read，全程零额外内存副本 - 务必设置
Content-Length头（可提前算好：8 + len(data)*8），否则 HTTP/1.1 会退化为 chunked 编码，增加服务端解析负担
真正难的不是“怎么写”，而是判断哪些环节必须放弃抽象（比如不用 gob）、哪些地方必须自己管理内存布局（比如结构体字段对齐）、以及什么时候该主动控制 buffer size 而不是依赖默认值——这些细节一旦漏掉，性能差距就是十倍起跳。
