部署Go函数到Knative需先编译为静态二进制，放入distroless镜像并设ENTRYPOINT；监听:8080、处理/healthz、避免init阻塞、显式传环境变量与revision名。
用 kn service create 部署 Go 函数前必须打包成可执行二进制
Knative 不运行源码，只运行容器镜像里的可执行文件。Go 函数不能直接扔进去，得先编译成静态链接的 main 二进制（Linux AMD64），再塞进轻量基础镜像（比如 gcr.io/distroless/static:nonroot）。
常见错误现象：exec format error（架构不匹配）、no such file or directory（动态链接缺失）、permission denied（没加 chmod +x 或非 root 用户无法执行）。
- 编译命令必须加
CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"' -o handler . - Dockerfile 里别用
FROM golang:alpine做 runtime 镜像——它只是构建环境；最终镜像应基于 distroless，且COPY handler /handler后要RUN chmod +x /handler - 入口点写死为
ENTRYPOINT ["/handler"]，别依赖CMD覆盖，Knative 对 CMD 解析不稳定
HTTP 处理函数必须监听 :8080 并响应健康检查
Knative 的 activator 和 queue-proxy 会向你的服务发 GET /healthz 和 GET /（取决于配置），如果 handler 没监听 :8080 或没处理这些路径，就会卡在 ContainerCreating 或反复 CrashLoopBackOff。
Go 代码里别用 http.ListenAndServe(":3000", nil)，也别依赖环境变量取端口——Knative 固定注入 PORT=8080，但你得显式读取并用：
立即学习“go语言免费学习笔记（深入）”；
port := os.Getenv("PORT")
if port == "" {
port = "8080"
}
http.ListenAndServe(":"+port, mux)
-
/healthz必须返回 200，哪怕只是w.WriteHeader(200)；否则 readiness probe 失败 - 别在
init()里做重试连接 DB 或远程 API——冷启动时可能超时，触发 Knative 的快速重启策略 - 所有 HTTP handler 必须设置
Content-Type: text/plain; charset=utf-8或对应类型，否则某些版本 queue-proxy 会截断响应体
kn CLI 部署时 --env 和 --revision-name 容易被忽略但影响极大
Go 函数常依赖环境变量传配置（如数据库地址、feature flag），但 kn service create 默认不继承本地 shell 环境，也不自动滚动新 revision——这意味着改了 env 不重启服务，或者并发更新时两个 revision 共存却没流量切分。
- 传环境变量必须显式写
--env DB_URL=xxx --env MODE=prod，不能靠.env文件或export后直接跑命令 - 每次变更都建议加
--revision-name myfunc-v2，否则 Knative 自动生成名字（如myfunc-00002-deployment），难追溯、难 debug - 若想灰度，得配合
--traffic：比如--traffic myfunc-v1=90 --traffic myfunc-v2=10，不设就全量切到最新 revision
Go 函数冷启动延迟高？关键在 init() 和依赖初始化时机
Go 本身启动快，但 Knative 的冷启动慢往往来自两处：一是 init() 做了阻塞操作（如连 Redis、加载大文件），二是用了带 heavy init 的第三方库（如 github.com/aws/aws-sdk-go 默认初始化所有服务）。
- 把 DB 连接池、缓存 client 的创建移到 handler 内部首次调用时（加 sync.Once），而不是包级变量或 init()
- 避免在
import _ "net/http/pprof"——它会在 init 里注册路由，而 Knative 的 queue-proxy 已经占了 /debug/* - 用
go mod vendor+-mod=vendor编译，减少镜像内 GOPATH 查找开销；实测 vendor 后冷启动降低 150~300ms
真正卡住的往往不是 Go 编译或 HTTP 启动，而是你以为“只执行一次”的代码，在每个 Pod 的生命周期里被反复执行——Knative 的 scale-to-zero 机制会让进程彻底退出，下次请求就是全新进程。
