一句话总结
Go = 静态编译的性能 + 接近脚本语言的开发效率 + 语言级并发。它的并发哲学是 CSP：不要通过共享内存通信，而要通过通信共享内存——goroutine 是轻量的用户态协程（初始栈仅几 KB，可动态扩缩），channel 是类型安全的通信管道，调度由运行时的 GMP 模型完成。内存上有逃逸分析决定栈/堆分配，GC 用三色标记 + 混合写屏障做到毫秒级停顿。面试主线：语法基础 → 并发原语 → 调度与 GC。
# Go 的五个设计取舍（解释"为什么这样设计"类问题的底料）：
# 1. 不做异常体系：error 是普通值，强迫显式处理（errors.Is/As、包装 %w）
# 2. 不做继承：组合 + 接口隐式实现（结构化类型的天然优势）
# 3. 不做泛型运算（1.18 起支持但克制）：优先 interface + 组合
# 4. 内置并发原语：goroutine/channel/select 一等公民，而不是库
# 5. 工具链内置：gofmt 统一风格、go test/bench/vet/pprof 开箱即用
初级理解
值类型与"引用类型"
| 类别 | 类型 | 赋值/传参时 |
|---|---|---|
| 值类型 | int、float、bool、string、array、struct | 完整拷贝 |
| 底层共享 | slice、map、chan、pointer、func、interface | 拷贝"头"或指针，底层数据共享 |
// slice 不是引用类型，是"底层数组的窗口"：三元组 {ptr, len, cap}
func main() {
s := []int{1, 2, 3}
t := s // 拷贝的是三元组头，指向同一个底层数组
t[0] = 99
fmt.Println(s[0]) // 99——元素修改互相可见
u := append(t, 4) // cap 未满：原地写入并更新 u 的头
w := append(s, 5) // 如果 s 的 cap 恰好够，会直接改掉共享底层数组！
fmt.Println(s, u, w) // 面试重点：append 是否影响原切片，取决于 cap
}
map 的基本语义
m := map[string]int{"a": 1}
v, ok := m["b"] // 取不存在的 key 返回零值，ok 标识是否存在——必须用两返回值判断
v2 := m["b"] // v2 == 0，无法区分"值就是0"还是"key不存在"
delete(m, "a")
for k, v := range m { // 遍历顺序故意随机化（防依赖顺序的 bug）
_ = k; _ = v
}
// m := make(map[string]int, 1024)——预分配容量，减少 rehash
// 零值 map 可读不可写：var m map[string]int; m["x"] = 1 → panic（写 nil map）
defer / panic / recover
func f() {
defer fmt.Println(1) // LIFO：后注册的先执行
defer fmt.Println(2)
fmt.Println(3)
// 输出：3 2 1
// 关键细节：defer 参数在注册时立即求值（复制），但函数体在返回时才跑
x := 1
defer fmt.Println(x) // 打印的是注册时的 1，不是返回前的 99
x = 99
// panic：当前函数栈立即 unwind，defer 依次执行；未 recover 则进程崩溃
// recover 只能在 defer 中调用，且只能拦住"当前 goroutine 正在 unwind 的 panic"
}
中级深入
GMP 调度模型（必考）
# G（Goroutine）：待执行任务，含栈、PC、状态，栈初始 2KB 动态扩缩（最多到 GB 级）
# M（Machine）：系统线程，真正干活的，数量上限默认 10000（可 debug.SetMaxThreads 调）
# P（Processor）：逻辑处理器，持有本地 G 队列，数量 = GOMAXPROCS（默认=CPU核数）
# P 是 M 和 G 之间的"许可证"：M 必须持有 P 才能执行 G（syscall 期间除外）
# 调度流程：
# 1. go func() 创建的 G 优先放入当前 P 的本地队列（无锁，lock-free 设计）
# 2. 本地队列满（256 个）→ 一半"偷"给其他 P（work stealing）
# 3. 当前 G 阻塞（syscall/IO）→ M 与 P 解绑（hand off），新 M 来接管 P 继续干活
# 4. 阻塞的 G 系统调用返回后：M 抢不到 P 就把 G 放回全局队列，自己休眠
# 追问：为什么要有 P？——把调度状态从 M 上拆下来，避免多 M 争抢全局队列的锁，
# 让本地调度无锁化；也是 GOMAXPROCS 限流的落点
channel 底层与 select 语义
# channel 底层是 hchan 结构：环形缓冲队列（buf）+ 发送/接收等待队列（sendq/recvq）+ 一把锁
# 发送方：队列有空位 → 入队；满了 → 当前 G 挂到 sendq，休眠
# 接收方：队列有数据 → 出队；空了 → 挂到 recvq 休眠；有等待的发送方 → 直接"握手"拷贝（跳过缓冲）
ch := make(chan int, 3) // 有缓冲
ch2 := make(chan int) // 无缓冲：必须双方同时就绪才完成（真正的同步点）
// select 的规则（高频考点）：
// 1. 所有 case 同时监听，随机选一个就绪的执行
// 2. 全不就绪：阻塞；有 default：走 default 不阻塞
// 3. nil channel 的 case 永久阻塞（常用来"关掉"某个分支）
// 4. 向已关闭 channel 发送 → panic；接收 → 立即返回零值，ok=false
v, ok := <-ch2 // 关闭后：v=零值, ok=false——用 ok 区分"关闭"和"值恰好是零值"
// 经典关闭范式：谁发送谁关闭，多发送方用 sync.WaitGroup 计数后由协调者关
// 反模式：接收方关闭 channel（会让发送方 panic）；向 nil channel 读写（永久阻塞）
逃逸分析：什么情况分配在堆上
# go build -gcflags="-m" 查看逃逸决策
# 常见逃逸（栈→堆）：
# 1. 函数返回局部变量的指针（编译器无法让生命周期超出栈帧）
# 2. interface 装箱：把值传给 interface{} 参数，编译期定不了大小 → 堆
# 3. 闭包捕获变量、发送到 channel、赋给全局变量
# 4. 变量过大 / 大小编译期未知（make 切片超出栈上限）
# 面试意义：Go 没有 "new 一定在堆" 的心智负担——&x 可能不逃逸（还在栈上），
# 逃逸分析是 GC 压力的第一道闸门；热点路径避免不必要的 interface 装箱
高级进阶
GC：三色标记 + 混合写屏障
# 三色标记（并发标记，几乎全程 STW-free）：
# 白色：未被访问（标记结束还是白色 → 回收）
# 灰色：已访问、引用的对象还没扫完
# 黑色：已访问、引用都扫完（不会被白色"背刺"）
# 流程：根对象（栈/GC元数据/全局）置灰 → 灰色逐个转黑色、其引用置灰 → 灰空 → 清扫白色
# 并发标记的危险：标记期间程序还在跑，"黑色对象直接引用白色对象"会让白色漏标
# （黑洞问题）。解决方案演进：写屏障
# Dijkstra 写屏障（插入屏障）：新引用白色时把它置灰 —— Go 用于堆对象
# Yuasa 删除屏障：删除旧引用时把旧指向置灰 —— 保护不被漏删
# Go 1.8 起：混合写屏障 = 两者结合 + 栈不需要屏障（栈在 STW 内重新扫描一次）
# 触发条件：堆增长到 GOGC 默认 100（堆翻倍）；或运行时按 2 分钟周期兜底
# Go 1.19+：GOMEMLIMIT（软内存上限）配合 GOGC 用——容器时代防 OOM 的关键参数
# 调优口径：GOGC=off + GOMEMLIMIT 适合内存稳定的服务；GC 频繁先看分配速率（pprof alloc_space）
内存模型：happens-before 与 channel 通信
# 问题背景：编译器/CPU 会重排 + 每个 M 有自己的缓存，"写了"不等于"别人看得见"
# Go 内存模型规定了"前一个操作 happens-before 后一个操作"时，前者对后者可见：
# - 同一 goroutine 内：程序顺序即 happens-before
# - channel：发送 happens-before 对应接收完成；无缓冲 channel 的接收 happens-before 发送完成
# - sync.Mutex： Unlock happens-before 后续 Lock
# - sync.Once：Once.Do 返回 happens-before 后续 Do 返回
// 实践推论：用 channel / sync 原语传递数据时不需要额外加锁；
// 只用普通变量在 goroutine 间"裸奔"共享，即使用 go run -race 也可能只是侥幸没炸
ch := make(chan struct{})
go func() { work(); close(ch) }()
<-ch // 等价于同步点，happens-before 建立
context：取消传播与超时控制
ctx, cancel := context.WithTimeout(parent, 3*time.Second)
defer cancel() // 必须调用，否则 timer 泄漏（vet 已能查出部分场景）
select {
case res := <-doWork(ctx): // 工作协程应把 ctx 传到最深处，select ctx.Done()
return res
case <-ctx.Done():
return ctx.Err() // context.DeadlineExceeded / context.Canceled
}
// WithValue 传请求级元数据（traceId/userId）——只放"跨 API 边界不便显式传递"的值，
// 键用未导出类型避免冲突；不要用它当函数参数省略器（可读性灾难）
sync 包选型
| 原语 | 适用场景 | 注意 |
|---|---|---|
| sync.Mutex | 临界区互斥 | 不要复制（值传递会拷贝锁状态） |
| sync.RWMutex | 读多写少 | 写会阻塞后续读，防写饥饿慎用嵌套 |
| sync.WaitGroup | 等待一批 goroutine 结束 | Add 在 go 之前；不能复用未 Wait 的实例 |
| sync.Map | 读极多写极少、key 稳定（如缓存） | 一般场景不如 Mutex+map 快，无 len()，遍历昂贵 |
| atomic | 计数器、状态标志、无锁单例 | 只能保护单个值，组合操作仍需锁 |
| sync.Pool | 高频临时对象复用（bytes.Buffer） | 对象可能随时被 GC 清空，不能当池化资源生命周期管理 |
goroutine 泄漏的三种典型场景
# 1. channel 没人读/没人写：阻塞在 <-ch 或 ch<- 的 goroutine 永不回收
# 修：配 ctx/cancel 或带缓冲、或保证每条 channel 有确定的关闭方
# 2. 忘记消费的生产者：for { ch <- produce() } 对端提前 return
# 3. time.Sleep 长等待 + 请求已取消：应改为 select { case <-time.After(): case <-ctx.Done(): }
# 排查：runtime.NumGoroutine() 持续上涨 → pprof goroutine profile 看阻塞栈
实战场景
Worker Pool：限制并发数处理任务流
func workerPool(ctx context.Context, jobs []Job, n int) []Result {
results := make(chan Result, len(jobs))
var wg sync.WaitGroup
for i := 0; i < n; i++ {
wg.Add(1)
go func() {
defer wg.Done()
for j := range jobsCh { // jobsCh 由协调者发送后 close
select {
case results <- handle(j):
case <-ctx.Done():
return // 提前退出，避免泄漏
}
}
}()
}
go func() { wg.Wait(); close(results) }() // 所有 worker 结束后关 results
var out []Result
for r := range results { out = append(out, r) }
return out
}
errgroup：并发抓取并聚合错误
g, ctx := errgroup.WithContext(context.Background())
g.SetLimit(8) // 1.20+ 内置并发上限，替代手写信号量
for _, url := range urls {
url := url // 循环变量捕获（1.22 前必须）
g.Go(func() error {
resp, err := http.Get(url) // errgroup 的 ctx 一旦有错自动取消其余任务
if err != nil { return err }
defer resp.Body.Close()
return save(url, resp)
})
}
if err := g.Wait(); err != nil { // 返回第一个非 nil 错误
log.Fatal(err)
}
优雅停机与 pprof 排查
// 优雅停机：SIGTERM → 拒绝新请求 → 等在途请求跑完 → 退出
ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGTERM, syscall.INT)
defer stop()
go srv.ListenAndServe() // 等 ctx.Done 后调用 srv.Shutdown(ctx)
# pprof 排查三板斧：
# go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30 # CPU 热点
# go tool pprof http://localhost:6060/debug/pprof/heap # 内存/泄漏
# go tool pprof http://localhost:6060/debug/pprof/goroutine # goroutine 堆栈
# top、web（火焰图）、trace（调度时间线）按需选；-lock 查数据竞争
面试模拟
面试官：说一下 GMP 模型，为什么要有 P？
你：G 是 goroutine 任务，M 是系统线程，P 是逻辑处理器、持有本地运行队列并代表执行 G 的"许可证"——M 必须持有 P 才能调度 G。G 由 go 关键字创建后优先进入当前 P 的本地队列（无锁），本地满 256 个会偷一半给其他 P。G 阻塞时 M 与 P 解绑交给新 M 继续跑。引入 P 的意义是把调度队列从全局锁里解放出来：没有 P 时所有 M 都要抢全局队列的锁，有了 P 后绝大多数调度走本地无锁队列，横向扩展性好，GOMAXPROCS 的限流也落在 P 上。
面试官：slice 传参后 append，会影响原切片吗？
你：slice 是三元组头（指针/len/cap）的值拷贝，传参拷贝的是头，底层数组共享。append 时若 len < cap（有剩余容量）就在原数组上写入，所有共享该数组的切片都"看得见"这个新元素；若容量不足则分配新数组拷贝，之后互不影响。坑在于：多个切片共享底层数组时，各自 append 可能互相覆盖数据——防御手段是 append 后用 s = s[:len(s):len(s)] 截断 cap 强制扩容，或显式 copy 一份新切片。
面试官：Go 的 GC 为什么用三色标记？写屏障解决什么问题？
你：三色标记是并发可达性分析：灰色持队列、黑色已扫完、白色待回收，从根对象出发把灰色转黑、引用置灰直到队列为空，白色即回收。并发标记期间 mutator 还在跑，可能出现黑色对象直接引用白色对象导致漏标（引用关系变更发生在"该对象已扫描"之后）。写屏障在指针写入时介入：Go 用混合写屏障（插入+删除屏障结合），新引用白色时置灰、栈上指针写入不加屏障（启动时栈重扫一次 STW），从而把 STW 压到亚毫秒级，同时避免丢引用。触发由 GOGC（堆增长比例）和 GOMEMLIMIT（软上限）控制。