Go不支持C风格动态数组，*[]T非正确解法；应优先用[]T切片或封装结构体，仅在对接C、零拷贝等特定场景才用unsafe+CGO手动管理内存。
Go 语言原生不支持通过指针直接模拟 C 风格的动态数组（比如 malloc + realloc + 指针算术），强行用 *[]T 或 *[N]T 管理“动态”内存不仅危险、易崩溃，而且违背 Go 的内存管理哲学。
为什么 *[]T 不是动态数组的正确解法
常见误区是声明一个指向切片的指针：ptr := &[]int{1,2,3}。这其实只是对一个底层数组已分配好的切片变量取地址，*ptr 仍是普通切片，扩容仍会生成新底层数组，原指针所指内容可能失效；更严重的是，它无法控制底层内存布局，也不能像 C 那样做指针偏移计算（ptr[i] 在 Go 中对 *[]T 不合法）。
真正需要的，通常是以下场景之一：
- 需在函数间共享并动态增长的数据容器（用
[]T本身即可，无需指针） - 需与 C 代码交互、手动管理连续内存块（用
unsafe.Pointer+C.malloc） - 实现自定义内存池或紧凑结构体数组（用
reflect.SliceHeader+unsafe，但极度危险）
安全替代方案：用切片 + 指针传递实现“共享可修改”
99% 的所谓“动态数组管理”，实际只需让多个函数能共同读写同一份数据——这时传 *[]T 是错的，正确做法是传 []T（切片本身含指针、长度、容量，是引用语义），必要时再加一层封装：
立即学习“go语言免费学习笔记（深入）”；
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
type IntList struct {
data []int
}
func (l *IntList) Append(x int) {
l.data = append(l.data, x) // 修改内部切片，调用方可见
}
func (l *IntList) At(i int) int { return l.data[i] }
关键点：
- 函数接收
*IntList是为了修改其内部字段，不是为了“模拟指针数组” -
append可能更换底层数组，但IntList.data字段会自动更新，外部无感知 - 绝不要对外暴露
*[]int类型，也不要用unsafe.Slice去“伪造”数组视图（Go 1.17+ 的unsafe.Slice仅用于从unsafe.Pointer构造切片，非动态扩容工具）
真要手管内存？必须用 unsafe + C，且只限特定场景
例如对接 C 库、实现零拷贝网络 buffer、或嵌入式受限环境。此时步骤严格：
- 用
C.CBytes或C.malloc分配原始内存 - 用
unsafe.Slice（Go 1.17+）或reflect.SliceHeader（旧版）构造临时切片视图 - 扩容需手动
C.realloc+ 复制数据 + 重构造切片，且必须确保旧内存不再被访问 - 最后必须调用
C.free，否则泄漏
示例（极简示意，生产环境需错误检查和生命周期管理）：
ptr := C.CBytes(make([]byte, 10)) defer C.free(ptr) // 转为 Go 切片视图 data := unsafe.Slice((*byte)(ptr), 10) // 扩容：申请新内存，复制，释放旧内存 newPtr := C.CBytes(append(data, make([]byte, 5)...)) C.free(ptr) ptr = newPtr data = unsafe.Slice((*byte)(ptr), 15)
注意：unsafe.Slice 不分配内存，只解释指针；任何越界访问或提前 free 都会导致 panic 或 undefined behavior。
真正难的从来不是“怎么让指针变长”，而是判断是否真的需要绕过 Go 的切片机制——绝大多数业务逻辑里，老老实实用 []T 和 append，配合结构体封装，既安全又高效。一旦引入 unsafe，所有内存安全假设都得自己重新验证，包括 GC 是否还能追踪到那块内存。
