Go 语言内置函数由编译器硬编码识别，不支持反射调用；需重点掌握 new、make、len、cap、append、copy、clear、close、panic/recover 等核心函数的语义差异与使用边界。
Go 语言没有“内置函数列表”这种全局可查的运行时 API，所有内置函数（builtin）在编译期由编译器硬编码识别，不依赖任何包导入，但也不能反射调用或遍历。真正常用且必须掌握的就那十几个，其余多数只在特定场景下出现（比如 real/imag），盲目罗列反而干扰判断。
什么时候该用 new 而不是 make
new 和 make 都分配内存，但语义和适用类型完全不同，混用会直接编译失败或逻辑出错。
-
new(T)只接受一个类型参数，返回*T，分配并清零整个值——适用于int、struct、[10]int这类值类型，也包括自定义类型 -
make(T, ...)只接受切片（[]T）、映射（map[K]V）、通道（chan T）这三种引用类型；它返回的是初始化后的值本身（非指针），不是地址 - 错误写法：
new([]int)编译报错；make(int, 5)同样报错 - 结构体指针初始化推荐用
&MyStruct{}，比new(MyStruct)更直观，且能带字段初值
len 和 cap 的行为差异与陷阱
len 返回长度，cap 返回容量，但两者对不同类型含义不同，尤其容易在切片扩容和通道读取时误判。
- 对切片：
len(s)是当前元素个数，cap(s)是底层数组从s起始位置到结尾的可用空间大小；cap决定是否触发append分配新底层数组 - 对字符串：
len(s)返回字节数（不是 rune 数），cap(s)不可用（编译错误） - 对 map：
len(m)返回键值对数量，cap(m)不可用 - 对 channel：
len(ch)返回当前缓冲区中待读取元素数，cap(ch)返回缓冲区总容量；注意len(ch)是运行时快照，非原子操作，不能用于同步判断
append、copy、clear 的典型误用点
这三个函数都作用于切片（或 map），但副作用和边界条件差异极大，稍不注意就会覆盖数据或 panic。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
append(s, x)总是返回新切片；原切片变量不变。常见错误是忽略返回值：append(s, 1); fmt.Println(s)—— 输出仍是旧切片 -
copy(dst, src)按最小长度复制，不会自动扩容dst；若dst为nil或长度为 0，复制 0 个元素但不 panic；目标切片必须已分配内存 -
clear(s)（Go 1.21+）将切片所有元素设为零值，但不改变其len和cap；它不释放底层内存，也不等价于s = s[:0]（后者改变长度） - 对 map 使用
clear(m)等价于逐个delete(m, key)，但更高效；注意clear不能用于指针指向的 map 或切片（即clear(&s)非法）
close 和 panic/recover 的并发安全前提
这两个函数看似简单，但在 goroutine 交织场景下极易引发不可预测行为。
-
close(ch)只能由发送方调用，且只能调用一次；对已关闭通道再close会 panic；向已关闭通道发送数据也会 panic，但接收仍可进行直到缓冲区耗尽 -
recover()必须在defer函数中直接调用才有效；如果中间包了其他函数（如defer func() { tryRecover() }()），则无法捕获 panic -
panic不跨 goroutine 传播；在一个 goroutine 中 panic 不会影响其他 goroutine，但若未 recover，整个程序会退出（除非被os.Exit截断） - 不要用
panic处理业务错误（比如文件不存在、网络超时），它专为“本不该发生”的严重异常设计
真正难的不是记住每个函数签名，而是理解它们在内存模型、类型系统和并发语义中的定位。比如 make 创建的 slice 底层数组可能被多个 slice 共享，append 是否扩容决定了共享是否被打破——这些细节不靠调试很难暴露，得从第一次写就建立预期。
