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 参数与结果对象，支持命名依赖等

下载

• 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 是否扩容决定了共享是否被打破——这些细节不靠调试很难暴露，得从第一次写就建立预期。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！