1. 基本类型：先搞清楚 Go 的“零值哲学”
刚学 Go 的时候，我最不习惯的就是一件事：变量声明之后不用初始化，直接就能用。
var i int var s string var ok booli 是 0，s 是空字符串，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 是 3，cap 是 5，你可以先访问 s[0] 到 s[2]，但 cap 说明底层数组已经预备了 5 个位置，后续 append 时前三次不会触发扩容，这就能省掉一部分内存分配开销。
2.2 初始化与 append 扩容
切片的初始化方式有好几种，看起来长得差不多，实际语义并不一样：
var s1 []int // nil slice，len=0，cap=0 s2 := []int{} // 空切片，len=0，cap=0，但非 nil s3 := make([]int, 0, 5) // 有容量，len=0var 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]我只改了 b，a 也变了。这很反直觉，但只要你记住“切片是底层数组的视图”，就能想通。更隐蔽的是 append 造成的覆盖：
a := []int{1, 2, 3, 4} b := a[:2] // len=2, cap=4 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 是 0，append 直接插入元素也没问题，几种情况下 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] = v，Go 在语言层面不区分 upsert 和 update。删除用内置的delete(m, k)，就算 key 不存在也不会报错。
3.2 并发读写：必踩的坑
Go 的 Map 不是并发安全的，这算是它最大的限制之一。多个 goroutine 同时写同一个 map，会直接 panic，Runtime 会毫不客气地报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 写入 panic | nil map 未初始化 | 先 make 再写 |
| 切片互相影响 | 共享底层数组 | 需要独立时用 copy |
| interface 判 nil 失效 | 动态类型已存在 | 不要将类型化 nil 赋给接口 |
| 遍历 map 顺序诡异 | 规范就是随机 | 先排序 key 再遍历 |
| len("中文") 比预期大 | 返回字节数 | 用 []rune 或 range 遍历 |
| 浮点比较失灵 | 精度问题 | 用差值比较 |
| 空切片序列化变 null | nil slice | 用空切片 []T{} 初始化 |
| append 后原切片没变 | 扩容更换底层数组 | 必须用返回值重新赋值 |
| goroutine 并发写 map 崩溃 | map 非并发安全 | 加锁或换 sync.Map |
| 条件误用赋值 | 语法错误 | 记住 Go 条件必须是布尔 |
最后一个建议，也是我自己现在写 Go 的习惯：定义变量时先想清楚它的零值是什么，这个类型在 nil 状态下哪些操作是安全的，哪些会 panic。把这些基础问题在脑子里过一遍，很多 bug 在编译之前就能避开。尤其是切片、Map、接口这三类，它们的 nil 行为几乎贡献了 Go 新手 80% 的运行时崩溃。排查问题的时候也可以反过来想：这大概率又是某个基础语义没吃透导致的。
