http.listenandserve不适合生产环境，因它缺乏超时控制、优雅关闭和错误隔离能力，仅用默认server和defaultservemux，无法设置readtimeout/writetimeout/idletimeout，且会全局复用路由导致冲突。
http.ListenAndServe 不能直接用于生产环境，它缺少超时控制、优雅关闭和错误隔离能力。用它跑 demo 可以，但一上线就容易挂。
为什么 http.ListenAndServe 不适合生产
它只是个快捷封装，背后用的是 http.DefaultServeMux 和默认 http.Server 实例，所有配置都不可调。
- 没有
ReadTimeout/WriteTimeout：慢请求会一直占着连接，拖垮整个服务 - 无法优雅关闭：
Ctrl+C或 kill 信号会直接中断正在处理的请求，导致客户端收不到响应 - 全局复用
DefaultServeMux：第三方库（比如某些监控 agent）可能偷偷注册路由，引发冲突或安全风险 - 错误日志全打到 stdout，没法单独捕获或分级
必须显式构造 http.Server 的三个理由
这是 Go HTTP 服务上线前最关键的一步，绕不开。
-
Addr字段要明确指定监听地址，避免绑定到0.0.0.0:8080暴露在公网（开发用没问题，上线得改） -
Handler必须传你自己的*http.ServeMux或框架路由实例，别再传nil -
IdleTimeout建议设为 60–120 秒：防止长连接空耗资源；ReadTimeout和WriteTimeout推荐统一设为 10 秒，防住大部分异常读写
示例：
server := &http.Server{
Addr: ":8080",
Handler: mux,
ReadTimeout: 10 * time.Second,
WriteTimeout: 10 * time.Second,
IdleTimeout: 60 * time.Second,
}
http.ServeMux 路由匹配的坑
它只做前缀匹配，不支持路径参数、正则或 RESTful 风格，但很多人误以为它能。
- 注册
/api，会同时匹配/api、/api/users、/api/xxx/yyy—— 没有“精确匹配”概念 -
/api/和/api是两个不同路径：/api/能匹配子路径，/api只匹配自身（且末尾不能多斜杠） - 重复注册同一路径会 panic，错误是
http: multiple registrations for /path，不是运行时报错，是启动时就崩 - 不解析 URL 路径参数，
/user/123中的123得自己从r.URL.Path截取
什么时候该换路由库
当你的路由开始出现这些信号，就该考虑 chi、gorilla/mux 或 Gin 了：
- 需要
/users/{id}这种带变量的路径 - 不同方法（
GET/POST）共用同一路径，但逻辑完全不同 - 想给某组路由统一加中间件（比如鉴权），而不是每个 handler 都写一遍
- 路由数量超过 10 个，维护
http.HandleFunc调用变得容易漏、难测试
注意：chi 是最轻量的兼容替代，API 几乎和原生一致；gorilla/mux 功能更全但稍重；Gin 性能好但引入了新范式，替换成本高。
真正麻烦的从来不是写第一行 http.HandleFunc，而是等服务跑了一周后，发现某个没设超时的健康检查接口把所有连接池耗尽，或者某次部署因为没关 server 导致新旧进程抢端口。这些点不提前卡死，后面花十倍时间都未必能复现清楚。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
