手写 reverse 切片应原地交换而非新建切片，以避免内存分配和逃逸，考察对 slice 底层三要素（指针、长度、容量）及引用特性的理解。

手写题不是考你背代码，而是看你会不会用 Go 的语言特性解决真实小问题——Top10 里有 7 道直接暴露你对 slice、channel、defer、interface 的理解偏差。

手写 reverse 切片（别用 for 循环从后往前赋值）

面试官想确认你是否真懂 slice 底层是引用+三要素（指针、长度、容量）。常见错误是新建切片再 copy，造成不必要的内存分配和逃逸。

• 正确做法：原地交换，for i, j := 0, len(s)-1; i
• 传参必须用指针：func reverse(s []int) 无法修改原 slice；要改内容就得 func reverse(s []int) —— 因为 slice 本身是值类型，但它的底层数组是共享的
• 坑：如果传入 nil slice，len(nil) 是 0，不会 panic，但 cap(nil) 也是 0，别在 reverse 里盲目 make

手写 sum 并发版（带超时控制和结果聚合）

这道题同时考察 goroutine 控制、channel 关闭时机、context 取消传播、以及如何避免 goroutine 泄漏。

• 核心结构：用 context.WithTimeout 包裹，启动 N 个 go func() 向同一 chan int 发送子结果，主 goroutine range 读取或等超时
• 关键细节：channel 必须带缓冲（如 make(chan int, workers)），否则一个 worker panic 或阻塞会导致整个流程 hang 住
• 致命错误：在 goroutine 里 defer close(ch)，因为多个 goroutine 同时 close 同一个 channel 会 panic：panic: close of closed channel
• 安全做法：只由主 goroutine 在所有 worker 返回后 close(ch)，或用 sync.WaitGroup + close 配合

手写 pipeline 模式（filter → map → reduce）

不是让你实现 MapReduce 框架，而是检验你能否用 channel 组合出可复用、可中断的数据流。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

立即学习“go语言免费学习笔记（深入）”；

• 每阶段函数签名应统一：输入 ，输出 <code>，例如 <code>func filter(in
• 必须处理上游关闭：用 for v := range in，而不是 for { select { case v := ，否则 channel 关闭后会死循环空转
• 常见泄漏点：没用 context 传递取消信号，导致中间 stage 卡在阻塞读，goroutine 永不退出
• bonus 点：在 reduce 阶段加 sync.Pool 复用临时 slice，避免高频分配

手写 defer 执行顺序 + 修改返回值（经典陷阱题）

这道题几乎必问，错一次基本等于没搞懂 defer 的底层机制。

• 记住：defer 在函数 return 语句执行「之后、函数真正返回之前」运行；且按栈序（LIFO）执行
• 能修改返回值的前提：函数有**具名返回值**，例如 func f() (err error)；如果是 func f() error，则不能通过 defer func() { err = xxx }() 修改
• 反例：下面代码输出 2 而非 3：

  func foo() (x int) {  
      defer func() { x++ }()  
      x = 1  
      return  
  }

  因为 return 实际被编译器展开为 x = 1; goto defer; ...，所以 defer 真的能改
• 但若写成 return 1（非具名），defer 中改 x 就无效 —— 编译器已把返回值当临时量处理了

真正难的不是写出代码，而是解释清楚「为什么这个 channel 不能关」「为什么这个 defer 改不了返回值」「为什么这个 slice 反转后原数组变了」——这些细节才是面试官盯住不放的地方。