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 编译器对 <code>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])) 是在干啥。
