len()和cap()是编译器内置原语，直接读取slice头的len/cap字段，不经过方法调用机制；unsafe.SliceHeader只是描述slice头的值类型结构体，修改其字段不影响原slice。
为什么 len() 和 cap() 不需要指针接收器
因为它们根本不是方法，也不是任何类型的成员函数——它们是编译器内置的**原语操作**，直接作用于底层 slice 的运行时表示（即 struct { ptr unsafe.Pointer; len, cap int }），不经过任何方法调用机制。
你写 len(s)，Go 编译器当场就把它替换成对 s.len 字段的读取；同理 cap(s) 就是读 s.cap。没有函数栈帧、没有接收器传递、甚至没有实际的函数符号生成。
-
len()和cap()不能被重载，也不能定义在自定义类型上（除非是别名且底层是 slice） - 即使你把 slice 变量声明为指针（
*[]int），也必须先解引用才能用len()：写成len(*p)，而不是len(p) - 它们对
nilslice 安全：len(nil)返回0，不会 panic
unsafe.SliceHeader 是值类型，但为什么能“看到”底层数组
因为 unsafe.SliceHeader 本身只是三个字段的结构体（Data, Len, Cap），它不持有数据，只持有指向数据的指针和长度信息。当你用 unsafe.SliceHeader 去“构造”一个 slice，本质是告诉 Go 运行时：“请按这个地址和长度，给我一个合法的 slice 头”。
所以它是不是值类型不重要——重要的是你填进去的 Data 字段是否有效、是否仍在内存中、是否有权限访问。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 从
[]byte转unsafe.SliceHeader是安全的（只要不逃逸或越界） - 但反过来，用任意整数当
Data填进去，然后转成 slice —— 运行时不会拦你，但访问时大概率panic: runtime error: invalid memory address -
unsafe.SliceHeader没有指针接收器，因为它压根不是接口或 struct 方法；它只是个搬运工规格说明书
常见误用：以为改 unsafe.SliceHeader 能改变原 slice
不能。修改一个 unsafe.SliceHeader 的字段，只影响那个局部变量，不会反射回原来的 slice。slice 本身是值类型，赋值即复制头信息（ptr/len/cap），但底层数组内存没动。
比如你把一个 []int 转成 unsafe.SliceHeader，改它的 Len，再转回去——看起来像“截断”，但其实只是新建了一个 slice 头，原 slice 毫发无损。
- 真正影响原 slice 的唯一方式是通过 slice 表达式（如
s[1:]）或append() - 用
unsafe.SliceHeader手动构造 slice 时，Cap若大于实际可用容量，后续append()可能覆盖相邻内存，引发静默错误 - 在 Go 1.21+ 中，
unsafe.Slice()替代了手撸unsafe.SliceHeader，更安全、更直观
什么时候必须关心 len 和 cap 的底层一致性
主要在零拷贝场景：比如网络包解析、内存池复用、或对接 C 函数时需要把 Go slice 当作连续内存块传出去。这时 len 决定逻辑长度，cap 决定还能往里写多少而不 realloc。
-
cap小于len是非法状态，运行时不会允许（构造不出） - 但
cap远大于len时，append()可能复用底层数组，也可能触发扩容——取决于当前cap是否够用 - 用
make([]T, l, c)显式指定cap，比先make([]T, l)再append更可控，尤其在避免意外扩容时
unsafe 相关代码时，心里得清楚：你在绕过类型系统，而 Go 的运行时不会帮你检查指针有效性。 
