Go复数类型为complex64和complex128，字面量如3+4i默认complex128且必须用i后缀；real/imag恒返float64；cmplx包函数仅支持complex128；复数不可大小比较，需转模长等标量。
复数类型声明和初始化写法容易出错
Go 的复数不是内置关键字，而是两种具体类型：complex64 和 complex128，分别对应 float32+float32 和 float64+float64。直接写 z := 3 + 4i 是合法的，但它的类型是 complex128，且必须带 i 后缀 —— 写成 3i 或 4i 没问题，但 3 + 4j 或 3 + 4I 都会编译失败。
常见错误现象：undefined: i（误以为 i 是变量）、cannot use ... as complex64 value（混用类型）。
-
z1 := 1.5 + 2.5i→ 推导为complex128 -
z2 := complex(1.5, 2.5)→ 同样是complex128，参数是 float64 -
z3 := complex64(complex(1.5, 2.5))→ 显式转成complex64，但要注意精度损失 - 不要用
var z complex64 = 1 + 2i—— 字面量1 + 2i默认是complex128，类型不匹配
real() 和 imag() 函数返回的是 float64，不是原类型
无论输入是 complex64 还是 complex128，real(z) 和 imag(z) 返回的永远是 float64。这在做数值比较或传给只接受 float32 的函数时容易埋坑。
使用场景：提取实部虚部后做后续计算，比如画复平面图、判断模长、做 FFT 前预处理。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
z := complex64(1.2 + 3.4i)→real(z)返回1.2（float64），不是float32 - 如果需要
float32，得手动转：float32(real(z))，但注意舍入 - 模长计算别手写
sqrt(real(z)*real(z) + imag(z)*imag(z))，直接用cmplx.Abs(z)更准（它内部处理了溢出和精度）
math/cmplx 包里常用函数的参数类型陷阱
math/cmplx 包所有函数（如 cmplx.Sin、cmplx.Exp、cmplx.Sqrt）只接受 complex128，不支持 complex64。这是 Go 的设计选择，没有重载，也没有泛型自动适配（截至 Go 1.22）。
性能影响：强制转换会带来微小开销；兼容性影响：如果你的数据源是 complex64 切片（比如从二进制文件读取的 DSP 数据），每次调用前都得遍历转一遍。
-
z64 := complex64(1 + 1i)→cmplx.Sin(z64)编译失败 - 正确写法：
cmplx.Sin(complex128(z64)) - 批量处理时，建议一开始就用
complex128，除非内存敏感（比如百万级复数数组且明确 float32 精度够用） -
cmplx.Polar返回float64模长和弧度角，不是complex128—— 它是反向拆解函数
复数比较只能用 == 和 !=，不能用 > = 等
复数在数学上没有自然序关系，Go 语言也禁止对复数使用大小比较操作符。试图写 z1 > z2 会直接报错：invalid operation: z1 > z2 (complex type)。
使用场景：常出现在条件过滤（比如只保留模长大于某值的复数）、排序、找极值等逻辑中。
- 要比较“大小”，得先转成标量：比如用
cmplx.Abs(z)得到模长再比 -
z1 == z2是合法的，按实部和虚部逐个 float 比较（注意浮点误差！） - 安全比较相等应避免直接
==，改用cmplx.Abs(z1 - z2) - 排序复数切片需自定义
sort.Slice，例如按模长升序：sort.Slice(zs, func(i, j int) bool { return cmplx.Abs(zs[i])
复数运算本身不难，真正卡住人的往往是类型隐式转换规则和浮点精度边界。尤其是混合使用 complex64 和 complex128 时，编译器不会帮你“猜意图”，而运行时又不会报精度错 —— 结果偏差可能悄悄累积几轮才暴露。
