不少学 Go 的朋友都有同一个经历数组看着没问题到切片这里就开始“凭感觉”写代码一遇到底层数组共享、append 扩容、copy 复制个数这些问题就翻车。市面上的切片练习题不少但多数只给答案不讲原理做完也不知道自己错在哪。这篇我直接用十道题开路从简单截取到二维切片、字符串转换、range 循环里 append每一题都拆开讲清楚“底层数组在那一瞬间到底发生了什么”。适合刚学完 Go 基础、想自测切片掌握程度的人也适合准备面试前想系统性查漏补缺的朋友。我自己带新手写 Go 项目时最常说的一句话是切片不是“动态数组”这么简单它是一个带着底层数组上下文的小结构。你如果只记住表层用法十个坑里能踩中八个。下面先花几百字把底层模型讲透再进入题目保证你刷完这十道题对切片的认知会扎实很多。1. 切片到底难在哪先搞懂它的底层模型再做练习很多人写切片题容易错根子在于没有把“切片 底层数组 指针 长度 容量”这个模型刻在脑子里。这里主要讲清楚三件事数组和切片是什么关系、切片描述符由哪几个字段组成、截取语法到底在算什么东西。1.1 数组的“实心眼”和切片的“懒记法”Go 里的数组是值类型。你写a : [4]int{1,2,3,4}然后把b : aGo 会把整个数组拷贝一份。也就是说b[0]100不会影响a二者是完完全全的两块内存。这是数组最直观的性格老实、厚重、交接时全部复制。切片就不一样了。切片本身不直接保存数据它保存的是“数据在哪里、能看多长、最多还能往后扩多少”。你可以把数组比喻成一整栋楼切片就是一张租赁合同合同上写了“我租的是从 3 楼开始的连续 4 个房间而且这栋楼从 3 楼往上一共有 6 个空房后续我有权利继续租”。租合同很轻但是多个片签可能指向同一栋楼的不同楼层甚至同一个房间被两份合同同时标注这时候问题就来了一个租户装修房间另一个租户看到的是同一个房间变了样。这就是切片让新手困惑的核心来源——共享底层数组。1.2 切片的三个字段ptr、len、cap在 Go 源码里切片的运行时表示是一个结构体三个字段ptr指向底层数组的起始位置len当前切片内有效元素个数cap从起始位置到底层数组末尾还能再容纳多少个元素你在函数里传递一个切片传递的是这个 24 字节的描述结构64 位平台下三个字段各 8 字节而不是把底层数组整个复制一遍。所以 Go 推荐用切片做参数效率高代价小。但有得必有失因为传的是描述结构接收方如果通过切片修改了底层数组的某个位置调用方那边的切片也会看到变化。很多工程 bug 就是从这里来的一个函数拿到了共享切片往里 append 了一个新值结果外部“无辜”的数据被悄悄改掉了。1.3 截取语法是怎么换算 len 和 cap 的当你看s[low:high]这样的切片表达式时Go 会做两件事新切片的len high - low新切片的cap cap(s) - low为什么cap是这样算因为底层数组还是原来那个数组新切片是从原数组的low位置开始“往后看”它能看到多少个元素取决于原数组在low位置之后还剩多少空间而不是取决于原切片的len。举例s : []int{0, 1, 2, 3, 4} t : s[1:3]t的len是 2cap是 4。因为s的底层数组长度是 5从下标 1 开始往后还能看到1、2、3、4四个位置所以cap 5 - 1 4。这一点很重要后面好多题都在这里设坑。理解了这三小节下面十道题就不是“猜答案”而是“按模型推导答案”。提示做题前建议先在本地跑一遍。如果条件有限不能运行也请先自己在纸上算一遍输出再往下翻解析。自己推出来的答案和直接看解析记住的答案效果完全不同。2. 十道切片自测题先动手再对答案以下是十道切片练习题按难度从入门到进阶排列。题面里只给代码和问题答案放在第三章建议先不要提前看。2.1 题目列表题1截取后的长度和容量s : []int{1, 2, 3, 4, 5} t : s[1:4] fmt.Println(len(t), cap(t))请问len(t)和cap(t)分别是多少题2append 修改了底层数组兄弟切片跟着变a : []int{1, 2, 3, 4} b : a[:2] c : a[:3] b append(b, 100) fmt.Println(a:, a) fmt.Println(b:, b) fmt.Println(c:, c)请写出这三次fmt.Println的输出。题3容量不够时append 会切断共享关系a : []int{1, 2, 3, 4} b : a[:2] b append(b, 100, 200, 300) fmt.Println(a:, a) fmt.Println(b:, b)请问a和b分别是什么题4不接 append 的返回值会怎样s : make([]int, 0) append(s, 1) fmt.Println(s)请问输出是什么这个1到哪去了题5make 的长度和容量是什么关系s : make([]int, 3, 5) s append(s, 1, 2) fmt.Println(len(s), cap(s))先判断s初始有几个元素再判断 append 之后长度和容量各是多少。题6copy 到底复制几个元素src : []int{1, 2, 3} dst : make([]int, 2) n : copy(dst, src) fmt.Println(n, dst)请问n是多少dst变成什么题7for range 内部 append 自己会死循环吗s : []int{1, 2, 3} for _, v : range s { s append(s, v) } fmt.Println(s)请问循环会无限进行吗循环结束后s是什么题8二维切片 make 之后直接赋值会 panic 吗ss : make([][]int, 2) ss[0] append(ss[0], 1) fmt.Println(ss)请问输出是什么如果把ss[0][0] 1放在 append 之前会发生什么题9字符串转成字节切片后修改它字符串会变吗s : hello b : []byte(s) b[0] x fmt.Println(s, string(b))请写出输出。想一想b和s之间到底共享内存吗题10append 一个切片需要展开吗a : []int{1, 2} b : []int{3, 4} a append(a, b...) fmt.Println(a)请问输出是什么如果把b...写成b能编译通过吗2.2 自测建议这十道题每一道都指向切片的一个典型知识点。做题时千万别只看输出对不对还要问自己三个问题这个操作改的是底层数组还是切片描述符本身append 前后底层数组是不是同一个我看到的切片len和cap分别是多少把这三个问题想清楚再去对第三章的解析收获会翻倍。3. 逐题拆解题眼都在“共享”和“扩容”上下面把十道题一道一道拆开讲。每道题我会直接给答案然后从底层模型的角度解释原因最后说一个常见认知误区。3.1 题1解析截取后的 cap 是从起点到数组末尾的距离答案len(t)3cap(t)4。t : s[1:4]得到的是s中下标1、2、3三个元素也就是[2,3,4]所以len是 3。cap为什么是 4因为底层数组还是原来那个长度为 5 的数组从下标 1 开始往后还能看到下标1、2、3、4共 4 个位置。很多人第一次做这道题会答cap(t)2或cap(t)5原因是没有意识到切片的cap不是“切片末尾到原切片末尾”而是“切片起点到整个底层数组末尾”。这个知识点直接关系到后面对append的判断如果cap还够用append 就会直接写在底层数组上兄弟切片会“被看到”如果cap不够Go 会换一块新底层数组兄弟切片从此各走各路。3.2 题2解析append 在容量充足时直接修改底层数组答案a: [1 2 100 4] b: [1 2 100] c: [1 2 100]初始时a : []int{1,2,3,4}len(a)4cap(a)4。b : a[:2]是一个长度为 2、容量为 4 的切片它指向底层数组下标 0c : a[:3]是一个长度为 3、容量为 4 的切片同样指向底层数组开头。b append(b, 100)时b当前长度是 2容量是 4还剩 2 个空位所以 100 被直接写到底层数组的下标 2 位置。于是整个底层数组变成[1 2 100 4]。由于a、b、c共享同一个底层数组它们打印出来就都会带着这个 100。这道题的易错点是很多人以为b是a的一份拷贝改b不影响a。实际上切片赋值、切片截取都不拷贝底层数据只是换了张“租赁合同”。切片的“值拷贝”发生在创建新切片或append导致扩容时不发生在简单的截取和赋值里。3.3 题3解析扩容之后底层数组各自独立答案a: [1 2 3 4] b: [1 2 100 200 300]初始状态和题2一样a的底层数组是[1,2,3,4]b : a[:2]的len2cap4。这次b append(b, 100, 200, 300)需要追加 3 个元素。追加后b的长度会变成 5但它的容量只有 4装不下。Go 的做法是分配一块更大的新底层数组把原来切片里的元素拷贝过去再追加新元素。所以b换到了新数组上后续怎么改 100、200、300 都和原来的a无关。a依然保持[1,2,3,4]。题2和题3放在一起对比就是要说明一个关键点append 是否影响其他共享切片完全取决于这次 append 有没有越过 cap 触发扩容。越过了就“分家”没越过就“共同修改底层的下一个格子”。这个逻辑在真实项目里极容易出现因为很多代码不会刻意关注当前切片还剩多少容量于是同样的 append 写法有时改到了别人有时没有非常诡异。3.4 题4解析append 的返回值必须接住答案s输出为[]。make([]int, 0)得到一个长度和容量都为 0 的空切片。append(s, 1)这个调用内部会尝试扩容返回一个新的切片描述符。但你没有把它赋值回ss依然是原来的空切片。那个数字1被写进了一块新的底层数组但因为切片描述符丢了程序无法再通过s访问到它。在 Go 里append 的返回值是必须接的。官方解释是因为 append 可能扩容导致底层数组地址发生变化所以必须返回新切片。哪怕这次没有扩容你也不能假设它一定没扩容因此统一用s append(s, v)这种写法。真实项目中有一种隐蔽错误在循环里写了append(slice, item)但忘记赋值结果循环结束后切片长度没有变化白白浪费了计算和内存。这种 bug 编译器不会报错运行时也不 panic只能靠经验或者测试发现。3.5 题5解析make 的 len 和 cap 是两个完全不同的概念答案len(s)5cap(s)5。make([]int, 3, 5)创建了一个长度 3、容量 5 的切片初始三个元素都是零值0。也就是说切片现在看起来是[0, 0, 0]但底层数组有 5 个位置后两个是“备而未用”的空位。然后append(s, 1, 2)追加两个元素直接填进空位长度变成 5容量还是 5所以输出5 5。这里常被搞混的是make([]int, 5)和make([]int, 0, 5)的区别。前者是“给我 5 个初始化好的零值元素”后者是“给我一个可以装下 5 个元素的容器但现在一个元素都还没有”。如果你把make([]int, 0, 5)直接拿去s[0] 1会 panic因为len还是 0下标越界。理解 len 和 cap 的分工是避免在切片表达式里写错下标的基础。3.6 题6解析copy 只复制长度较小的那个答案n2dst[1 2]。copy(dst, src)执行的是“从 src 往 dst 复制”复制的元素个数是min(len(src), len(dst))。src长度是 3dst长度是 2所以只复制前两个元素返回 2。这里特别反直觉的一点是copy不会因为dst的容量足够就多复制它只看len(dst)。比如dst : make([]int, 0, 3) n : copy(dst, []int{1,2,3}) fmt.Println(n, dst) // 输出 0 []dst容量是 3但长度是 0copy一个元素都不会放进去。想让复制生效必须保证dst有足够的长度而不是足够的容量。这在初始化目标切片时很常见应该写make([]int, len(src))而不是make([]int, 0, len(src))。3.7 题7解析range 在开始时就把长度固定了答案不会死循环。循环结束后s是[1 2 3 1 2 3]。Go 的for range在循环开始之前会对被迭代的切片求值一次确定这次迭代的“长度”。后续每次迭代都用这个固定的长度不会因为循环体内修改切片而重新计算。所以即使你在循环体内不断append循环也只会迭代 3 次。具体过程第一次迭代取v1append 后 s 变[1 2 3 1]第二次取v2append 后变成[1 2 3 1 2]第三次取v3append 后变成[1 2 3 1 2 3]。这个特性有正面用途也有坑。正面用途是遍历切片的同时追加元素不会导致死循环。坑是如果你在循环体内修改底层数组的某几个位置后续迭代读取的值可能会变成你刚写入的新值因为range是“边遍历边读取底层数组当前位置的数据”。在并发场景或者需要遍历时保持数据快照的情况下要格外小心。3.8 题8解析二维切片的内层元素默认是 nil答案输出[[1] []]。make([][]int, 2)只创建了外层切片长度是 2。外层切片的每个元素都是[]int类型而 Go 会把这些内层切片初始化为零值即nil。所以初始状态是[nil nil]。ss[0] append(ss[0], 1)虽然ss[0]是 nil但append(nil, 1)是合法的Go 会创建新的底层数组并放入1然后把新切片赋给ss[0]于是输出[[1] []]。如果你在 append 之前直接写ss[0][0] 1就会 panic因为ss[0]是 nil访问下标 0 越界。二维切片正确初始化方式是先给每一行分配底层数组ss : make([][]int, 2) for i : range ss { ss[i] make([]int, 3) }这种“外层建好了内层还是 nil”的细节在写二维表、矩阵、分组容器时会经常遇到是很多新手 panic 的常见来源。3.9 题9解析字符串转字节切片会复制底层数据答案输出hello xello。[]byte(hello)会生成一个新的字节切片底层数组是新建的内容复制自字符串。所以修改b[0]只影响新的字节数组字符串s本身不可变不受影响。需要注意的是Go 语言规范并不保证编译器一定在[]byte(s)时复制。理论上如果编译器能证明字节切片不会被修改它可能直接引用字符串的底层内存以避免拷贝。但在我们的代码里b[0] x明确修改了切片编译器必须让它成为可修改的独立内存所以必然复制。实际开发里经常用[]byte(string)做字符串替换或者解析这种转换会带来一次拷贝开销如果在热点路径上频繁执行且性能敏感可以用unsafe或其他方式优化但那已经属于进阶话题。至少你需要知道默认的转换是安全的字符串不会被字节切片意外改掉。3.10 题10解析append 展开切片要用三点答案输出[1 2 3 4]。a append(a, b...)的意思是“把b中的所有元素展开逐个追加到a后面”。这是 Go 里把一个切片拼到另一个切片后面的标准写法。如果把b...写成ba append(a, b) // 编译错误会报错因为append的第一个参数是切片后面跟的参数类型必须和切片元素类型一致也就是必须是int而b是[]int类型不匹配。只有加...才能把切片展开成元素序列。这道题在高频面试里也经常以变体出现能不能用append(a, b...)复制一个切片答案是能但要注意它返回的是新切片追加和扩容规则和普通 append 一样。如果想确保不共享底层数组用一个copy更直接。4. 刷完题之后工程里的切片坑与性能意识做完题只是第一步更重要的是把题目里的底层模型迁移到真实项目中。这一章我就不再一道题一道题来了直接总结我在实际开发里见过最多的四类切片“坑”以及怎么躲开它们。4.1 共享底层数组是“连环爆炸”的源头最典型的场景是结构体内部存了一个切片某个方法把内部切片的子切片返回出去调用方随手 append 一个新值结果内部数据被篡改。借用题2的模型看下面这段代码type Buffer struct { data []int } func (b *Buffer) GetSecond() []int { return b.data[:2] } func main() { buf : Buffer{data: []int{1,2,3,4}} got : buf.GetSecond() got append(got, 99) fmt.Println(buf.data) // [1 2 99 4] }调用方只是觉得自己拿到了一段“参考数据”准备往里面追加自己的内容但buf.data内部已经被改掉。这类 bug 的特点是单看每个方法都合理但组合起来数据就乱了。我的建议是凡是把内部切片对外提供除非你明确希望调用方拥有修改权限否则返回copy后的副本或者至少保证返回的切片cap和len相等让 append 直接触发扩容。不过后一种做法依赖扩容行为不够稳妥最稳的还是复制一份再返回。用copy之前先把目标切片长度建好这正好对应题6的知识点。4.2 append 的扩容策略与预分配Go 的切片扩容策略在不同版本里有一些差异大致规律是在长度小于 256 时容量翻倍更大的切片增长速度会放缓到大约 1.25 倍并带有内存对齐的上浮。具体数值不是官方对外 API 的保证所以作为使用者不应该依赖“它一定能翻倍”或者“翻倍后 cap 恰好是多少”只需要知道一件事当容量不够时append 会分配新底层数组并整体拷贝代价不小。如果代码里明确预知切片将要承载多少个元素比如从数据库中读n行、从文件中解析n列那就应该用make([]T, 0, n)预分配容量。这样可以避免多次扩容和多次拷贝。实测一个简单场景连续 append 10 万个元素预分配容量的版本比完全不预分配的版本在耗时和内存分配次数上都有明显优势。尤其是存储的元素本身是结构体时反复扩容的内存搬运开销会被放大。写高性能代码或者处理大批量数据时这个习惯非常重要。4.3 闭包、循环变量和切片的隐式关联循环里 append 切片是常见操作但有几个隐蔽风险需要留意。比如循环里错误地使用了共享的循环变量地址或者range捕获了同一个变量导致所有回调都看到同一个值。这个问题在很多文章里讲过Go 1.22 之后循环变量语义已经改成了每轮迭代独立的变量但生产环境里的 Go 版本不一定都升级到 1.22 以上所以旧代码里依然可能埋着这个坑。除了循环变量还有就是切片本身是引用语义闭包捕获的是切片描述符。如果闭包延迟执行而闭包外已经往切片里追加了内容闭包执行时看到的就是最新的切片内容而不是“创建闭包那一刻的快照”。在做异步任务、并发回调时一定要注意这一点。4.4 一个实用的检查套路我后来教团队新人时总结了一个三连问每次写切片相关代码前自我检查当前这个切片和谁共享底层数组我要做的 append/copy/截取会不会影响其他切片或底层数据我有没有接住 append 的返回值copy 的目标切片长度够不够这三问基本可以覆盖切片使用中 90% 的隐患。尤其是“共享底层数组”这件事很多 bug 只要在脑海里画一遍底层数组的格子图马上就能看出来。做题时把这种检查变成条件反射写项目时就能少熬夜查数据错乱的问题。我个人刷完这些题之后最大的感受是切片背后不是复杂的魔法就是一个简单的“底层数组 描述符”模型难就难在太多人只记 API 不记模型。每道题都对应一个真实世界里的坑把这些坑提前在练习题里踩遍总好过上线后被用户发现数据被悄悄改掉。如果你手上的项目也遇到过“切片被莫名修改”的 bug回头用这三问套一下八成能定位到问题。