go 中 func 类型变量不能直接用 == 比较，因函数值非可比较类型，编译期报错；唯一可行的运行时地址比较需用 reflect.value.pointer()，但闭包函数无效。
Go 中 func 类型变量不能直接用 == 比较
Go 语言明确禁止对函数值（func 类型）使用相等操作符，编译期就会报错：invalid operation: cannot compare func values。这不是疏漏，而是设计选择——函数值在 Go 中不是可比较类型，哪怕它们指向同一个函数、甚至同一段代码。
常见错误现象：写 if f1 == f2 { ... } 直接编译失败；或试图把 func 放进 map 作 key、塞进 struct 后做 == 判断，同样会卡在编译阶段。
- Go 规范中只有少数内置类型支持
==：数值、字符串、布尔、指针、channel、interface（当底层值可比较时）、数组（元素可比较）、结构体（所有字段可比较） -
func不在其中，且没有计划加入 —— 官方认为“函数是否‘相同’”语义模糊：是看地址？看闭包捕获的变量？看源码位置？Go 选择不定义 - 即使两个函数字面量完全一样，如
func(){} == func(){}，也非法；哪怕都赋给同名变量再比，照样报错
想判断“是不是同一个函数”，得用 reflect.Value.Pointer()
如果目标确实是「运行时是否指向同一份函数代码」（忽略闭包差异），唯一可行路径是通过反射取函数值的底层指针。注意：这仅对顶层函数、方法表达式、或未携带闭包的函数字面量有效；一旦涉及闭包，每个实例都是独立对象，Pointer() 必然不同。
使用场景：调试钩子注册、避免重复回调绑定、单元测试中验证 handler 是否被正确赋值。
立即学习“go语言免费学习笔记（深入）”；
- 必须先用
reflect.ValueOf(f).Pointer()获取函数入口地址，返回uintptr - 不能直接对
reflect.Value用==，要转成整数再比 - 若函数是方法值（如
obj.Method），Pointer()返回的是包装后的函数地址，与原始方法不等价 - 示例：
func hello() {} f1 := hello f2 := hello p1 := reflect.ValueOf(f1).Pointer() p2 := reflect.ValueOf(f2).Pointer() fmt.Println(p1 == p2) // true
带闭包的函数无法可靠比较，别硬试
闭包函数（比如 func() { x++ } 或捕获了局部变量的匿名函数）每次调用都会生成新实例，即使逻辑一致、捕获相同变量，其底层运行时表示也完全不同。此时 Pointer() 比较必然为 false，且毫无意义。
常见误用：想用反射指针判断两个 handler 是否“功能相同”，结果发现永远不等——因为它们是不同闭包实例。
- Go 不提供任何机制获取闭包捕获的变量内容或结构，所以无法做语义级比较
- 若业务真需区分闭包行为，应改用显式结构体封装状态 + 方法，让结构体本身可比较
- 例如：把
func(int) int替换为type Op struct{ Base int; Shift int }，然后实现Apply(x int) int方法 - 强行对闭包函数做
Pointer()对比，只会得到稳定但无业务价值的false
替代方案：用标识符或接口抽象代替函数指针比较
真正需要“判断函数是否相同”的场景，往往暴露了设计问题。更健壮的做法是放弃比较函数值本身，改用可比较的标识。
使用场景：插件系统、事件分发器、中间件链管理。
- 给每个函数分配唯一
string名或intID，在注册/调用时传入并比对 - 定义接口如
type Handler interface{ Name() string; ServeHTTP(...) }，让实现者控制相等逻辑 - 用
sync.Map存储函数时，key 用描述性字符串而非函数本身 - 性能上，字符串比较远快于反射；兼容性上，不依赖
unsafe或内部实现细节
函数值不可比较不是缺陷，是 Go 推动你把意图显式化。一旦开始纠结两个 func 是否相等，大概率该重构的是调用关系，而不是找绕过限制的 hack。
