sync.Pool适用于对象创建开销大、生命周期短、高并发频繁分配的场景，如net/http中的responseWriter复用；不适用长生命周期资源或含未清零字段的对象，且每次Get后须显式初始化。

什么时候该用 sync.Pool 而不是直接 new

当对象创建开销大（比如 bytes.Buffer、http.Request 临时结构体）、生命周期短、且在高并发下频繁分配时，sync.Pool 才值得引入。盲目套用反而增加 GC 压力和内存碎片——因为 Pool 中的对象不会被 GC 自动回收，只在 GC 时被批量清理。

• 适用场景：net/http 中的 responseWriter 复用、日志格式化缓冲区、JSON 解析临时 map[string]interface{}
• 不适用场景：持有长生命周期资源（如数据库连接）、含指针或未清零字段的对象（必须实现 New 函数并手动重置）
• 关键细节：每次从 Pool.Get() 拿到的对象状态未知，务必显式初始化或清零，不能依赖构造逻辑

for range 遍历切片 vs 索引遍历的可读性陷阱

for i := range s 看似简洁，但若后续需要索引参与计算（比如跳过偶数位、构造带偏移的 key），它反而迫使你额外声明变量或重复调用 len()；而 for i := 0; i 在这类场景下更直白，且现代 Go 编译器对 len(s) 做了常量折叠，无性能损失。

• 优先用 range：仅需元素值、无需索引、不修改原切片
• 优先用索引：需要下标运算、批量处理连续子段、或配合 unsafe.Slice 等底层操作
• 常见错误：在 range 循环里取地址（&v）导致所有指针指向同一栈变量，应改用 &s[i]

interface{} 和泛型函数的取舍边界

Go 1.18+ 泛型不是万能解药。对简单类型转换（如 int → string）、单次调用的工具函数，硬上泛型反而让签名臃肿、IDE 补全变卡；但涉及高频容器操作（排序、查找、映射），泛型比 interface{} + 类型断言快 3–5 倍，且避免运行时 panic。

• 用泛型：函数被多次调用、参数类型固定、需编译期类型约束（如 constraints.Ordered）
• 用 interface{}：适配未知第三方类型、仅做透传（如日志上下文注入）、或类型分支极少（switch v.(type) 不超过 2–3 种）
• 注意：泛型函数无法直接作为 http.HandlerFunc 使用，需显式实例化类型，这点常被忽略

defer 的隐蔽成本与替代方案

defer 让资源释放更安全，但每次调用会生成一个 _defer 结构体并链入 goroutine 的 defer 链表，高频路径（如每请求都 defer mu.Unlock()）会拖慢微秒级函数。此时应权衡：是否真需要异常安全？能否用作用域控制替代？

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

• 保留 defer：涉及 I/O、锁、文件句柄等必须成对出现的资源
• 替换为手动调用：纯内存操作（如 slice 清空、map 删除）、已知不会 panic 的临界区
• 折中方案：把多个 cleanup 合并进一个 defer func(){...}()，减少 defer 链节点数量

真正难的不是选高性能写法，而是判断哪条路径是瓶颈。先用 go tool pprof 确认热点，再改；否则可读性让步于优化，最后谁也看不懂那行 unsafe.Pointer(uintptr(unsafe.Pointer(&s[0])) + uintptr(i)*unsafe.Sizeof(s[0])) 是在干啥。