1. 基本类型先搞清楚 Go 的“零值哲学”刚学 Go 的时候我最不习惯的就是一件事变量声明之后不用初始化直接就能用。var i int var s string var ok booli 是 0s 是空字符串ok 是 false。这在 C、Java 里简直不敢想但 Go 就是靠这套“零值机制”把代码写简单了。你定义一个结构体所有字段自动就位不会出现“忘了初始化导致读到随机内存”这种问题。理解这一点比背几个类型关键字重要得多。1.1 整型家族int 和 uint 的坑Go 的整型分两大派系带符号的 int、int8、int16、int32、int64不带符号的 uint、uint8、uint16、uint32、uint64。日常写业务绝大部分场景就用int但这里有个隐蔽的坑int的长度在不同平台不一样。64 位平台上 int 是 64 位32 位平台上 int 是 32 位。如果你写协议解析、二进制文件读写、序列化这类对字节长度敏感的逻辑直接用 int 会埋雷。我踩过一次本地跑测试全通过部署到 32 位 ARM 设备上数据就错位了最后排查半天发现是 int 宽度不一致导致的。从那以后涉及字节长度、网络协议的字段我会显式写死int32或int64业务逻辑层才用int。另外两个别名要记住byte是uint8的别名rune是int32的别名。byte 天生适合处理字节流rune 天生适合处理 Unicode 字符。遍历字符串时如果用for i : 0; i len(s); i拿到的是一堆字节而用for _, r : range s拿到的才是完整的字符这就是 rune 存在的意义。1.2 浮点、字符串与显式转换浮点类型有 float32 和 float64大部分场景直接用 float64。浮点数有个经典问题不能用判断相等。if a b { // 很危险 }正确做法是判断差值绝对值是否小于某个阈值import math if math.Abs(a-b) 1e-6 { }字符串是 Go 里使用频率最高的类型但有几个细节值得注意。第一len(s)返回的是字节数而不是字符数一个中文字符占 3 个字节所以len(你好)是 6。第二字符串是不可变的拼接大量字符串时别用硬拼性能会很差应该用strings.Builder或bytes.Buffer。第三字符串和整数互转不能用强转语法得走strconv包。n, err : strconv.Atoi(123) // 字符串转 int s : strconv.Itoa(123) // int 转字符串Go 没有隐式类型转换int和int64即使都是整型也得显式转。这个设计初看繁琐实际上是在逼你直面类型关系少了很多 C 里面隐式截断的暗坑。1.3 零值和零值设计的意义我把零值单独拎出来说是因为它是 Go 风格里很重要的一环。指针、切片、Map、函数、接口、Channel 的零值都是 nil数值类型是 0布尔是 false字符串是空串。这不只是“编译器帮你初始化”这么简单而是告诉你可以为 0、false、空串写出“无需额外逻辑也能正常工作”的代码。比如bytes.Buffer的零值就是一个可以直接使用的缓冲区sync.Mutex的零值就是一个未锁定的锁很多结构体零值直接可用。反过来看如果你在 Java 里经常写着if (xxx ! null) { ... }到了 Go 你会发现自己写的 nil 判断少了很多因为切片、Map 这类类型对 nil 有“半容忍”的设计读操作是安全的写操作才需要小心。这个特点以后还会反复遇到尤其是看别人代码时如果对方大量判断 nil大概率是没吃透切片和 Map 的语义。2. 数组与切片一字之差天壤之别数组和切片是 Go 里最容易混淆的两个概念但它们的区别非常本质数组是值类型切片是引用类型。2.1 数组是“值”切片是“视图”[5]int和[6]int是两个完全不同的类型数组长度是类型的一部分。你定义var a [5]int把它传给一个函数func foo(arr [5]int)函数内部修改 arr 不会影响外面的 a因为参数传递时整个数组被复制了一份。这个拷贝行为在数组稍微大一点的时候就显得笨重所以 Go 实际开发中直接用数组的地方很少几乎都是切片。切片是什么可以理解为指向底层数组的“视图”包含三部分指针、长度、容量。用小白能听懂的话说切片就像一个滑动窗口窗口露出来的部分len你能直接操作窗口后面还藏着一些预留空间cap等到 append 塞不下时再向底层数组申请扩展。s : make([]int, 3, 5)这里 len 是 3cap 是 5你可以先访问 s[0] 到 s[2]但 cap 说明底层数组已经预备了 5 个位置后续 append 时前三次不会触发扩容这就能省掉一部分内存分配开销。2.2 初始化与 append 扩容切片的初始化方式有好几种看起来长得差不多实际语义并不一样var s1 []int // nil slicelen0cap0 s2 : []int{} // 空切片len0cap0但非 nil s3 : make([]int, 0, 5) // 有容量len0var s1 []int和s2 : []int{}在很多操作上表现一致但有一个肉眼可见的区别JSON 序列化时nil slice 会输出null空切片会输出[]。如果你要对接前端后端返回null和[]在不少框架里是两种语义容易引发判断问题。append 是切片最核心的操作它背后藏着扩容逻辑。Go 1.18 之后的扩容策略大致是在容量小于 256 时直接翻倍大于等于 256 时会按约 1.25 倍的速度增长再结合内存对齐做调整。这个细节不需要背但你要理解一件事append 不总是原地新增当 len 即将撞上 cap 时Go 会分配一块更大的新底层数组把老数据整体搬过去。所以“切片是引用类型”这个说法要打个折扣。切片变量本身传递的是那个窗口结构但底层数组可能被悄悄换掉。函数里对切片做 append如果触发了扩容外层切片变量是感知不到的必须通过返回值拿回新的切片。这也是为什么所有标准库函数里 append 的结果都要重新赋值给原变量s append(s, v)这行代码不是冗余它是在处理底层数组可能更换的情况。2.3 共享底层数组的副作用切片切片本质上还是在操作同一个底层数组。看这个例子a : []int{1, 2, 3, 4, 5} b : a[1:3] // b 指向 a 的底层数组第 1、2 位 b[0] 99 fmt.Println(a) // [1 99 3 4 5]我只改了 ba 也变了。这很反直觉但只要你记住“切片是底层数组的视图”就能想通。更隐蔽的是 append 造成的覆盖a : []int{1, 2, 3, 4} b : a[:2] // len2, cap4 b append(b, 5) // b 变成 [1 2 5]同时 a 变成 [1 2 5 4]因为 b 的 cap 还有富余append 直接写进了 a 底层数组的第 3 个位置把原来的 3 覆盖成了 5。这算是我见过最频繁的新手坑之一。规避方式就是 copy。如果你想把某个切片独立出来彻底断开和原来底层数组的关系就现造一个长度相等的新切片再用内置 copy 搬过去c : make([]int, len(b)) copy(c, b)2.4 nil slice 与空 slice很多人分不清 nil slice 和空 slice 的使用边界。实际规则很简单nil slice 是合法的切片len 是 0append 直接插入元素也没问题几种情况下 nil slice 和空 slice 的行为是一致的。但一旦涉及序列化、反射、比较两者就开始分道扬镳。判断切片是否为空推荐用len(s) 0不要用s nil。因为一个空切片 s2 不等于 nil但长度也是 0逻辑上不应该区分它们。如果你接手了别人的老代码看到一堆if s nil的分支那大概率是在强行区分“未分配”和“已分配但空”这种代码维护起来非常费劲。能用 len 判断就用 len 判断别给自己添乱。3. Map哈希表在 Go 里的正确打开方式Map 是干活的必备工具Go 的 Map 底层是哈希表读写都是 O(1) 的平均复杂度但它的语法和“脾气”有不少细节。3.1 声明、初始化与读写先看两行代码var m map[string]int // nil map m2 : make(map[string]int) // 可用的空 map第一行的 nil map 可以直接做读操作返回零值但不能写写了直接 panic报错信息是assignment to entry in nil map。我做竞赛题时栽过一次原因很简单声明了 map 但忘了 make往里塞数据直接崩。所以初始化 Map 是必不可少的一步日常写代码建议直接用 make 构造。读取不存在的 key 时返回的是 value 类型的零值。这个特性有时候是帮手有时候是坑。你想判断某个 key 是否存在只凭返回值判断不了因为返回值可能是真实存储的零值也可能是“这个 key 不存在”的默认值。正确写法是用逗号 ok 语法v, ok : m[key] if ok { // 存在 }新增和修改都是同一句语法m[k] vGo 在语言层面不区分 upsert 和 update。删除用内置的delete(m, k)就算 key 不存在也不会报错。3.2 并发读写必踩的坑Go 的 Map 不是并发安全的这算是它最大的限制之一。多个 goroutine 同时写同一个 map会直接 panicRuntime 会毫不客气地报fatal error: concurrent map writes不是返回值错误是直接崩溃。有人会问是不是只读就安全严格说当一个 goroutine 对 map 进行写操作时其他 goroutine 连读都不应该做否则同样有隐患。因为 map 在扩容时会 rehash底层结构随时在动。解决方案也很常规用sync.RWMutex自己控制读写锁读并发、写互斥适合大多数业务场景。用第三方并发安全 Map 实现比如分段锁思路的扩展库适合高并发且对性能有要求的场景。用sync.Map:适合“读多写少”且 key 集合比较稳定的场景比如缓存热点配置。但 sync.Map 不是万能药日常业务如果写频率不低性能反而不如普通的加锁 map。3.3 遍历随机性与排序Map 的遍历顺序是随机的这个是语言规范明确规定的不保证你这次遍历和上次遍历的顺序一样。所以任何依赖遍历顺序的代码都是错的。如果非要按固定顺序输出标准做法是把 key 先放进一个切片排序再按切片顺序去 map 里取keys : make([]string, 0, len(m)) for k : range m { keys append(keys, k) } sort.Strings(keys) for _, k : range keys { fmt.Println(k, m[k]) }范围遍历也可以用for k : range m只取 key不需要 value少一次无谓的拷贝。3.4 用 map 做集合空结构体技巧Go 没有原生的 set 类型通常用map[K]struct{}代替。这里的 value 用空结构体struct{}因为空结构体不占任何内存比用 bool 还省那一个字节。判断集合里有没有某个元素set : make(map[string]struct{}) set[go] struct{}{} _, ok : set[go]这种代码在实现去重、集合运算时特别顺手。另外注意map 的 key 必须是可比较类型切片、Map、函数不能作为 key。如果业务上确实需要复杂 key可以先把数据转成字符串再当 key或者自定义一个可比较的 struct 作为 key。4. if 与 nil被低估的两个基础点基础语法总是被人忽略但实际上 if 和 nil 在 Go 里有不少独特的语义理解不到位写出来的代码会时不时抽风。4.1 if 语法少写括号多用初始化Go 的 if 条件不需要括号这个很多人知道。但很多人不知道的是if 支持初始化语句这是 Go 里面非常有用的语法糖if err : doSomething(); err ! nil { // 处理错误 }初始化语句里的变量作用域被限制在 if/else 链里离开这个链就不存在了。好处是 err 不会泄漏到外层不用担心变量被后续代码意外复用。而且这个写法把“调用函数”和“判断返回值”放在同一行语义很紧凑。我见过有人抱怨 Go 的 if 条件里不能像 C 那样直接写if (x someFunc())这反而是优点。Go 在语法层面直接把这种容易混淆的写法堵死了——条件必须是布尔表达式。如果误写成if x 1 {}编译期就会报错不会等到运行时才发现。4.2 nil 不是“空指针”这么简单很多从其他语言转过来的人把 nil 等同于空指针这种理解在 Go 里太片面的。nil 是多种类型的零值指针、切片、Map、函数、接口、Channel 都有各自对应的 nil但它们的表现千差万别。nil slice 可以 append、可以 len一切正常。nil map 可以读但不可以写。nil 指针调用方法会崩溃但是 nil 接口、nil channel 又有各自的规则。把这些关联起来的最好方法是把 nil 理解成“这个类型还没有指向任何具体的存储”。你不需要背全部细节但至少要知道同一件事nil 的表现取决于它属于哪个类型。有一个细节容易被忽略函数类型的零值也是 nil调用 nil 函数会 panic。如果你有个全局函数变量其他 goroutine 可能还没赋值就调用了代码看起来正常运行时突然崩排查起来相当有迷惑性。这时候要想到函数变量也需要初始化和指针一样。4.3 interface 的 nil 陷阱这是我见过的 Go 面试最高频坑也是实际开发里最容易摔的跟头。把 nil 指针放进接口变量后接口本身竟然不等于 nil。var p *int var i interface{} p fmt.Println(i nil) // false原因在于一个非空接口变量内部有两个槽一个是动态类型一个是动态值。当你把 p 赋给 i 时i 的动态类型被设置成了*int虽然动态值还是 nil但类型信息已经存在所以接口不可能是 nil。这个坑在错误处理上特别常见。比如定义一个自定义错误类型正常 nil 返回是没问题的但如果你把一个 nil 的自定义错误指针赋给 error 接口变量再用if err ! nil判断它永远为 true错误处理逻辑直接失效。解决办法是检查接口的动态类型或确保返回时直接返回 nil 而不是一个类型化的 nil 指针。4.4 错误处理if err ! nil 的进阶用法Go 的错误处理离不开if err ! nil但到了 Go 1.13 之后简单比较 err 就变得不够用了。因为错误可能被包装用err io.EOF判断一个已经被 fmt.Errorf 包装过的错误会失败。标准做法是if errors.Is(err, io.EOF) { // 即使 err 被包装过也能识别出它本质上是 io.EOF }还有一个errors.As用于把错误链中特定类型的错误取出来。我建议新项目里统一用 errors.Is 和 errors.As 做错误判断不要再用裸的比较。还有 nil 本身也可以成为错误处理的一部分Go 的 channel 关闭后读操作会立即返回零值区分“数据”和“关闭”要用 ok 标志。这些细节单独看都不难但组合在一起就是工程经验。5. 我的踩坑笔记与速查清单写到这里我把实际开发中反复遇到的问题汇总成一份清单每个都标注了原因和规避方案。这份清单是写给未来的自己看的也顺便分享给正在学 Go 的人。症状原因规避方案map 写入 panicnil map 未初始化先 make 再写切片互相影响共享底层数组需要独立时用 copyinterface 判 nil 失效动态类型已存在不要将类型化 nil 赋给接口遍历 map 顺序诡异规范就是随机先排序 key 再遍历len(中文) 比预期大返回字节数用 []rune 或 range 遍历浮点比较失灵精度问题用差值比较空切片序列化变 nullnil slice用空切片 []T{} 初始化append 后原切片没变扩容更换底层数组必须用返回值重新赋值goroutine 并发写 map 崩溃map 非并发安全加锁或换 sync.Map条件误用赋值语法错误记住 Go 条件必须是布尔最后一个建议也是我自己现在写 Go 的习惯定义变量时先想清楚它的零值是什么这个类型在 nil 状态下哪些操作是安全的哪些会 panic。把这些基础问题在脑子里过一遍很多 bug 在编译之前就能避开。尤其是切片、Map、接口这三类它们的 nil 行为几乎贡献了 Go 新手 80% 的运行时崩溃。排查问题的时候也可以反过来想这大概率又是某个基础语义没吃透导致的。