net/http可快速构建最小可行http服务：几行代码调用http.handlefunc和http.listenandserve即可启动生产级服务器，无需框架；需检查返回值、处理路由与超时，端口冲突和权限问题须主动应对。
用 net/http 写最小可行服务，别碰框架
Go 做云原生，第一原则是“够用即止”。新手常误以为必须上 Gin/Echo 才算正经微服务，其实 net/http 完全胜任：启动快、无依赖、内存可控、调试透明。Kubernetes 拉起一个 net/http 服务平均耗时
常见错误是把路由逻辑和业务逻辑混写在 http.HandleFunc 里，导致无法单元测试、健康检查难剥离。正确做法是分层：
- 主函数只做监听、信号处理、探针端口分离
- 业务 handler 单独抽成函数，接收
http.ResponseWriter和*http.Request，不依赖全局变量 - 所有外部依赖（DB、Redis、下游 HTTP）通过参数传入，便于 mock
示例片段（非完整程序）：
func main() {
// 主服务
mux := http.NewServeMux()
mux.HandleFunc("/api/v1/users", userHandler)
// 健康探针（独立端口）
healthMux := http.NewServeMux()
healthMux.HandleFunc("/healthz", healthHandler)
go func() { http.ListenAndServe(":8081", healthMux) }() // 8081 专供 livenessProbe
http.ListenAndServe(":8080", mux)
}
func userHandler(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json")
json.NewEncoder(w).Encode(map[string]string{"id": "123", "name": "alice"})
}
配置只从环境变量读，禁用 viper 自动映射
云原生环境下，配置来源必须明确且可审计：os.Getenv 是唯一可信入口。viper 默认开启 AutomaticEnv，会把 FOO_BAR 自动映射为 foo.bar，但 Kubernetes ConfigMap 的 key 名称规则和 Go struct tag 不一致，极易导致配置静默失效。
正确姿势是显式绑定：
- 定义结构体，字段加
mapstructuretag（如db_url string `mapstructure:"DATABASE_URL"`） - 调用
viper.BindEnv("db_url", "DATABASE_URL")，而非viper.AutomaticEnv() - 启动时校验必填字段是否为空，空则
log.Fatal—— Kubernetes 会自动重启，比带病运行更安全
别把配置文件（config.yaml）打进镜像。Dockerfile 里只保留二进制，ConfigMap 或 Secret 由部署侧挂载。
构建多阶段 Docker 镜像，跳过 alpine 运行时
用 golang:alpine 当最终运行镜像，看似轻量，实则埋雷：musl libc 兼容性问题频发（尤其涉及 DNS 解析、TLS 握手），且 alpine 的 apk 包管理器在 CI 中不可缓存、易受源站波动影响。
标准多阶段构建应分三步：
- 构建阶段：用
golang:1.26-slim（Debian base，glibc，稳定）编译，加-ldflags="-s -w"去符号和调试信息 - 运行阶段：用
gcr.io/distroless/static-debian12或scratch，只 COPY 二进制 - 镜像 tag 必须用 Git commit SHA（如
git rev-parse --short HEAD），禁用latest
示例关键行：
FROM golang:1.26-slim AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 go build -a -ldflags '-s -w' -o /usr/local/bin/app . FROM gcr.io/distroless/static-debian12 COPY --from=builder /usr/local/bin/app /app EXPOSE 8080 CMD ["/app"]
健康检查端点必须分离端口 + 超时包裹
Kubernetes 的 livenessProbe 和 readinessProbe 默认超时 1 秒，若和主服务共用同一 http.Server，中间件（如日志、鉴权、trace 注入）可能让探针响应超时，触发误杀 Pod。
必须拆开：
-
/healthz放独立http.Server，监听 8081，只检查内存/协程数/GC 压力，**不连任何外部依赖** -
/readyz可放主服务内，但要用http.TimeoutHandler包裹，超时设为 500ms（严于 K8s 默认） - 所有探针 handler 最后一行必须是
w.WriteHeader(http.StatusOK)，不能只靠fmt.Fprint依赖默认状态码
容易被忽略的是：探针返回内容必须是纯文本或 JSON，且不能含换行符（某些 Ingress 控制器会截断）。最简 /healthz 就该是：
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "text/plain")
w.WriteHeader(http.StatusOK)
w.Write([]byte("ok"))
})
真正麻烦的从来不是写几行 Go 代码，而是让每个环节都对齐云原生的假设：网络不可靠、进程随时被杀、配置动态变更、依赖随时掉线。把 os.Exit 换成 server.Shutdown，把 localhost:6379 换成 redis.default.svc.cluster.local:6379，这些细节才决定服务上线后是稳如磐石，还是三天两头进 CrashLoopBackOff。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
