skaffold init 卡住因无法识别构建上下文，需确保 go.mod 在根目录或手动编写 skaffold.yaml；telepresence 请求超时因未 intercept 拦截服务；skaffold dev 重启慢应改用 local 构建+sync 或 build.type: none 配合 air；退出 telepresence 必须运行 telepresence quit 避免残留。
Skaffold init 为什么卡住或报错 no supported builder found
Skaffold 需要识别项目里的构建上下文才能生成配置，它默认靠文件后缀和目录结构猜——比如看到 go.mod 就认为是 Go 项目，但如果你的 main.go 不在根目录、或者用了非标准构建方式（比如用 make build 而非 go build），它就会失败。
- 确保
go.mod在项目根目录；如果不在，先go mod init一下 - 运行
skaffold init --analyze看它识别到了什么，常会发现它把Dockerfile当成唯一构建入口，忽略了 Go 源码 - 手动补一个
skaffold.yaml比硬等init成功更可靠，尤其对 Go 项目——Skaffold 对 Go 的原生支持其实很弱，它更倾向“Dockerfile 优先”
Telepresence connect 后请求超时，curl http://my-service:8080 无响应
这不是网络不通，而是 Telepresence 默认只代理集群内 Service 的 DNS 和流量，不自动把本地进程注册进 Kubernetes Service 的 Endpoints。你本地跑的 Go 服务没被加进 Endpoints，Service 就转发不到它。
- 启动本地 Go 服务前，先运行
telepresence connect，再用telepresence intercept my-service --port 8080 --env-file .env显式声明拦截目标 -
--port必须和你的 Go 服务监听端口一致，且该端口不能被占用；常见坑是本地开了另一个go run main.go占着 8080，导致 intercept 失败但不报错 - 检查
kubectl get endpoints my-service，成功后应该能看到你本地 IP + 端口出现在列表里；没有？说明 intercept 没生效，多半是命名空间不匹配（--namespace漏了）或服务名拼错
Skaffold dev 重启慢、热重载失效，go run main.go 没反应
Skaffold 的 dev 模式默认走容器重建流程：检测文件变化 → 构建新镜像 → 推送 → 重启 Pod。Go 应用编译快，但这一整套流程可能要 20 秒以上，完全失去“开发环境”意义。
- 改用
build.type: local+build.artifacts[].sync，跳过镜像构建，直接把修改后的 Go 文件同步进正在运行的容器 - 更彻底的方案：不用 Skaffold 构建，改用
build.type: none，让 Skaffold 只负责部署和 watch，本地用air或fresh做进程热重启，再配合 Telepresence 拦截流量 - 注意
sync不支持.go文件直接同步执行——容器里得提前装好go环境，并运行go run main.go而非二进制；否则改完代码只会同步过去，不会自动重跑
Telepresence 退出后本地服务还连着集群，kubectl get pods 显示异常
Telepresence 有时没干净清理 iptables 规则或 DNS 设置，导致后续 kubectl 请求被错误路由到本地代理端口，出现连接拒绝或超时，甚至影响其他工具（如 k9s、helm）。
- 退出前务必运行
telepresence quit，别直接 Ctrl+C；如果已经断了，就手动执行sudo telepresence uninstall - 检查
cat /etc/resolv.conf是否被改成指向127.0.0.1—— 这是 Telepresence 的 DNS 代理残留，删掉那行或还原备份 - Mac 用户特别注意：Telepresence 会往
/etc/hosts写一堆cluster.local映射，长期不清理会导致ping my-service.default.svc.cluster.local解析失败，删掉相关行即可
