不建议将Go微服务直接扔进Serverless，因其长期运行、状态管理、服务发现等特性与Serverless无状态、短生命周期、事件驱动的本质冲突；真正适合的是API网关后端、定时任务、对象存储触发、消息队列消费者及BFF层等一次调用、快速响应场景。
Go 微服务要不要直接扔进 Serverless？
多数情况下，不建议。微服务强调长期运行、状态管理、服务发现和健康检查；Serverless 函数是短生命周期、无状态、事件驱动的执行单元。硬套会导致 gRPC 通信失败、连接池失效、context 超时频繁、健康探针被平台忽略等问题。
真正适合 Serverless 的 Go 场景是：API 网关后端、定时任务（cron）、对象存储触发（如 S3 → Lambda）、消息队列消费者（SQS / Kafka → FC）、BFF 层聚合。这些场景天然符合“一次调用、快速响应、无状态”的约束。
- 微服务拆分粒度太细 → 每个函数都带完整依赖和初始化逻辑 → 冷启动变慢、部署包膨胀
- 用了
http.Server自启监听 → Serverless 平台会直接忽略或报错（如 AWS Lambda 不允许ListenAndServe） - 依赖全局变量缓存数据库连接 → 多次调用间可能复用，但平台回收实例时连接泄漏，下次冷启动又重建
Go 函数在 Serverless 上怎么写入口？
不能用 main() + http.ListenAndServe。必须按平台约定实现 handler 函数，由平台注入 context 和请求结构体。
AWS Lambda 要求 func (ctx context.Context, event interface{}) (interface{}, error)；Google Cloud Functions 是 func (w http.ResponseWriter, r *http.Request)；腾讯云 SCF 用 cloudfunction.Start(handler) 绑定。
立即学习“go语言免费学习笔记（深入）”；
- 别在 handler 里做耗时初始化（如加载配置文件、建 DB 连接）→ 放到函数外层（global scope 或
init()），但要加sync.Once控制只执行一次 - HTTP 类函数优先用
http.Request接口，避免自己解析 body → 兼容 API Gateway 的 proxy 集成格式 - 非 HTTP 触发（如 SQS）要用对应 SDK 解析 event 结构，比如
lambda.SQSEvent，不是通用 JSON
冷启动优化到底动哪些地方？
Go 本身冷启动快（50–150ms），但实际项目常卡在 300ms+，问题不在语言，而在代码写法和配置。
-
go build -ldflags="-s -w"必加 → 去掉符号表和调试信息，二进制小 30% 以上 - 避免在
init()里调os.ReadFile或net/http.Get→ 这些 IO 会阻塞容器初始化 - DB 连接不要用
sql.Open后立即db.Ping()→ 改为首次查询时懒连接，或用db.SetMaxOpenConns(1)防爆 - 内存配高一点（如 512MB）→ AWS Lambda 按内存比例分配 CPU，初始化阶段明显更快
实测：一个含 Zap 日志、Viper 配置、PostgreSQL 连接的函数，从默认 128MB/冷启 420ms，调到 512MB + -ldflags="-s -w" + 懒加载后，压到 110ms 内。
日志和错误怎么在 Serverless 里不丢？
Serverless 平台会截断 stdout/stderr 输出，且不保证顺序。直接用 fmt.Println 或标准 log 包，容易漏日志、没 trace ID、查不到上下文。
- 必须用结构化日志库（如
zap），且禁用 file output → 只输出到os.Stdout - handler 入口统一加 request ID（从 event 或 header 提取），用
zap.With(zap.String("req_id", id))注入 logger - 错误不要只
return err→ 要包装成平台可识别格式（如 AWS 要 JSON 序列化 error 字段，GC Functions 要http.Error） - panic 必须 recover → Serverless 函数 panic 会导致整个 invocation 失败，且日志可能被截断
最易忽略的一点：本地开发时用 zap.NewDevelopment()，上线必须切到 zap.NewProduction()，否则 JSON 日志字段名不一致，CloudWatch Logs Insights 查不到关键字段。
