complex64实部虚部各占32位，complex128各占64位；前者无法精确表示math.Pi等float64常量，且标准库复数函数仅支持complex128，C互操作或高性能场景才需用complex64。
complex64 和 complex128 的底层区别到底在哪
它们不是“精度更高就好”的关系，而是和 float32 / float64 严格对齐的：前者实部虚部各占 32 位，后者各占 64 位。这意味着 complex64 的实部不能精确表示 math.Pi（它本身是 float64 常量），强制转换会截断。
常见错误现象：z := complex64(3.1415926 + 2i) 编译失败——Go 不允许浮点字面量直接转 complex64，因为字面量默认是 complex128 类型。
- 正确写法是
z := complex64(complex(3.1415926, 2))或更安全地用complex(float32(3.1415926), float32(2)) - 如果参与计算的变量已经是
float32，优先用complex32(a, b)构造，避免隐式升格再降格带来的精度损失 - 标准库中几乎所有复数函数（如
cmplx.Abs、cmplx.Exp）都只接受complex128；传complex64会触发自动转换，但你得清楚这步发生了
什么时候必须用 complex128
当你调用 math/cmplx 包里的函数时，没得选——cmplx.Sqrt、cmplx.Log、cmplx.Pow 全部只定义在 complex128 上。试图传 complex64 会报错：cannot use z (type complex64) as type complex128 in argument to cmplx.Sqrt。
- 工程中若需高性能复数运算（如信号处理批量 FFT），别硬扛着用
cmplx，考虑用gonum.org/v1/gonum/mat等支持complex64的第三方库 - 从 C 互操作（比如调用 FFTW）回来的数据通常是
complex64切片，这时别一股脑转成complex128再算——内存翻倍、缓存不友好，先确认下游是否真需要高精度 -
fmt.Printf("%v", z)对两者输出格式一致，但fmt.Sprintf("%e", real(z))这类单独取实部的操作，类型决定了有效位数
数组/切片里混用 complex64 和 complex128 的坑
它们是完全不同的类型，不能互相赋值，也不能共用同一个切片类型。写 var zs []complex64 = make([]complex128, 10) 直接编译失败。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
立即学习“go语言免费学习笔记（深入）”；
- 接口赋值没问题：
var i interface{} = z32或= z64都行，但反射或类型断言时必须写对具体类型 - JSON 解码默认把复数当
complex128（因为json.Number解析为float64），如果结构体字段是complex64，会解码失败或静默截断——得自定义UnmarshalJSON - 数据库驱动（如
pgx）通常只支持complex128映射，存complex64得手动拆成两个float32字段
性能敏感场景下怎么选
单纯看内存：一个 complex64 占 8 字节，complex128 占 16 字节。在百万级复数切片场景下，差整整 8MB——但这只是表象。
- CPU 指令层面，现代 x86-64 的
AVX复数乘法通常按双精度设计，complex64可能反而要多做 unpack/pack - Go 编译器对
complex128的内联和常量传播更成熟，简单表达式（如z * z + c）用complex128有时更快 - 真正瓶颈往往不在复数类型本身，而在是否触发了逃逸、GC 压力或缓存行对齐——用
go tool compile -S看关键函数汇编，比凭经验猜靠谱
复数类型选型不是非黑即白的事，关键是看上下游约束：标准库锁死 complex128，C 库或嵌入式设备可能只认 complex64，而中间层要不要桥接、怎么桥接，得盯着实际数据流和 profiling 结果来定。
