skaffold不能直接替代本地go run，它不编译也不运行go代码；其作用是协调容器生命周期——监听文件变化、重建镜像、部署到k8s、启动portforward，真正的go进程始终在容器内运行。
Skaffold 能否直接替代本地 go run？不能，它不编译也不运行 Go 代码本身
Skaffold 不是 Go 的构建器或调试器，它不调用 go build 或 go run，也不启动 Delve。它的角色是协调容器生命周期：监听文件变化 → 触发镜像重建 → 推送 → 部署到 Kubernetes → 启动端口转发。你在本地看到的“热更新”，其实是 Skaffold 检测到源码变动后，自动重建镜像、重启 Pod，并把新 Pod 的端口映射回本地。真正的 Go 进程始终运行在容器里。
必须启用 portForward 才能本地调试微服务间调用
默认情况下，Skaffold 部署的 Pod 只暴露 Service ClusterIP，本地无法直连。若前端服务要调用后端服务（比如 http://leeroy-app:8080），必须显式配置 portForward，否则会遇到连接拒绝或 DNS 解析失败。
-
skaffold.yaml中需添加portForward块，例如转发后端服务的 8080 端口到本地 8081：
portForward: - resourceType: service resourceName: leeroy-app port: 8080 localPort: 8081
- 这样你本地
curl http://localhost:8081/health就能命中集群中的leeroy-appPod； - 前端代码中仍应使用 Kubernetes 内部 DNS 名（
leeroy-app），而非localhost—— 因为该请求实际由 Pod 发起，走的是集群网络； - 若跳过这步，本地开发时容易误写成
http://localhost:8080，上线后必然报错。
Go 微服务要可调试，Dockerfile 和 deployment.yaml 必须协同改造
仅靠 Skaffold 无法让 Go 进程支持远程断点。Delve 必须嵌入容器并暴露端口，且 Kubernetes 层需允许该端口通信和非 root 权限执行。
- Dockerfile 中需用
dlv启动命令，且禁用优化：CGO_ENABLED=0 go build -gcflags="all=-N -l" -o /app/main .； -
deployment.yaml中必须设置securityContext.runAsUser: 0，否则 Delve 因权限不足静默失败； - 必须显式开放
containerPort: 2345并加入ports列表，否则 Skaffold 的portForward无法绑定； - 务必关闭 readiness/liveness 探针——它们会在 Delve 启动前就杀掉容器，导致调试会话无法建立。
环境变量注入服务地址时，别混淆 host 和 port 字段
Skaffold 支持通过 serviceRef 自动注入服务 Host，但不会注入 Port。常见错误是只配了 LEEROY_APP_SERVICE_HOST，却在 Go 代码里硬写 :8080，结果上线后因 Service 端口名变更（如从 http 改成 web）而失效。
- 正确做法：在
deployment.yaml的env块中同时注入 Host 和 Port：
- name: LEEROY_APP_SERVICE_HOST
valueFrom:
serviceRef:
name: leeroy-app
- name: LEEROY_APP_SERVICE_PORT
valueFrom:
serviceRef:
name: leeroy-app
port: 8080
- Go 代码中拼接 URL 时用
os.Getenv("LEEROY_APP_SERVICE_HOST") + ":" + os.Getenv("LEEROY_APP_SERVICE_PORT")； - 注意
serviceRef.port是 Service 中ports[0].port的值，不是容器的containerPort。
真正卡住人的地方，往往不是 Skaffold 配置语法，而是 Kubernetes 网络模型与本地开发直觉之间的错位——比如以为转发了端口就能用 localhost 替代服务名，或者以为注入了 Host 就自动有了 Port。这些细节不验证，调试链路就断在第一跳。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
