不能直接用http.listenandserve(":8080", nil)，因它依赖全局http.defaultservemux易路由冲突，无超时控制致连接耗尽，不支持https跳转、结构化日志及精确路径匹配。
http.ListenAndServe 是 Go 启动 HTTP 服务最直接的方式，但仅靠它写不出健壮的服务——它默认不设超时、不控制连接数、不处理 HTTPS 重定向、不支持细粒度日志或中间件。真正上线的 HTTP 服务几乎从不用 nil 作为第二个参数。
为什么不能直接用 http.ListenAndServe(":8080", nil)
这个调用看似简洁，实则埋了多个运行时隐患：
-
http.DefaultServeMux是全局单例，多个包调用http.HandleFunc会互相污染路由，尤其在引入第三方库（如 prometheus/client_golang）时容易冲突 - 没有读写超时控制：客户端不关闭连接，
net/http默认永久等待，可能耗尽文件描述符 - 无法设置
MaxHeaderBytes或ReadBufferSize，攻击者可发送超长 header 导致内存暴涨 - 错误日志只打到
log.Fatal，无法接入结构化日志系统（如 zap）
正确做法是显式构造 *http.Server 实例，哪怕只是覆盖几个关键字段。
http.ListenAndServeTLS 必须配对提供证书与私钥路径
调用 http.ListenAndServeTLS(":443", "cert.pem", "key.pem", nil) 时，两个文件必须同时存在且权限合理（私钥不应为 world-readable）。常见错误包括：
- 路径写错：
"./certs/cert.crt"和"./certs/key.key"不在同一目录，或用了相对路径但二进制运行位置不同 - 证书链不完整：权威 CA 签发的证书常需拼接 intermediate cert，否则某些客户端（如 iOS）会校验失败
- 私钥密码保护：Go 标准库不支持加载加密私钥，必须先用
openssl rsa -in key.pem.enc -out key.pem解密
开发阶段可用 generate_cert.go（Go 源码自带工具）快速生成自签名证书，但仅限测试。
HTTP 自动跳转 HTTPS 的陷阱
监听 :80 并 301 跳转到 https://... 时，别直接拼接 r.Host：
-
r.Host可能带端口（如localhost:8080），跳转后变成https://localhost:8080:443/...，明显错误 - 反向代理（如 Nginx）转发时，真实域名在
X-Forwarded-Host头里，但该头不可信，需白名单校验 - 若后端服务本身跑在容器或负载均衡后，
r.TLS永远为nil，得靠X-Forwarded-Proto: https判断
更安全的做法是：配置反向代理做跳转（Nginx / Caddy），或在 Go 中用固定域名白名单 + r.Header.Get("X-Forwarded-Proto") == "https" 组合判断。
路由注册顺序影响匹配结果
http.ServeMux 是前缀匹配，不是全路径匹配。比如：
http.HandleFunc("/users", userIndexHandler)
http.HandleFunc("/users/profile", userProfileHandler)
访问 /users/profile 时，userIndexHandler 会被先命中（因为 /users 是 /users/profile 的前缀），userProfileHandler 永远不会执行。
- 解决办法：把更具体的路径写在前面，或者改用
gorilla/mux、chi等支持精确匹配的路由器 - 标准库
http.ServeMux不支持路径参数（如/users/{id}），硬编码/users/123会匹配失败 - 若必须用标准库，可用
r.URL.Path手动截取和解析，但失去路由表可读性
生产环境建议尽早切换到 chi：轻量、无反射、中间件友好，且兼容 http.Handler 接口。
真正的难点不在启动一行代码，而在于你是否意识到 http.ListenAndServe 那个 nil 参数背后藏着多少默认行为——它们在本地跑得飞快，一上生产就咬人。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
