uintptr是Go中唯一能与指针双向无损转换的整数类型，需经unsafe.Pointer中转，仅支持指针算术，不参与GC追踪，滥用将导致内存安全风险。
Go 中 uintptr 是唯一能和指针双向转换的整数类型
Go 语言禁止直接把 *int 转成 int 或 int64，编译器会报 cannot convert *int to int。真正能和指针做无损转换的，只有 uintptr——它不是普通整数，而是“足够存下任意指针值”的无符号整数类型，大小和平台指针一致（32 位系统是 4 字节，64 位是 8 字节）。
常见错误是试图用 int 接收指针地址：
ptr := &x n := int(ptr) // 编译失败：cannot convert ptr (type *int) to type int
正确做法是先转 uintptr，再按需转其他整数类型（但要注意后续用途）：
-
uintptr(unsafe.Pointer(ptr))是标准转换路径，unsafe.Pointer是指针的“通用中间态” - 如果只是打印地址或做简单算术（比如计算结构体字段偏移），
uintptr本身够用 - 若必须转
int64（例如传给 C 函数或日志记录），可显式转换：int64(uintptr(unsafe.Pointer(ptr)))，但要确保目标平台不会溢出
转回去时必须用 unsafe.Pointer 中转，不能跳步
从整数还原指针，Go 要求严格两步：整数 → uintptr → unsafe.Pointer → 具体指针类型。跳过 unsafe.Pointer 会编译失败：
立即学习“go语言免费学习笔记（深入）”；
n := uintptr(unsafe.Pointer(&x)) p1 := (*int)(n) // 错误：cannot convert n (type uintptr) to type *int p2 := (*int)(unsafe.Pointer(n)) // 正确
这个限制不是为了麻烦，而是让“指针语义”显式暴露在代码里，避免隐式指针操作绕过 GC 安全检查。
- 所有从整数恢复的指针，都必须经过
unsafe.Pointer这一层，这是强制约定 - 转换后的指针类型必须和原始对象匹配，否则读写会触发未定义行为（比如把
*float64当*int用） - 如果原指针指向的是局部变量，且函数已返回，那还原出来的指针就是悬空指针，访问会 panic 或读到垃圾值
真实场景中，90% 的需求其实不需要转整数
多数人想“把指针变数字”，其实是为调试、日志、哈希或跨 FFI 传参。但 Go 提供了更安全的替代方案：
- 打印地址用
fmt.Printf("%p", ptr)，它内部处理了uintptr转换，无需手动干预 - 做对象唯一标识？用
fmt.Sprintf("%p", ptr)得到字符串，比整数更便携、无平台差异 - 和 C 交互时，C 函数参数是
void*，Go 侧直接传unsafe.Pointer(ptr)，根本不用转整数 - 想计算内存布局？用
unsafe.Offsetof和unsafe.Sizeof，它们返回uintptr，但不涉及运行时指针转换
一旦开始手动转 uintptr，你就主动放弃了 Go 的内存安全保护。GC 不再追踪该地址，也不会阻止它被回收。
uintptr 不是整数，它没有算术意义
uintptr 看起来像整数，但 Go 明确规定：它只用于存储指针地址，**不支持指针算术以外的数学运算**。比如加减常量可能合法（如 p + unsafe.Offsetof(s.field)），但乘除、位运算、比较大小（除了 == !=）都属于未定义行为。
-
u := uintptr(unsafe.Pointer(&x)); u2 := u + 4—— 可能合法，但仅当你知道&x后面确实有 4 字节可用空间 -
u * 2或u & 0xFF—— 编译器不报错，但结果不可靠，不同版本或平台行为可能不同 -
uintptr值不能保存到全局变量或 map 中长期持有，因为 GC 无法识别它是“活着的指针”，对应内存可能被回收
真正难的从来不是怎么转，而是转完之后——你得自己保证那个地址还有效、对齐、可访问，而且整个过程不能被编译器优化掉。这些细节，没人替你兜底。
