Go HTTP服务启动需注意监听地址、错误处理和超时配置：ListenAndServe默认绑定所有网卡，空addr非仅localhost；Serve更可控，支持自定义Server参数；常见失败因端口占用、panic未捕获或hosts配置异常。
Go 自带 net/http，不用装第三方框架就能跑起一个可用的 HTTP 服务——关键不是“能不能”，而是“怎么避免踩坑”。
用 http.ListenAndServe 启动最简服务
这是最直接的方式，但默认行为容易让人困惑：监听地址写错、端口被占、没处理 panic 都会导致服务静默失败。
-
http.ListenAndServe第一个参数是addr，传空字符串""表示"localhost:8080"，但实际会绑定到":8080"（即所有网卡），不是仅限本地；如需只限本地，显式写"127.0.0.1:8080" - 第二个参数是
http.Handler，传nil会使用默认的http.DefaultServeMux，此时必须提前用http.HandleFunc注册路由 - 该函数阻塞执行，且不返回错误日志——出错时直接返回非 nil error，必须手动检查并打印
package mainimport ( "fmt" "log" "net/http" )
func main() { http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { fmt.Fprintln(w, "Hello, Go!") })
log.Println("Server starting on :8080") if err := http.ListenAndServe(":8080", nil); err != nil { log.Fatal(err) // 不加这行，端口被占时你根本不知道哪错了 }}
为什么
http.Serve比ListenAndServe更可控当你需要复用已创建的
net.Listener（比如要复用 TLS 配置、限制连接数、或做端口重用），http.Serve是更底层也更灵活的选择。立即学习“go语言免费学习笔记（深入）”；
-
http.ListenAndServe内部就是先调net.Listen再调http.Serve，多了一层封装，反而藏了细节 - 用
http.Serve可以捕获 listener 创建失败（如端口权限不足）、可提前设置http.Server的超时、IdleTimeout、MaxHeaderBytes 等参数 - 调试时可把 listener 设为
tcp4或tcp6显式指定协议族，避免双栈行为不一致
package mainimport ( "log" "net/http" "net" )
func main() { ln, err := net.Listen("tcp", ":8080") if err != nil { log.Fatal(err) } defer ln.Close()
server := &http.Server{ Handler: http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { w.WriteHeader(200) w.Write([]byte("OK")) }), ReadTimeout: 5 * time.Second, WriteTimeout: 10 * time.Second, } log.Println("Server listening on :8080") log.Fatal(server.Serve(ln)) // 注意：这里用 Serve 而非 ListenAndServe}
常见启动失败原因和快速排查点
90% 的“服务没起来”问题都集中在监听地址、端口、错误处理这三处，而不是代码逻辑。
- 错误信息只显示
listen tcp :8080: bind: address already in use？用lsof -i :8080（macOS/Linux）或netstat -ano | findstr :8080（Windows）查 PID，再kill -9或任务管理器结束 -
浏览器访问
http://localhost:8080显示连接被拒绝？确认程序确实在运行（ps aux | grep your_binary），且没因 panic 退出（加defer+recover或用go run直接看终端输出） - 用
127.0.0.1:8080能通，但localhost:8080不行？检查系统 hosts 是否注释了127.0.0.1 localhost，或 DNS 解析异常 - 服务启动后立即退出？检查是否漏了
log.Fatal或os.Exit，或main()函数末尾没阻塞（比如忘了log.Fatal(server.Serve(...))）
真正麻烦的不是写几行代码启动服务，而是让服务在不同环境（开发机、Docker、CI）下稳定响应请求——地址绑定方式、错误传播路径、超时配置，这些细节一旦忽略，线上就只能靠日志盲猜。
