s[a:b:c]的容量是c-a而非c-b，因其底层数组指针从索引a开始，容量即a到c的长度；长度为b-a，二者独立计算；约束条件为0≤a≤b≤c≤cap(s)。
为什么 s[a:b:c] 的容量是 c - a 而不是 c - b
因为容量描述的是“从切片起始位置开始，底层数组还剩多少可用空间”，不是“还能追加多少元素”。s[a:b:c] 生成的新切片，其底层指针指向原数组索引 a 处，所以容量自然是从 a 算到 c，即 c - a。长度才是 b - a —— 这两个值独立计算，不能混用。
常见错误现象：len(s) == 3、cap(s) == 4，但误以为“还能 append 4 个”，结果第一次 append 就触发扩容——其实最多只能再 append cap(s) - len(s) == 1 个才不换底层数组。
s[a:b:c] 编译失败和 panic 的边界条件
编译期就报错的情况只有一种：c 。Go 编译器会直接拒绝，不生成二进制。
运行时 panic 的唯一条件是：c > cap(s)（注意：不是 len(s)，也不是底层数组长度）。这时会触发 panic: runtime error: slice bounds out of range [:n] with capacity m。
必须满足的约束链：0 ≤ a ≤ b ≤ c ≤ cap(s)。漏掉任一环都出问题。
-
a > b：编译失败（索引顺序非法） -
b > cap(s)：编译失败（双索引切片也拦不住） -
c == b：合法，但得到一个len == 0、cap == 0的切片，后续任何append都必然分配新底层数组
用 s[a:b:c] 控制 append 行为的实际效果
它的核心作用不是“节省内存”，而是“切断共享风险”：显式压低容量，让超出逻辑边界的 append 不再复用原底层数组，从而避免意外覆盖其他切片的数据。
例如从一个大数组中提取子视图供函数处理，又不想让该函数通过 append 泄露写入到原数据区 —— 这时 s[a:b:c] 是比注释或文档更可靠的契约。
性能影响很小：只是改了 header 里的 cap 字段（8 字节），不复制数据、不分配内存。
典型误用：s[2:5:5] 看似“截到末尾”，但如果原切片 cap(s) == 10，那它等价于 s[2:5:10] —— 容量仍是 8，没起到限制作用。真正要锁死容量，得写成 s[2:5:5] 且确保 cap(s) == 5，或用 s[2:5:2+3] 这种显式算式增强可读性。
和双索引切片 s[a:b] 的关键差异点
双索引切片的容量默认是 cap(s) - a，它“继承全部剩余空间”，容易造成容量远超实际需要；三索引强制你声明上限，把隐式行为变成显式契约。
当你看到一段代码里反复用 append 且依赖底层数组不换，却没用 s[a:b:c] —— 那它大概率在靠运气跑，一旦上游切片容量变化，行为就不可控。
容易被忽略的细节：s[a:b:c] 不改变底层数组指针位置，也不影响原切片；但它会让所有基于它的后续切片（比如再 s2[1:3]）都受限于这个人为压低的容量上限 —— 这个限制是透传的，不是一次性的。
