make是唯一能同时分配内存并初始化map、slice、channel的操作；var声明nil map/slice/channel后直接使用会运行时panic。
直接说结论：用 make 创建 map、slice、channel 是唯一能完成「分配底层内存 + 初始化状态」的操作；只声明不 make（比如 var m map[string]int）会导致运行时 panic，不是编译错误，极易漏查。
map 初始化必须用 make 或字面量，var 声明等于没初始化
Go 的 map 是引用类型，但它的零值是 nil。这意味着：
-
var m map[string]int—— 只是声明了一个nil map，底层没分配哈希表结构 -
m["k"] = 1会立刻 panic：panic: assignment to entry in nil map - 正确做法只有两个：
m := make(map[string]int)或m := map[string]int{} -
make(map[string]int)和map[string]int{}功能完全等价，都是可写入的空 map，选哪个纯看团队风格
slice 用 make 时长度和容量参数不能乱配
make([]T, len, cap) 中的 len 和 cap 决定切片初始行为，错配会导致意外交互问题：
-
make([]int, 5)→ 长度=5，容量=5，元素全为 0，索引 0~4 可直接赋值 -
make([]int, 0, 5)→ 长度=0，容量=5，len(s) == 0，但cap(s) == 5，适合后续用append批量填入 -
make([]int, 5, 3)→ 编译报错：cap 不能小于 len - 如果只是要一个“空但可 append”的切片，优先用
make([]int, 0, n)，比make([]int, n)更节省初始内存
channel 初始化时缓冲区大小影响阻塞行为
make(chan T) 和 make(chan T, n) 表面只差一个参数，实际语义完全不同：
-
ch := make(chan int)→ 无缓冲 channel，发送和接收必须同步配对，否则 goroutine 阻塞 -
ch := make(chan int, 3)→ 有缓冲 channel，最多存 3 个值，发送不阻塞直到缓冲满 - 缓冲区大小设为 0 等价于不传参数，
make(chan int, 0)就是无缓冲 - 别用
make(chan int, 1)模拟 “单次信号”——它仍可能被重复发送而不阻塞，应配合select+default控制
make 的第三个参数（容量 hint）不是硬限制，但设太离谱会白忙活
对 map 和 slice，make 的容量参数是提示，不是契约：
-
make(map[string]int, 100)→ Go 会向上取整分配 bucket 数（比如 128），避免早期扩容；但插入第 101 个键仍可能触发扩容 -
make([]int, 0, 1000000)→ 底层数组真会分配 100 万个 int 的空间，内存立刻涨，慎用 - 预分配有意义的前提是：你知道数据规模且写入集中（如解析 JSON 后批量填充）；如果是边读边写、key 来自用户输入，预分配基本无效
- 别为了“看起来快”盲目设大容量——实测发现，
make(map[int]int, 1000)插入 1000 项时分配次数为 1，而make(map[int]int)约 3–4 次；但设成 10000，多占内存却没提速
真正容易被忽略的是：所有用 make 初始化的结构，其零值行为都依赖底层实现细节。比如 make([]int, 5) 元素必为 0，但 make([]string, 5) 元素是空字符串而非 nil；这种差异在类型断言或 JSON 解析时会突然冒出来。写的时候就得想清楚——你初始化的到底是个容器，还是个带默认值的模板。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
