go切片扩容时的cap变化由runtime内存分配器的size class对齐决定，而非缓存行或简单倍增；例如cap=27（int64）append后变为56，因28×8=224字节→目标容量54×8=432→roundupsize(432)=448→448/8=56。
Go 切片扩容时的内存对齐不是为了缓存行或数据安全，而是 runtime 内存分配器（mallocgc）的块管理策略决定的——它对齐的是分配器的 size class 档位，不是你想象的 64 字节 cache line。
为什么 cap 从 27 变成 56 而不是 54？
这不是翻倍或四舍五入，是字节数先对齐、再反推容量的结果：
- 假设元素类型是
[]int64（每个 8 字节），当前cap = 27，append 至少需要 28 个元素 → 需要 28 × 8 = 224 字节空间 - 但
growslice实际走的是：先按策略算“目标容量”（比如翻倍得 54），再算字节数：54 × 8 = 432 字节 - 调用
runtime.roundupsize(432)→ 查 size class 表，返回最接近且 ≥432 的档位（如 448 字节） - 最终容量 = 448 / 8 =
56，不是 54，也不是 55
这个过程完全不看元素个数奇偶，只看「元素个数 × 单元素字节数」是否跨过 size class 边界。
cap ≥ 1024 后的“1.25 倍”其实是假象
真正逻辑是：newcap = oldcap + oldcap/4，然后向上对齐到 8 字节边界，最后还得满足分配器块尺寸约束：
-
cap = 2048→ 算得2048 + 512 = 2560，2560 × 8 = 20480 字节 →roundupsize(20480)返回 20480（刚好对齐），所以cap就是 2560 -
cap = 3000→ 3000 + 750 = 3750 → 3750 × 8 = 30000 字节 →roundupsize(30000)返回 30016 → 最终cap = 30016 / 8 = 3752 - 你看到的“2560”“3760”只是常见结果，不是硬编码规则；不同元素大小（如
[]bytevs[]struct{a int; b [100]byte}）会导致完全不同路径
copy 不参与扩容，也不触发对齐
copy 函数签名是 func copy(dst, src []T) int，它只做三件事：按字节拷贝、返回实际拷贝数、不碰 dst.len 和 dst.cap：
-
dst必须已有足够cap，否则只拷贝min(len(dst), len(src))个元素，不会增长 - 哪怕你用
make([]int, 0, 100)创建dst，copy(dst, src)后它的cap还是 100，没变过 - 所谓“用 copy 扩容”，纯属误解；扩容动作只来自
append或显式make - 最危险的是：如果
dst是大数组的子切片（如big[100:200]），copy可能写入big[200:]区域——这不是对齐问题，是视图越界
真正容易被忽略的点：你无法靠观察 cap 数值反推内存布局，因为 roundupsize 的输入是字节数，而字节数取决于元素大小和目标容量的乘积；写压测或对接 C 接口时，必须手算这一步，不能依赖经验公式或打印出来的 cap 值。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
