http.HandleFunc不区分HTTP方法，故POST /login与GET /login均命中同一处理函数，需手动校验r.Method；它也不支持路径参数提取和中间件，路由复杂时易出错。
http.ListenAndServe 默认用的是 nil handler，也就是走 http.DefaultServeMux。它够快、够轻、够直接，但一旦路由变多、需要方法限制、路径参数或中间件，就容易踩坑。
为什么 http.HandleFunc 不能匹配 POST /login？
http.HandleFunc 只看路径前缀，不区分 HTTP 方法。注册 http.HandleFunc("/login", loginHandler) 后，GET /login 和 POST /login 都会进同一个函数——你得自己在函数里判断 r.Method。
- 常见错误现象：表单提交返回 404 或静默失败，其实是 handler 没做方法校验，又没写
w.WriteHeader - 正确做法：要么手动检查
if r.Method != "POST" { w.WriteHeader(http.StatusMethodNotAllowed); return }，要么换支持方法路由的 mux（如gorilla/mux或chi） - 注意：
http.ServeMux本身不支持POST /login这种带方法的注册签名，那种写法会直接 panic
http.ListenAndServe 的第二个参数传 nil 有什么隐患？
传 nil 就是把所有请求甩给 http.DefaultServeMux，它全局唯一、无隔离、不可重置。多个包如果都调用 http.HandleFunc，可能互相覆盖或冲突。
- 典型场景：你引入了一个日志库，它悄悄注册了
/health；你的主逻辑也注册了/health—— 后注册的生效，前者失效，且毫无提示 - 安全影响：第三方依赖可能暴露调试接口（比如
/debug/pprof），而你根本不知道它被挂到了默认 mux 上 - 建议做法：显式创建
http.NewServeMux()，只挂你信任的 handler，然后传给ListenAndServe
如何让 /user/123 中的 123 被提取出来？
http.ServeMux 不支持路径参数解析，r.URL.Path 就是原始字符串，得手动切。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 简单提取：对
/user/做前缀判断，再用strings.TrimPrefix(r.URL.Path, "/user/")拿 ID - 风险点：如果用户访问
/user/123/edit，上面逻辑会得到123/edit，没做边界校验就直接入库会出问题 - 更稳方案：用
gorilla/mux注册r.HandleFunc("/user/{id:\d+}", userHandler)，再通过mux.Vars(r)["id"]安全取值 - 注意：
http.ServeMux对/user/和/user/123是两个独立路径，必须分别注册，否则后者 404
超时没配，服务卡住就一直挂着？
http.ListenAndServe 本身不设读写超时，连接建立后，如果客户端不发数据、或 handler 死循环、或下游服务迟迟不响应，这个 goroutine 就永远卡住。
- 后果：连接数缓慢上涨，最终耗尽文件描述符，新请求连 accept 都失败
- 必须配的三个超时：
ReadTimeout（从 connect 到读完 header）、WriteTimeout（从收到 request 到写完 response）、IdleTimeout（keep-alive 空闲时间） - 实操：别用
http.ListenAndServe，改用&http.Server{Addr: ":8080", Handler: mux, ReadTimeout: 5 * time.Second, ...}.ListenAndServe()
真正难的不是启动服务器，而是当第一个 499 或 502 出现时，你能不能快速定位是路由没配对、handler panic 了、还是超时压根没生效。这些细节不在 hello world 例子里，但在上线前必须确认。
