Go 不允许在函数签名中直接使用 func(T) U 作为参数类型，必须先用 type 声明具名函数类型（如 Mapper[T, U]），这是为提升可读性、复用性与可维护性；slices.Map 不支持 nil 切片且无法流式处理，自定义泛型 Map 可弥补此缺陷；nil 函数参数需显式校验，否则调用即 panic。
为什么不能直接用 func([]T, func(T) U) []U 定义泛型 Map？
Go 编译器不允许在函数签名里裸写 func(T) U 这种类型字面量作为参数——它会报错 syntax error: unexpected func, expecting type。你必须先用 type 声明一个具名函数类型，否则连编译都过不去。
这不是语法限制，而是 Go 的设计选择：强制你为行为命名，提升可读性和复用性。比如 type Mapper[T, U any] func(T) U 比匿名写法更清晰，也方便在多个地方统一约束或 mock。
-
Mapper[T, U]可用于多个泛型函数（Map、MapInPlace、测试桩） - 单元测试中可传入固定返回值的
Mapper，无需改业务逻辑 - 如果后续要加日志或指标埋点，只需改
Mapper类型定义，不碰调用方
slices.Map 和自己写的泛型 Map 有什么实际区别？
slices.Map 是 Go 1.23+ 标准库提供的官方实现，类型安全、性能好、不修改原切片，但它有两个硬限制：不支持 nil 切片，且要求输入切片长度已知（无法流式处理）。你自己写的泛型 Map 可以补上这些缺口。
- 手动实现时可加
if slice == nil { return nil }处理空切片，避免 panic - 若需兼容旧版 Go（
- 标准库
slices.Map返回新切片，但如果你需要原地转换（如大结构体避免拷贝），只能自己写MapInPlace - 性能上差异极小，但自己实现可加 trace 或采样逻辑，标准库做不到
泛型 Filter + Map 组合时，如何避免重复遍历？
链式调用 Filter(...).Map(...) 看起来简洁，但默认会遍历两次：一次过滤，一次映射。除非你用切片构造器（如 type Slice[T] []T）封装成支持惰性求值的类型，否则 Go 没有内置 lazy list 支持。
立即学习“go语言免费学习笔记（深入）”；
- 最简方案是合并逻辑：写一个
FilterMap[T, U any](slice []T, f func(T) (U, bool)) []U，单次遍历中决定是否保留并转换 - 示例：只对正数做平方
FilterMap(nums, func(n int) (int, bool) { if n > 0 { return n * n, true }; return 0, false }) - 注意返回的
bool是保留标志，不是错误；U值在bool==false时被忽略，不进结果 - 别试图用闭包缓存中间结果——Go 不会自动优化多层嵌套调用，反而增加 GC 压力
传入的函数参数为 nil 时，程序直接 panic 怎么办？
Go 不做隐式空值防护，transform 或 predicate 为 nil 时，调用瞬间就 panic。这在动态配置策略、插件化场景下特别危险——你无法控制调用方传什么。
- 所有高阶函数入口必须显式检查：
if transform == nil { panic("transform function is nil") }或返回 error - 不要依赖“使用者不会传 nil”这种假设；HTTP 中间件、规则引擎等场景，nil 往往代表“跳过”，此时应走默认分支而非 panic
- 泛型函数内联后，
nil函数调用仍 panic，所以校验必须放在泛型函数体内部，不能只靠外部保障 - 如果函数参数允许为空（如可选回调），那就定义成指针类型
*Mapper[T,U]并判空，而不是让调用方传nil func
真正卡住人的从来不是语法能不能写出来，而是想清楚：哪个逻辑该暴露为参数、哪个状态该锁进闭包、谁来对 nil 负责、以及要不要为一次额外的遍历换可读性。这些决策藏在类型定义和空值处理里，不在 for 循环的括号中。
