直接用 http.listenandserve 能跑起来，但别在生产环境这么干：它缺乏超时控制、无法优雅关闭、不限制请求头大小、panic 会直接终止服务，且使用默认零值配置（如 readtimeout=0、maxheaderbytes 默认值）。
直接用 http.ListenAndServe 能跑起来，但别在生产环境这么干
刚写完 http.HandleFunc 加 http.ListenAndServe 就看到 “Server starting…” —— 这确实能响应请求，但背后藏着几个硬伤：没有超时控制、无法优雅关闭、不设最大请求头大小、panic 会直接 kill 整个服务。你本地调试没问题，一上服务器，连接堆积、大文件上传卡死、异常崩溃后进程消失，全是它惹的祸。
-
http.ListenAndServe使用的是包级默认http.DefaultServeMux和无配置的隐式http.Server，所有参数都走零值 - 比如
ReadTimeout是 0（无限等待），MaxHeaderBytes默认是1（1MB），但很多攻击载荷就卡在这儿 - 调用
http.ListenAndServe后，一旦发生 panic，goroutine 退出，服务静默中断，连日志都不留
必须手动构造 http.Server 实例，而不是依赖包级函数
真正可控的起点，是显式声明一个 http.Server 结构体。这不是“过度设计”，而是把关键开关握在自己手里。你不需要一开始就写中间件或路由框架，但至少得把超时、监听地址、错误处理这几项钉死。
-
Addr必须明确指定，比如":8080"；空字符串或遗漏会导致监听失败，错误信息是"listen tcp: address : missing port" -
ReadTimeout和WriteTimeout建议设为 5–10 秒，避免慢连接拖垮整个服务 -
IdleTimeout推荐设为 60–120 秒，防止 keep-alive 连接长期挂起占用资源 -
Handler别传nil，哪怕只是用http.NewServeMux()，也比默认 mux 更易扩展
http.ServeMux 够用，但路径匹配规则容易踩坑
http.ServeMux 是标准库自带的多路复用器，对小项目完全够用，但它的匹配逻辑不是“最长前缀”也不是“完全匹配”，而是“注册顺序 + 前缀优先”。这意味着你注册 /api 在前、/api/users 在后，后者永远不会被命中。
- 注册顺序敏感：先注册的路径，只要满足前缀匹配，就直接执行，不再往后找
-
/static/会匹配/static/css/main.css，也会匹配/staticx—— 因为它只做前缀判断，不校验路径分隔符 - 没有通配符支持（如
/users/{id}），想实现变量路由必须自己解析r.URL.Path - 如果需要子路径隔离，建议用嵌套
http.ServeMux或直接换gorilla/mux，别硬绕
启动和关闭必须成对处理，否则 SIGTERM 会杀不掉进程
用 http.ListenAndServe 启动的服务，收到 SIGTERM 信号后不会释放监听端口、不等待活跃连接结束，直接退出。Kubernetes 或 systemd 下滚动更新时，旧 pod 可能还在处理请求，新实例已上线，导致 502 或数据丢失。
- 用
s.ListenAndServe()启动后，要另起 goroutine 监听系统信号（如os.Interrupt、syscall.SIGTERM） - 收到信号后调用
s.Shutdown(ctx)，并传入带超时的context，确保连接有时间完成 -
Shutdown不会主动 close listener，你得在 defer 里补上s.Close()防止 fd 泄漏 - 常见错误是只调
Shutdown却没等它返回，或者 context 超时太短（低于最慢请求耗时）
实际跑起来的最小安全模板，核心就这四行：
srv := &http.Server{Addr: ":8080", Handler: mux, ReadTimeout: 5 * time.Second, WriteTimeout: 5 * time.Second}
go func() { log.Fatal(srv.ListenAndServe()) }()
<!-- 省略信号监听和 Shutdown 调用 -->
真正麻烦的从来不是写 handler，而是让 server 活得稳、退得干净。这些点不提前想清楚，后面加 metrics、加 tracing、加 TLS 的时候，全得返工。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
