append 返回新切片必须赋值，因切片是引用类型但 append 不修改原变量；cap 是当前底层数组剩余容量而非上限；批量追加需用...展开；map 的 hint 是预分配提示而非容量限制。
append 是 Go 中最贴近“语言学习思路”的动态扩容入口——它不像教科书里讲的“先分配、再复制、最后替换”，而更像母语习得：你只管说（传入元素），系统自动判断要不要换更大的“嘴”（底层数组）来容纳，且旧话（数据）一句不丢。
但这个类比容易误导人跳过关键细节。实际编码中，真正卡住人的从来不是“会不会用 append”，而是“为什么用了却没扩容”“为什么扩容后老值丢了”“为什么性能突然变差”。
为什么 append 返回新切片，赋值不能省？
Go 的切片是引用类型，但 append 不修改原变量，而是返回一个可能指向新底层数组的切片。这和“学单词要抄三遍”不同——你抄了，但老师没收你那张纸，得自己交上去。
-
slice = append(slice, 42)✅ 正确：把返回值重新赋给slice -
append(slice, 42)❌ 无效：结果被丢弃，slice仍指向旧底层数组，长度也没变 - 常见现象：循环里反复
append却没赋值，最后打印还是空或只有第一个元素
cap 不是“最大容量”，而是“当前能免费加多少”
初学者常把 cap 当作数组的“上限”，其实它是当前底层数组还能容纳多少新元素而不触发扩容。就像背单词本的“剩余页数”——写满一页才换新本，但本子大小不是固定的。
立即学习“go语言免费学习笔记（深入）”；
- 初始
make([]int, 0, 8)：长度 0，容量 8 → 可append8 次都不扩容 - 第 9 次
append：触发扩容，新容量通常为 16（翻倍），旧数据全拷贝过去 - 若从
[5]int数组转成切片：arr := [5]int{1,2,3,4,5}; s := arr[:]，此时cap(s) == 5，再append就必然扩容
合并两个切片时，... 不是语法糖，是类型必需
想把 slice2 全部元素加到 slice1 末尾，必须写 append(slice1, slice2...)。漏掉 ... 不是少打三个点，而是传了一个 []int 类型参数，而 append 第二个及以后参数要求是 int（或对应元素类型）。
-
append(slice1, slice2...)✅ 展开为append(slice1, 6, 7, 8, 9, 10) -
append(slice1, slice2)❌ 编译错误：cannot use slice2 (type []int) as type int in argument to append - 错误常出现在重构代码时：把单个元素
append(a, x)改成批量，却忘了加...
map 的“扩容”完全不用你操心，但 make(map[K]V, hint) 的 hint 是防抖，不是设限
map 的扩容是运行时黑盒操作，你调 m[k] = v 就完事。但 make(map[string]int, 100) 里的 100 不是“只能存 100 个”，而是告诉 runtime：“我大概要存这么多，你提前分一块差不多大的内存，别老来回搬。”
- hint 过小（如
make(map[string]int, 1)）→ 频繁扩容 → 多次哈希重分布 → 性能毛刺 - hint 过大（如
make(map[string]int, 1000000)）→ 内存浪费，尤其 map 实际只存几十个键 - 不确定数量时，直接
make(map[string]int)即可，runtime 有合理默认值
真正容易被忽略的，是切片扩容策略随容量变化：小切片翻倍（cap=4→8→16），大切片只增 25%（cap=2048→2560）。这意味着，如果你预估要存 5000 个元素，用 make([]int, 0, 5000) 比依赖自动扩容更稳——避免中间那几次大拷贝。
