泛型数学函数必须带约束而非直接用any，因为+、-等运算符并非所有类型都支持；若用[t any]，编译器会报“operator + not defined on t”，需通过interface{~int|~float64}等约束确保编译期类型安全。
泛型数学函数为什么必须带约束，而不是直接用 any
因为数学运算符（+、-、*、/、 等）在 Go 中不是所有类型都支持。如果写成 <code>func Sum[T any](a, b T) T，编译器会报错：invalid operation: a + b (operator + not defined on T)。Go 不会在运行时查方法表，它要求在编译期就确认类型支持哪些操作。
所以必须用约束告诉编译器：“这个 T 至少得能加、能比大小”。常见做法是使用标准库的 constraints.Ordered（Go 1.21+）或 constraints.Integer/constraints.Float（旧版需引入 golang.org/x/exp/constraints）。
-
constraints.Ordered：覆盖int、int64、float32、float64、string等可比较且支持四则运算的类型（注意：string支持+但不支持-，实际用时仍需按运算选约束） - 只做加法/求和？用
interface{ ~int | ~int64 | ~float64 }更精准，避免把string也放进来 - 别用
comparable做数值计算——它只保证==和!=，不提供+
Sum 和 Max 的约束差异在哪
Sum 只需要加法能力，Max 需要比较能力，二者约束不能混用。强行复用同一约束会导致编译失败或语义错误。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
Sum[T interface{ ~int | ~int64 | ~float64 }](s []T) T：用~表示底层类型匹配，允许传入[]int或[]int64，但禁止[]string -
Max[T constraints.Ordered](a, b T) T：依赖，所以 <code>string合法，但[]byte不合法（不可比较） - 若对切片求最大值，
MaxSlice[T constraints.Ordered](s []T) (T, bool)必须检查len(s) == 0，否则s[0]panic；返回(T, bool)比返回零值更安全
为什么 Reduce 函数不能用 make([]T, 0) 初始化 accumulator
因为 Reduce 的 accumulator 是单个值（比如累加和），不是切片。写成 acc := make([]T, 0) 会导致类型不匹配，后续 acc = f(acc, s[i]) 编译不过——你不能把一个 T 赋给 []T。
- 正确做法：用
acc := s[0]（非空切片前提下），或用var zero T+ 显式判断空切片 - 不要写
acc := *new(T)：对int是 0，但对自定义结构体可能触发不必要的初始化逻辑 - 如果
f是闭包且捕获了外部变量，注意逃逸分析——高频调用时，泛型版本比interface{}版本更不易逃逸到堆上
泛型数学函数在实际项目里容易踩的三个坑
泛型不是万能胶，尤其在数学计算场景，几个典型问题反复出现：
- 传
nil切片进SumSlice[T constraints.Integer](s []T)会 panic，因为s[0]访问越界；必须先判空，或改用...T变长参数（但会丢失切片长度信息） - 混合类型调用失败：比如
Sum([]interface{}{1, 2.5})无效——泛型要求所有元素是同一底层类型，interface{}切片不满足~int约束 - 性能陷阱：对小数据量（如 2~3 个数），泛型函数调用开销略高于硬编码版本；只有当逻辑复杂、复用频繁、或需保持类型信息（如返回
uint64而非int）时，收益才明显
最常被忽略的是：泛型函数无法推导类型时，错误提示非常模糊，比如 cannot infer T。这时候得回看参数是否全传、有没有 nil、约束里是否漏了某个必要类型（比如忘了加 ~float32）。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
