http.ListenAndServe 默认阻塞且不报错，端口占用或地址写为"localhost:8080"会导致失败；应改用":8080"、加日志、捕获错误并用curl验证。
用 http.ListenAndServe 启动最简服务器，但端口被占或没返回就卡住
Go 的 HTTP 服务默认是阻塞的，http.ListenAndServe 调用后程序不会自动往下走，也不会告诉你为什么没响应。常见错误是端口已被占用（比如另一个 go run 进程还在跑），或者监听地址写成 "localhost:8080" ——这其实会失败，因为 localhost 不是合法的 host 绑定名，得用 ":8080" 或 "0.0.0.0:8080"。
实操建议：
- 启动前加简单日志：
log.Println("server starting on :8080")，确认是否走到这一步 - 捕获错误并打印：
if err := http.ListenAndServe(":8080", nil); err != nil { log.Fatal(err) } - 想快速验证是否跑起来，用
curl -v http://localhost:8080，别只刷浏览器——有些浏览器对空响应会转圈不报错
http.HandleFunc 和 http.Handle 选哪个？注册路由时容易混淆
http.HandleFunc 是语法糖，底层调用 http.Handle；前者接收函数值，后者接收实现了 http.Handler 接口的实例。日常写小服务用 HandleFunc 更轻量，但一旦需要复用逻辑（比如带认证、日志中间件）、或要测试 handler 行为，就得自己实现 ServeHTTP 方法，这时候必须用 http.Handle。
注意点：
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
http.HandleFunc("/api", handler)中的路径匹配是前缀匹配，/api/foo也会进这个 handler，不是全等匹配 - 多个
HandleFunc注册相同路径，后注册的会覆盖前一个，没有警告 - 如果用了
nil作为第二个参数（即http.ListenAndServe(":8080", nil)），就走默认的http.DefaultServeMux，所有HandleFunc都往它上面挂
处理 POST 请求时读不到 Body，r.Body 返回空
根本原因是 Body 是单次读取流，一旦被其他代码提前读过（比如调用 r.ParseForm()、r.FormValue() 或任何触发解析的操作），再手动 io.ReadAll(r.Body) 就只能拿到空字节。这不是 bug，是设计使然。
正确做法取决于你的真实需求：
- 只想取表单字段：直接用
r.FormValue("key")，它内部会自动调用ParseForm，别再碰Body - 要读原始 JSON：先
r.ParseForm()（可选，仅当需同时读 form 和 body），再io.ReadAll(r.Body)——但必须在ParseForm之后立刻读，且只能读一次 - 想兼容多种内容类型（如 JSON + multipart）：用
r.MultipartReader()判断类型，或统一用io.ReadAll读原始体，自己解析，绕开ParseForm
本地开发时热重载没生效，改完代码要手动 Ctrl+C 再 go run
Go 标准库本身不提供热重载，go run main.go 每次都是新进程，旧进程残留会导致端口占用、日志重复、甚至 handler 被双注册（如果用全局 mux）。这不是代码问题，是工作流缺失。
推荐方案（不引入复杂工具）：
- 用
air（轻量，配置少）：go install github.com/cosmtrek/air@latest，然后项目根目录下运行air - 如果只希望“保存即重启”，Mac/Linux 可用
nodemon类思路：nodemon --exec go run main.go --ext "go"（需先npm install -g nodemon） - 更彻底的方式：把服务启动逻辑包进函数里，加个
for循环 +signal.Notify，手动支持 graceful restart ——但这已超出入门范围，多数人没必要
真正容易被忽略的是：哪怕用了热重载，也要检查 http.DefaultServeMux 是否在每次启动时被重复注册 handler。全局变量状态不会随进程销毁而清空，但热重载会起新进程，所以通常没问题；反而是手写循环重启时，老 handler 可能还挂在 mux 上。
