http.ListenAndServe是阻塞调用，会卡住当前goroutine持续监听请求，不返回则后续代码永不执行；必须检查错误、确保端口格式为":8080"、避免裸用nil handler，需协程化或http.Server实现并发与优雅退出。
http.ListenAndServe 是阻塞调用，不返回就代表服务在跑
它不会“启动后继续执行下一行”，而是卡住当前 goroutine，持续监听并分发请求。如果你在 http.ListenAndServe 后面写了日志、关闭文件或清理逻辑，那些代码永远不会运行——除非函数返回错误（比如端口被占、地址格式错）。
常见误写：
- 把
http.ListenAndServe放在main()中间，后面还跟了其他业务逻辑 → 那些逻辑永远不执行 - 没用
log.Fatal或显式检查错误 → 服务 panic 退出时控制台静默，你以为“没反应”，其实是崩溃了没提示 - 写成
http.ListenAndServe("8080", nil)（漏掉冒号）→ 直接 panic：listen tcp: address 8080: missing port in address
端口字符串必须带冒号，":8080" 不等于 "8080"
http.ListenAndServe 的第一个参数是网络地址，不是单纯端口号。Go 要求格式为 "host:port"，其中 host 可省略（空字符串等价于 "0.0.0.0"），但冒号和 port 缺一不可。
正确写法：
立即学习“go语言免费学习笔记（深入）”；
-
":8080"→ 监听所有 IPv4/IPv6 接口的 8080 端口（最常用） -
"127.0.0.1:8080"→ 只响应本机请求，外部无法访问（适合调试） -
"0.0.0.0:8080"→ 显式绑定所有 IPv4 接口（和":8080"行为一致）
错误写法："8080"、8080（非字符串）、": 8080"（带空格）都会导致 panic。
handler 参数为 nil 时走全局 DefaultServeMux，但不推荐用于生产
传 nil 给 http.ListenAndServe 第二个参数，等价于用 http.DefaultServeMux，也就是所有 http.HandleFunc 注册的路由都归它管。这很轻量，但有隐患：
- 多个包 import 后悄悄调用
http.HandleFunc，路由冲突或覆盖不易察觉 - 无法单独测试某段路由逻辑（因为依赖全局状态）
-
http.DefaultServeMux不支持子路径自动重定向、正则匹配、中间件包装等现代需求
更可控的做法是显式创建 mux：
mux := http.NewServeMux()
mux.HandleFunc("/health", healthHandler)
mux.HandleFunc("/api/data", dataHandler)
log.Fatal(http.ListenAndServe(":8080", mux))
想启动服务同时做别的事？必须起 goroutine，但要小心错误丢失
如果需要在 Web 服务运行期间定时刷新缓存、监听信号、上报指标，就得把 http.ListenAndServe 放进 goroutine：
go func() {
if err := http.ListenAndServe(":8080", mux); err != nil {
log.Printf("HTTP server error: %v", err)
}
}()
但注意两点：
- goroutine 内的 panic 不会终止主程序，错误容易被吞掉 → 务必加日志，别只写
if err != nil { return } - 主 goroutine 不能直接退出（比如没加
select {}或time.Sleep），否则整个进程立即结束，Web 服务跟着挂 - 更稳妥的方式是用
http.Server结构体，配合srv.Shutdown实现优雅退出，但这已超出ListenAndServe的能力范围
真正难的不是写对那行 http.ListenAndServe，而是理解它背后没有“后台线程”概念——Go 的并发模型里，阻塞是常态，调度靠 goroutine，错误处理靠显式判断。漏掉一个冒号、少捕获一次 err、没意识到它不返回，都可能让服务启而不动、动而不响、响而无日志。
