copy函数不扩容、不对齐，仅搬运内存；其行为由dst切片的len和cap决定，扩容与对齐均由append或make触发，copy只按字节拷贝且不修改dst元信息。
copy 函数本身不扩容，也不会触发任何内存对齐行为——它只做内存搬运，容量和底层数组地址完全由目标切片（dst）决定。
为什么 copy 不参与扩容或对齐？
copy 的签名是 func copy(dst, src []T) int，它只按字节拷贝元素值，不修改 dst 的 len 或 cap，也不分配新内存。所谓“用 copy 扩容”，其实是误称；真实扩容动作必须来自 append 或 make。
-
copy要求dst已有足够容量，否则只拷贝min(len(dst), len(src))个元素，不会自动增长 - 若
dst是用make([]T, 0, N)预分配的，copy后它的cap仍是N，没变过 - 内存对齐（如 8 字节边界）只发生在
growslice分配新底层数组时，copy完全不调用它
真正触发对齐的是 append，不是 copy
当你看到“扩容后容量是 6 而不是 4”或“2048 → 2560”，那全是 append 调用 growslice 的结果。对齐规则在 runtime/slice.go 中硬编码：
- 元素大小为 1 字节（如
[]byte）：新容量向上对齐到roundupsize(uintptr(newcap)) - 元素大小为 8 字节（如
[]int64）：先算newcap * 8，再对齐，最后除以 8 得整数容量 - 对齐不是为了数据安全，而是适配内存分配器（
mallocgc）的块管理策略
想控制对齐？只能绕过 append，手动分配
如果你需要精确控制底层数组大小（比如对接 C 接口或做内存池），不能依赖 append 的自动策略。可行方式：
- 用
unsafe.Alloc（Go 1.21+）配合unsafe.Slice构造指定长度+对齐的切片 - 用
make([]T, 0, exactCap)预分配，再用copy填充——此时cap就是你写的exactCap，无额外对齐干扰 - 避免
append(s, x)在关键路径中出现，尤其当s的cap接近临界值（如 1023、2047）时，一次追加可能跳到 2048 或 2560，破坏你预设的布局
最易被忽略的一点：copy 的 dst 切片如果本身是某个大数组的子切片（如 big[100:200]），它的 cap 包含了后面未使用的空间，copy 可能悄悄写进你没意识到的内存区域——这不是对齐问题，而是视图越界风险。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
