Go工程规范的关键在于理解设计哲学：go mod init须在项目根目录执行以防模块孤立；sync.Pool仅适用于高频小对象且需重置字段；http.HandlerFunc需显式转换避免panic；抽象如context.Context和io.Reader旨在解耦而非表面功能。
Go语言入门不难，但想写出符合工程规范、能长期维护的代码，必须从第一天就避开“写完能跑就行”的惯性路径。真正的学习卡点不在语法，而在理解 Go 的设计哲学如何约束你的编码选择。
为什么 go mod init 要在项目根目录执行，且不能嵌套？
Go 的模块系统以 go.mod 文件为唯一权威入口，它决定了整个项目的依赖解析边界。一旦在子目录误执行 go mod init，就会生成孤立模块，导致 import 路径错乱、go build 找不到包、CI 构建失败等连锁问题。
- 初始化前先确认当前路径是项目顶层（即包含所有
main.go和业务子包的父目录） - 如果已有
go.mod，再执行go mod init会报错，此时应直接用go mod tidy同步依赖 - 模块名建议用可解析的域名形式（如
github.com/yourname/project），避免用myproject这类本地名，否则后续引入私有包或发布到 GOPROXY 时会出问题
什么时候该用 sync.Pool，又为什么多数时候不该用？
sync.Pool 是为高频分配/释放同类型小对象（如字节缓冲、JSON 解析器实例）设计的缓存机制，但它不解决内存泄漏，也不保证对象复用——GC 可能在任意时刻清理 Pool 中的对象。
- 仅当压测发现
runtime.mallocgc占 CPU 高峰 >15%，且对象生命周期短、结构稳定时才考虑引入 - 切勿把含外部状态（如已打开的文件句柄、未关闭的 HTTP 连接）的对象放入 Pool，Pool 不调用析构逻辑
- 使用前必须重置对象字段（如
buf = buf[:0]），否则上一次残留数据会污染下一次使用 - 替代方案优先考虑栈上分配（
var buf [1024]byte）或预分配切片（make([]byte, 0, 1024)）
http.HandlerFunc 和 http.Handler 的接口转换为什么总出 panic？
根本原因是把函数类型误当成接口类型直接赋值，而 Go 不允许函数值隐式转为接口值，必须显式转换或包装。
立即学习“go语言免费学习笔记（深入）”；
- 正确写法：
http.Handle("/path", http.HandlerFunc(myFunc))，不是http.Handle("/path", myFunc) - 如果
myFunc参数签名不是(http.ResponseWriter, *http.Request)，编译会直接报错，无需运行时 panic - 自定义中间件链中，常见错误是返回
func(http.ResponseWriter, *http.Request)却忘了用http.HandlerFunc()包一层再传给next.ServeHTTP - 更健壮的做法是统一用结构体实现
http.Handler接口，便于注入依赖和单元测试
真正卡住人的从来不是某个函数怎么用，而是没想清楚「这个抽象是为了解决哪一层的耦合」。比如 context.Context 不是为传参而存在，是为取消传播和超时控制；io.Reader 接口的意义不在读数据，而在解耦数据源与处理逻辑。这些点不靠抄代码，得靠重读标准库里三五个典型实现才能真正沉下去。
