用 reflect 判断结构体字段是否为指针类型
Go 没有内置语法能直接“看”一个结构体有没有指针字段，得靠 reflect 在运行时检查。核心是遍历结构体所有字段，对每个 Field.Type 调用 Kind() 看是不是 reflect.Ptr。
注意：只检查顶层字段，不递归进嵌套结构体或接口值内部；如果字段是 *T，Kind() 返回 Ptr；如果是 T（非指针），返回对应基础类型如 Struct、Int 等。
- 必须传入结构体的指针（如
&s），否则reflect.ValueOf(s)得到的是不可寻址的副本，Type()虽可用但字段遍历逻辑易错 - 用
reflect.TypeOf((*YourStruct)(nil)).Elem()可以安全获取结构体类型，避免空值 panic - 字段是接口类型（如
interface{}）时，Kind()是Interface，不是Ptr，即使它背后存了个指针——这属于值层面的动态行为，静态检查无法覆盖
静态分析：用 go vet 或 staticcheck 发现潜在指针误用
go vet 本身不报“结构体含指针”，但它会揪出指针相关的典型问题：比如对非指针接收者方法调用取地址、sync.WaitGroup 字段未取地址传参、json.Unmarshal 传非指针等。这些错误往往暴露了本该用指针却忘了加 & 的结构体字段。
staticcheck 更进一步，能识别像 struct{} 字段被声明为指针（*struct{}）这种明显冗余写法，也支持自定义规则检查特定字段名是否应为指针（比如以 Config 结尾的字段强制要求是指针）。
立即学习“go语言免费学习笔记（深入）”；
- 运行
go vet -tags=dev ./...时确保构建标签一致，否则条件编译掉的字段会被忽略 -
staticcheck默认不检查未导出字段，如需覆盖，得在配置中显式启用checks: ["all"]并确认unused类规则不影响判断逻辑 - 这类工具查的是代码模式，不是类型结构——它们不会告诉你 “这个 struct 有 3 个指针字段”，而是 “这里用了指针但可能没初始化”
编译期断言：用空接口 + 类型断言模拟“编译时检测”
如果你真正关心的是“某结构体能否安全传给一个只接受指针的函数”，可以用类型约束或空接口配合断言，在调用前快速失败。这不是检测“是否含指针”，而是检测“是否满足指针使用契约”。
例如函数要求输入必须是 *T，你传了 T，Go 编译器直接报错；但若函数接收 interface{} 再内部转 *T，就只能靠运行时判断。这时可加一层包装：
func MustBePtr[T any](v T) *T {
return &v
}
它强制调用方显式传值并取地址，把潜在错误提前到调用点。
- 不要在库函数里对
interface{}做reflect.Value.Kind() == reflect.Ptr判断后自动解引用——这会让调用行为不透明，且掩盖原始意图 - 如果结构体字段是
map[string]*T，reflect查到的是Map类型，不是Ptr；要深入 value 类型得再调用Elem()，容易漏层 - 生成代码（如 protobuf 或 SQL ORM）产生的结构体，字段指针性高度固定，适合写脚本扫描
.go源文件正则匹配\*\w+，比运行时reflect更快更准
为什么不能只看 unsafe.Sizeof 或内存布局来判断
unsafe.Sizeof(T{}) 返回的是结构体实例大小，和字段是否指针无关——*int 和 int 在 64 位系统上都占 8 字节，unsafe.Sizeof 完全无法区分。
有人试过对比 unsafe.Offsetof(t.field) 和字段类型对齐要求，但这依赖具体编译器实现，Go 不保证 ABI 稳定，且嵌入字段、填充字节会让偏移量失去指针标识意义。
- 结构体含指针会影响 GC 扫描行为（触发栈/堆对象标记），但这是运行时细节，无法通过静态值推导
- JSON 序列化时
omitempty对指针字段的零值处理（nil不输出）常被误认为“检测指针的方法”，其实只是序列化逻辑，和类型本身无关 - 真正容易被忽略的是：字段是
func()、chan int、map[string]int这类引用类型，它们底层也是指针，但reflect.Kind()返回的是Func/Chan/Map，不是Ptr——别只盯着Ptr忽略其他引用类型
