go 不支持指针算术，p + 1 等操作编译直接报错，因其将指针视为不可运算的引用凭证；unsafe.add 是唯一合法偏移方式，但需手动计算字节偏移、确保内存合法与对齐，且所有 unsafe 操作均由开发者承担全部安全责任。
Go 语言根本不支持指针算术——p + 1、p++ 这类写法在编译期就会报错，不是“绕不过”，而是压根没这扇门。所谓“黑魔法”其实是误读，真正能动的只有 unsafe 包提供的有限接口，且每一步都自带风险。
为什么 p + 1 直接编译失败
这不是语法糖缺失，而是 Go 编译器主动拦截。它把指针视为不可运算的引用凭证，而非内存地址整数。这种设计直接堵死了越界访问、非法偏移等常见 C 风格错误路径。
-
invalid operation: p + 1 (mismatched types *int and int)是最典型的报错，说明类型系统在源头拒绝混合运算 - 即使你用
uintptr强转再加减，也必须立刻转回unsafe.Pointer，中间多存一行变量就可能触发 GC 误回收 - 现代编译器对
for i := range s { s[i] }的优化已足够好，手动指针遍历既不安全也不更快
unsafe.Add 是唯一合法偏移入口（Go 1.17+）
它替代了过去危险的 uintptr(p) + offset 手写模式，语义明确、不易漏掉类型转换，但前提是：偏移量单位是字节，不是元素个数。
- 想从
*int移动到下一个int，得写unsafe.Add(p, unsafe.Sizeof(int(0)))，不能想当然除以 8 - 目标地址必须落在合法内存范围内，
unsafe.Add不做任何边界检查，越界后行为未定义 - 若只是想取一段连续内存为切片，优先用
unsafe.Slice，它内部处理了对齐和 GC 可见性，比手造reflect.SliceHeader安全得多
结构体字段访问必须用 unsafe.Offsetof
字段偏移不是靠字段顺序“猜”出来的，而是由编译器根据对齐规则决定的。手算偏移等于在赌平台、版本和字段排列。
-
unsafe.Offsetof(s.field)返回的是编译期常量，安全可靠 - 拿到偏移后，仍需验证地址对齐，例如读
*int64前检查(uintptr(unsafe.Pointer(&s)) + offset) % 8 == 0 - 字段解引用前，还得确保该 struct 实例生命周期足够长——栈上局部变量被 GC 复制到堆后，旧地址立即失效
真正容易被忽略的不是怎么写，而是“为什么非得这么麻烦”：因为 Go 把内存安全当第一优先级，所有 unsafe 操作都要求开发者自己承担全部责任——包括对齐、生命周期、并发访问、GC 可见性。一旦漏掉其中一环，问题不会立刻暴露，而是在特定负载、特定构建模式或特定 GC 周期下突然崩溃。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
