OpenFaaS Go函数需定义Handle函数而非main，签名须为func([]byte)([]byte, error)；部署404因函数名/服务名/路由不一致；请求头转为Http_X_*环境变量，需在stack.yml声明；高并发时应限制CPU内存并设GOMAXPROCS=1。
Go 函数怎么写进 OpenFaaS 的 handler？
OpenFaaS 的 Go 模板默认用 main.Handle 作为入口，不是 main()。你写个标准 Go 程序直接扔进去会 panic：找不到 Handle 函数。
- 必须定义一个签名为
func (string) string或func ([]byte) ([]byte, error)的Handle函数 - 模板里已 import
github.com/openfaas/faas-provider/types，但别自己引入 provider 包来写 HTTP 逻辑——OpenFaaS 已帮你把请求 body 解成字节流传进来 - 返回值是
[]byte就自动当响应体；如果返回error，OpenFaaS 会转成 500 并带上错误消息（注意：不是 stack trace） - 示例：
package main import "fmt" func Handle(req []byte) ([]byte, error) { name := string(req) if name == "" { name = "World" } return []byte(fmt.Sprintf("Hello, %s!", name)), nil }
为什么本地 faas-cli build 成功但部署后调用返回 404？
常见原因是函数名、服务名、路由路径三者没对齐，OpenFaaS 不会自动补全或纠错。
-
faas-cli deploy时指定的--name必须和stack.yml里的service字段一致，且只能含小写字母、数字、短横线 - 调用地址是
http://<gateway>/function/<service-name>，不是/functions/...或/invoke/... - 如果你改过
stack.yml里的image:，确保镜像已推送到 registry（比如 Docker Hub），且 gateway 能拉取——私有 registry 需配docker-registry-secret - 检查
faas-cli list输出，确认状态是Ready，不是Pending或ImagePullBackOff
如何在 Go 函数里读取环境变量和请求头？
OpenFaaS 把 HTTP 请求头转成 X-Forwarded-* 和 X-Call-* 前缀注入，不直接透传原始 header；环境变量则完全可用，但得提前在 stack.yml 里声明。
- 请求头：通过
os.Getenv("Http_X_Forwarded_For")获取客户端 IP（注意大小写转换规则：-后首字母大写，Http_是固定前缀） - 自定义 header 如
X-Api-Key→Http_X_Api_Key；空格和下划线会被忽略，只保留字母数字和短横 - 环境变量：在
stack.yml的environment:下写死，或用environment_file:引入.env；运行时用os.Getenv("MY_VAR")读取 - 别在
init()里读环境变量——函数可能被复用，但环境变量不会变；但别假设它“一直存在”，要加非空判断
并发高时 Go 函数 CPU 占用飙升甚至 OOM？
OpenFaaS 默认为每个函数实例分配 1 个 worker 进程，但 Go runtime 会按 GOMAXPROCS 启动多个 OS 线程，默认是 CPU 核心数。容器资源限制没配好时，就会抢宿主机资源。
立即学习“go语言免费学习笔记（深入）”；
- 在
stack.yml中显式限制：limits: memory: 128Mi cpu: 250m
- 启动时加
GOMAXPROCS=1环境变量（适用于 I/O 密集型函数），避免 goroutine 调度开销过大 - 别在
Handle里启 goroutine 后不等它结束——OpenFaaS 不会等后台任务，响应一发就回收实例，goroutine 可能被粗暴终止 - 日志别用
log.Printf打大量调试信息，stdout/stderr 是同步写 gateway 的，高并发下易成瓶颈；用结构化日志库（如zerolog）并控制 level
