这八个是日常开发中真正高频、不可绕开的核心标准库，因它们覆盖服务启动、数据进出、资源管理、并发协调、时间控制和格式输出等80%代码场景，其余为按需加载的场景专用库。
fmt、net/http、encoding/json、os、io、sync、context、time 这八个是日常开发中真正高频、不可绕开的核心标准库；其余如 database/sql、crypto、reflect 等，属于按需加载的“场景专用库”，新手初期无需系统学。
为什么不是“全库清单”，而是这八个？
因为 Go 标准库有 200+ 包，但绝大多数项目里，80% 的代码只和这八个打交道。它们覆盖了：服务启动（net/http）、数据进出（encoding/json + io）、资源管理（os）、并发协调（sync + context）、时间控制（time）、格式输出（fmt）。学全不如学透——比如 net/http 里 http.Request.Body 是 io.ReadCloser，不 defer r.Body.Close()，压测时连接会卡死；又比如 encoding/json 中 *string 字段加 omitempty 不生效，必须配合自定义 MarshalJSON 方法。
net/http 和 encoding/json 必须成对理解
几乎所有 API 服务都同时用到这两个库，但它们的协作方式极易出错：
-
r.ParseForm()和json.NewDecoder(r.Body).Decode()不能混用——前者会提前读空Body，后者再读就返回io.EOF -
http.ResponseWriter只允许调用一次WriteHeader()；第二次调用会被静默忽略，状态码永远是第一次的值 - 本地调试建议弃用
http.ListenAndServe，改用http.Server{Addr: ":8080", ReadTimeout: 5 * time.Second}实例启动，避免超时无提示断连 - POST 请求若带 JSON body，别用
r.FormValue("key")——它只读application/x-www-form-urlencoded或multipart/form-data，JSON 得走json.Decode
os + io + bufio：谁关文件、谁可能卡住，得刻在脑子里
文件操作崩得无声无息，问题几乎全出在生命周期和缓冲行为上：
立即学习“go语言免费学习笔记（深入）”；
-
os.OpenFile返回*os.File，必须显式Close()；但defer f.Close()前要先判断f != nil，否则os.OpenFile报错时会 panic -
io.Copy内部用 32KB 缓冲区，适合大文件流式复制；小数据（如写几行日志）用io.WriteString更轻，但它不自动换行，得自己加"\n" -
bufio.Scanner默认单行上限 64KB，读超长日志行会直接Scan() == false且Err()返回bufio.ErrTooLong，需提前调用scanner.Buffer(nil, 1024*1024)扩容
context、sync、time 是并发场景的“安全带”
它们不常单独出现，但一旦缺失，程序会在高并发下悄无声息地泄漏或错乱：
-
context.WithTimeout必须传给下游所有可能阻塞的操作——比如http.Client.Do(req.WithContext(ctx))、db.QueryContext(ctx, ...)，否则超时信号无法传递 -
sync.Map不是万能替代品：它适合读多写少、键固定、无需遍历的场景；普通 map +sync.RWMutex在写较多或需 range 遍历时更可控 -
time.Sleep在测试中很常见，但生产代码里应优先用time.AfterFunc或timer.Reset配合select，避免 goroutine 泄漏
encoding/json 的字段标签、net/http 的 Body 生命周期、os 文件句柄的关闭时机——这些不是“知识点”，而是每天写代码时伸手就碰到的边界条件。标准库从不隐藏复杂性，它只是把责任交还给你。
