语言基础
Go 的设计哲学
Go 的设计目标是解决 Google 内部大规模软件工程的痛点：编译慢、依赖混乱、并发编程复杂、工程师水平参差不齐。它刻意放弃了很多语言特性，追求「足够好」的工程效率。
| 设计原则 | 具体体现 | 解决的问题 |
|---|---|---|
| 简单少即是多 | 25 个关键字、没有继承、没有泛型（1.18 前）、没有异常 | 降低学习成本，代码风格统一，新人一周可上手 |
| 组合优于继承 | struct embedding、interface 鸭式类型 | 避免继承层次过深，代码更易重构 |
| 并发是一等公民 | goroutine + channel、CSP 模型 | 语言层面支持高并发，不用回调地狱 |
| 快速编译 | 依赖分析清晰、禁止循环依赖、包级别编译 | 大型项目编译速度快，开发体验好 |
| 内置工具链 | gofmt、go test、go vet、go mod、pprof | 统一工程规范，不用纠结选什么工具 |
Go 适用场景
| 场景 | 为什么选 Go | 代表项目 |
|---|---|---|
| 云原生基础设施 | 单二进制部署、并发强、资源占用低、容器友好 | Docker、Kubernetes、Etcd、Prometheus |
| 微服务/API 网关 | HTTP/RPC 性能好、goroutine 处理高并发连接 | Go-kit、Kratos、Gin、Hertz |
| CLI/DevOps 工具 | 交叉编译简单、跨平台、无依赖 | Hugo、Terraform、GitHub CLI、kubectl |
| 分布式中间件 | 网络库成熟、并发模型适合代理/存储 | TiDB、InfluxDB、CockroachDB、NSQ |
| 高并发网络代理 | goroutine-per-connection 模型简单高效 | Traefik、Envoy（部分）、FRP |
Go 不适合的场景
| 场景 | 为什么不选 Go | 替代语言 |
|---|---|---|
| HPC/数值计算 | GC 停顿、编译器优化不如 C++/Fortran、SIMD 支持弱 | C++、Fortran、Julia |
| GPU 计算/CUDA | 没有官方 CUDA 绑定、生态薄弱 | CUDA C++、Python |
| 低延迟实时交易 | GC 虽然低延迟但仍有 STW，不能保证亚微秒级 | C++、Rust |
| GUI 桌面应用 | 原生 GUI 框架不成熟 | C++、Rust、Electron |
| 前端 Web 开发 | WASM 生态尚在发展，不如 JS/TS 成熟 | TypeScript、Rust（WASM） |
回答思路：从性能、生态、部署、团队三个维度对比，结论是「分层选型」而不是二选一。
模型推理封装、数据处理 pipeline、Notebook 实验、快速原型验证。Python 有 PyTorch/TensorRT 完整生态，算法团队效率最高。
高并发 API 网关、请求调度、服务编排、缓存代理、日志采集、分布式训练的控制面。Go 处理 10k QPS 只用几个 goroutine，内存占用是 Python 的 1/10，单二进制部署到 K8s 极其方便。
Go 做入口层（鉴权、限流、路由、batch 合并）→ Python/C++ 做推理层（TensorRT/vLLM）→ Go 做监控日志层。这是目前大多数 AI 公司的标准架构。
回答思路：核心是「传递的到底是什么」以及「修改是否会影响原对象」。
Go 中所有赋值和参数传递默认都是值拷贝：int、string、struct、array 是值类型，传参会复制整个对象；slice、map、channel、interface、pointer 看起来像引用，本质是「包含指向底层数据指针的结构体」，拷贝的是这个 header 结构体，所以通过它们能修改底层数据。
Java 中除了基本类型（int、long 等），所有对象都是引用传递，赋值只是拷贝引用地址，方法内修改对象字段会影响原对象；但如果是obj = newObj这种重新赋值，不会影响外部引用。
// Go
type User struct{ Name string }
func f(u User) { u.Name = "changed" } // 修改的是拷贝，外部不变
func f(u *User) { u.Name = "changed" } // 传指针，外部变
// Java
void f(User u) { u.name = "changed"; } // 修改对象字段，外部变
void f(User u) { u = new User(); } // 重新赋值，外部不变
回答思路：不是因为 Go 性能最高，而是综合工程效率、部署、并发、生态的最优解。
静态编译成单二进制，FROM scratch 就能做镜像，没有 JVM/Python 依赖，镜像大小几 MB vs Java 的几百 MB，冷启动快。
云原生组件大多是 I/O 密集型（watch API、处理 HTTP 请求、代理转发），goroutine 模型让每个连接一个 goroutine 成为可能，代码写起来像同步但性能是异步的。
gofmt 统一代码风格、内置 test/bench/pprof、社区推崇简单透明，K8s 生态早期就是 Google 内部 Borg/Omega 的 Go 实现延伸。
值类型 vs 引用类型
Go 中所有赋值和参数传递默认都是值拷贝，但有些类型内部持有指针，表现得像引用。理解这点是写对 Go 代码的基础。
| 分类 | 类型 | 拷贝行为 | 修改是否影响原值 |
|---|---|---|---|
| 值类型 | int、float、bool、string | 完整拷贝数据 | 不影响 |
| array（固定长度数组） | 拷贝整个数组 | 不影响 | |
| struct | 拷贝所有字段 | 不影响（字段是指针除外） | |
| pointer（*T） | 拷贝地址（8字节） | 通过指针修改会影响 | |
| 引用语义类型 | slice | 拷贝 header（ptr+len+cap） | 修改元素会影响底层数组 |
| map | 拷贝 header（指向哈希表指针） | 修改会影响 | |
| channel | 拷贝 header（指向队列指针） | 修改会影响 | |
| interface | 拷贝（tab+data 两字） | 如果 data 是指针则可能影响 |
Struct Embedding：组合替代继承
Go 没有 extends 关键字，不支持类继承，而是通过 struct embedding 实现组合。嵌入的字段称为「匿名字段」，外层 struct 可以直接访问嵌入字段的方法和字段。
type Animal struct{ Name string }
func (a Animal) Speak() string { return "..." }
type Dog struct {
Animal // 嵌入 Animal，不是继承
Breed string
}
d := Dog{Animal: Animal{Name: "旺财"}, Breed: "柯基"}
fmt.Println(d.Name) // 直接访问：旺财（提升字段）
fmt.Println(d.Speak()) // 直接调用方法：...
| 特性 | Go Embedding | Java/C++ 继承 |
|---|---|---|
| 关系 | has-a（组合） | is-a（继承） |
| 多态 | 通过 interface 实现 | 通过虚函数/override 实现 |
| 方法覆盖 | 外层同名方法会遮蔽嵌入方法，可显式调用 d.Animal.Speak() | 子类 override 父类方法，多态调用 |
| 多继承问题 | 可以嵌入多个 struct，编译器处理冲突 | 菱形继承问题，需要虚继承 |
| 构造 | 必须显式初始化嵌入字段 | 自动调用父类构造 |
Interface：隐式鸭式类型
Go 的 interface 是一组方法签名的集合，类型不需要显式声明「implements XxxInterface」，只要实现了 interface 的所有方法，就自动满足这个 interface。这就是「鸭子类型」：如果它走起来像鸭子、叫起来像鸭子，那它就是鸭子。
type Speaker interface {
Speak() string
}
type Dog struct{}
func (d Dog) Speak() string { return "汪！" } // Dog 自动满足 Speaker
type Cat struct{}
func (c Cat) Speak() string { return "喵～" } // Cat 自动满足 Speaker
func MakeSound(s Speaker) { fmt.Println(s.Speak()) }
MakeSound(Dog{}) // 汪！
MakeSound(Cat{}) // 喵～
空 interface interface{}
interface{}（Go 1.18+ 写作 any）不包含任何方法，所以所有类型都满足它。但不要滥用空 interface，它会让你失去类型检查：
- ✅ 用在 fmt.Print、json.Marshal 这种真正需要处理任意类型的地方
- ❌ 不要为了省事用
map[string]interface{}传业务参数，应该定义 struct
类型断言与 Type Switch
从 interface 取出具体类型用类型断言 x.(T)，推荐用 comma-ok 形式避免 panic。
var s Speaker = Dog{}
// 不安全：如果 s 不是 Dog 会 panic
d := s.(Dog)
// 安全：ok 为 false 时 d 是 Dog 的零值
d, ok := s.(Dog)
if ok {
fmt.Println("是 Dog", d.Breed)
}
// Type Switch：判断多种类型
switch v := s.(type) {
case Dog:
fmt.Println("Dog:", v.Breed)
case Cat:
fmt.Println("Cat:", v.Name)
case nil:
fmt.Println("nil interface")
default:
fmt.Printf("未知类型 %T\n", v)
}
⚠️ 经典坑：nil interface vs nil pointer
这是 Go 面试最高频的坑之一：interface 在内部是两字结构（(type, data)），只有当 type 和 data 都为 nil 时，interface 才等于 nil。
type MyError struct{}
func (e *MyError) Error() string { return "error" }
func returnsError() error {
var e *MyError = nil // e 是 nil pointer
return e // 但返回的 interface 是 (*MyError, nil)
}
func main() {
err := returnsError()
fmt.Println(err == nil) // false！面试必问
fmt.Println(err) // （打印看起来是 nil 但实际不是）
}
interface != nil。返回错误时，如果真的没有错误，必须显式返回 nil，而不是返回值为 nil 的指针。正确写法
func returnsError() error {
var e *MyError = nil
if 出错条件 {
return e
}
return nil // ✅ 正确：无错误时直接返回 nil
}
回答思路：从 Go 设计哲学「简单、可维护」出发，说继承的问题和组合的优势。
继承是 is-a 关系，容易形成过深的继承层次（继承金字塔），父类修改会影响所有子类，耦合度高；多继承带来菱形继承问题；子类继承了不需要的方法，违反里氏替换原则。
组合是 has-a 关系，耦合度低，可以嵌入多个 struct，方法查找简单直接，不会有继承的脆弱基类问题；Go 通过 interface 实现多态，通过 embedding 实现代码复用，职责更清晰。
封装（首字母大小写控制可见性）、继承（struct embedding 组合）、多态（interface 鸭式类型）——Go 没有放弃 OOP，而是用更简单的方式实现。
回答思路：先讲 interface 的内部结构，再给代码示例，最后说正确的返回方式。
interface 在运行时是两个指针大小的结构体：第一个指针指向 itab（类型信息+方法表），第二个指针指向实际数据。只有 itab 和 data 都为 nil 时，interface 才 == nil。
当你把一个 nil 的 *T 赋值给 interface 时，itab 被设置为 *T 的类型信息，data 是 nil，但 interface 本身不是 nil。fmt.Println(err) 会打印 <nil> 是因为 Error() 方法在 receiver 为 nil 时返回的，但 err == nil 比较的是整个 interface 结构。
函数返回 error 时，如果确定没有错误，一定要 return nil，不要 return 一个类型化的 nil 指针；接收 error 时不要用 err != (*MyError)(nil) 这种判断，用 errors.As 来做类型断言。
回答思路：核心区别是「是否需要显式声明实现」以及「是否可以有数据」。
隐式实现，不需要 implements 关键字；interface 不能有字段（Go 1.18 前），只有方法；可以给任意类型（包括基本类型、非 struct 类型）实现方法来满足接口；支持空 interface any。
显式声明 implements；Java 8+ 可以有 default 方法、static 方法、常量；只能被 class 实现；一个类可以实现多个 interface。
包含纯虚函数就是抽象类，可以有成员变量、构造函数、普通虚函数；通过 public 继承来「实现」接口；支持多继承，但有菱形继承风险。
error 是一个接口
Go 内置的 error 就是一个只包含 Error() 方法的 interface，这是最朴素的错误处理设计：
type error interface {
Error() string
}
创建错误最常用的方式：
// 1. 简单字符串错误（最常用）
err := errors.New("something went wrong")
// 2. 格式化错误信息
err := fmt.Errorf("failed to read file %s: %w", filename, err)
// 3. 自定义错误类型（需要携带额外信息时）
type MyError struct {
Code int
Message string
Cause error
}
func (e *MyError) Error() string {
return fmt.Sprintf("code=%d msg=%s: %v", e.Code, e.Message, e.Cause)
}
错误包装与 errors.Is/As/Unwrap
Go 1.13 引入了错误包装（error wrapping），用 %w 格式化动词可以把底层错误包装到新错误中，形成错误链。
| 函数 | 作用 | 示例 |
|---|---|---|
fmt.Errorf("...: %w", err) | 包装错误，保留原始错误链 | return fmt.Errorf("query db: %w", err) |
errors.Is(err, target) | 判断错误链中是否包含 target 错误（包括哨兵错误） | if errors.Is(err, os.ErrNotExist) { ... } |
errors.As(err, &target) | 把错误链中第一个匹配的类型提取到 target | var myErr *MyError; if errors.As(err, &myErr) { ... } |
errors.Unwrap(err) | 返回被包装的下一层错误 | 手动遍历错误链时用 |
⚠️ Sentinel Error vs 自定义错误
| Sentinel Error（哨兵错误） | 自定义错误类型 | |
|---|---|---|
| 定义 | var ErrNotFound = errors.New("not found") | 实现 error 接口的 struct |
| 判断方式 | errors.Is(err, ErrNotFound) | errors.As(err, &myErr) |
| 优点 | 简单、标准库大量使用 | 可以携带上下文信息（Code、字段等） |
| 缺点 | 不能携带额外信息，API 暴露内部实现 | 需要定义类型，略复杂 |
| 适用 | 标准错误：EOF、NotExist、AlreadyClosed | 业务错误：ErrorCode、请求ID、用户信息 |
Go 错误处理最佳实践
- ✅ 错误要么处理，要么返回，不要忽略（
_ = err除外） - ✅ 错误信息要描述「做什么失败了」，不要只说「出错了」
- ✅ 用
%w包装错误保留根因，不要用%v吞掉错误链 - ✅ 业务错误用自定义类型携带错误码，上层用
errors.As判断 - ❌ 不要到处
if err != nil { return err }裸传，至少加一层上下文 - ❌ 不要用 panic 处理普通业务错误（比如参数校验失败）
// ❌ 不好：裸传错误，没有上下文
func GetUser(id int) (*User, error) {
return db.Query("SELECT ...", id)
}
// ✅ 好：包装错误，说明是哪个操作失败
func GetUser(id int) (*User, error) {
user, err := db.Query("SELECT ...", id)
if err != nil {
return nil, fmt.Errorf("get user %d from db: %w", id, err)
}
return user, nil
}
Panic 与 Recover
panic 用于报告真正意外的、程序无法继续运行的错误，会立刻停止当前函数执行，沿调用栈向上执行所有 defer，然后程序崩溃并打印栈信息。
什么时候用 panic，什么时候不用
| ✅ 应该用 panic | ❌ 不应该用 panic |
|---|---|
| 程序启动时配置解析失败（服务没法启动） | HTTP 请求参数校验失败（应该返回 400） |
| 不可能发生的情况（程序员错误） | 数据库查询没找到记录（应该返回 ErrNotFound） |
| map 并发写、nil 指针解引用等 runtime 错误 | 网络超时、文件不存在（可预期的错误） |
| init() 函数中依赖初始化失败 | 任何业务逻辑错误 |
recover 用于捕获 panic，阻止程序崩溃，只能在 defer 中调用，通常用于 HTTP 服务的中间件，避免单个请求 panic 导致整个服务挂掉。
func RecoveryMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
defer func() {
if err := recover(); err != nil {
log.Printf("panic: %v\n%s", err, debug.Stack())
http.Error(w, "Internal Server Error", 500)
}
}()
next.ServeHTTP(w, r)
})
}
Defer 执行顺序：LIFO + 在 return 之前
defer 语句会把函数调用压入栈，后进先出（LIFO）顺序执行；defer 执行时机是「函数返回之前」，也就是 return 语句赋值返回值之后、真正返回给调用者之前。
func example() {
defer fmt.Println("1")
defer fmt.Println("2")
defer fmt.Println("3")
fmt.Println("函数体")
}
// 输出：
// 函数体
// 3
// 2
// 1
经典面试题：defer 修改命名返回值：
func f() (result int) {
defer func() {
result++ // ✅ 可以修改命名返回值
}()
return 0 // 1. 先给 result 赋值 0；2. 执行 defer（result 变成 1）；3. 返回 result=1
}
func g() int {
result := 0
defer func() {
result++ // ❌ 修改的是局部变量，不影响返回值
}()
return result // 返回值已经确定是 0，defer 改的是局部变量
}
fmt.Println(f()) // 1
fmt.Println(g()) // 0
回答思路：这是 Go 设计哲学的体现，核心是「显式优于隐式」和「控制流清晰」。
exception 会隐式改变控制流，throw 可以从很深的调用栈直接跳转到上层 catch，代码路径不清晰；容易被滥用，什么错误都抛异常；程序员容易忽略异常（或者写空 catch 吞掉）；资源清理依赖 try-with-resources/finally，容易出错。
错误是普通值，必须显式处理，if err != nil 强迫你面对错误；控制流完全在代码里可见，不会有看不见的跳转；资源清理用 defer 更可靠；没有额外的异常栈展开开销，性能更好。
代价是代码里 if err != nil 看起来很啰嗦，但 Rob Pike 说「这不是问题，这是我们的设计选择——显式处理每个错误，让错误成为代码的一等公民」。Go 1.13 之后 errors.Is/As 和 %w 包装已经很大程度缓解了错误处理的繁琐。
回答思路：分两部分回答：多个 defer 的顺序，以及 defer 和 return 的先后关系。
后进先出（LIFO，栈结构）：先 defer 的后执行，后 defer 的先执行。这和栈释放资源的语义一致——先申请的后释放（比如打开文件 A 再打开文件 B，先关 B 再关 A）。
return 不是一个原子操作，编译器把它拆成三步：
1. 给返回值赋值<br>
2. 执行所有 defer 函数<br>
3. 函数真正返回（RET 指令）</p>
所以 defer 是在 return 赋值之后、真正返回之前执行的。如果函数用命名返回值，defer 可以修改最终返回值；如果是匿名返回值，return 时已经把值存到返回位置了，defer 修改局部变量不影响。
defer 语句执行时（不是 defer 函数调用时）就会对参数求值，比如 defer fmt.Println(i) 中 i 的值在 defer 那一刻就确定了；如果 defer 的是闭包，闭包引用的变量是在执行时才取值。
for i := 0; i < 3; i++ {
defer fmt.Println("a:", i) // 输出 a:2, a:1, a:0（参数立即求值）
defer func() { fmt.Println("b:", i) }() // 输出 b:3, b:3, b:3（闭包引用外部 i）
}
回答思路：先讲二者解决的问题，再给对比和示例。
沿着错误链 Unwrap，逐层比较是否等于 target 错误（用 == 比较，或者类型实现 Is(error) bool 方法）。用于判断「这个错误是不是某个预定义的哨兵错误」，比如 os.ErrNotExist、io.EOF、context.Canceled。
if errors.Is(err, context.DeadlineExceeded) {
return "超时"
}
沿着错误链 Unwrap，找到第一个类型匹配的错误，把它赋值给 target（target 必须是指针）。用于提取自定义错误类型，拿到 Code、Metadata 等额外信息。
var apiErr *APIError
if errors.As(err, &apiErr) {
log.Printf("API 错误码: %d, 请求ID: %s", apiErr.Code, apiErr.RequestID)
}
Is 问「是不是这个错误」（比较值），As 问「有没有这种类型的错误」（提取类型）。
