serverless编排不能用net/http启动多handler，因平台无长期进程，阻塞式服务会导致冷启动失败、超时或被杀；编排是事件驱动状态机，需按平台约定签名拆分为无状态函数，避免goroutine长耗时任务。
Go Serverless 编排为什么不能直接用 net/http 启动多个 handler
因为 Serverless 平台（如 AWS Lambda、腾讯云 SCF、阿里云 FC）不给你长期运行的进程，http.ListenAndServe 这种阻塞式服务模型会卡死冷启动、超时失败，甚至被平台强制杀掉。编排引擎本质是“事件驱动的状态机”，不是 Web 服务。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有函数入口必须是平台约定的 handler 签名，比如 AWS Lambda 要
func(context.Context, Events.APIgatewayV2HTTPRequest) (events.APIGatewayV2HTTPResponse, Error) - 编排逻辑要拆成离散的、无状态的 Go 函数，每个函数只做一件事（如
validateOrder、reserveInventory），通过事件总线或平台原生 Step Functions 触发 - 避免在 handler 内部启 goroutine 做长耗时任务——平台可能在响应返回后立即冻结/销毁实例，goroutine 会被静默丢弃
如何用 go-cloud 实现跨云函数状态传递
go-cloud 的 blob 和 pubsub 驱动能屏蔽底层差异，但直接用它存编排上下文容易踩坑：Blob 不保证强一致性，Pub/Sub 消息可能重复投递。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 状态存储优先选带事务语义的方案，比如用
cloud.google.com/go/firestore或github.com/aws/aws-sdk-go-v2/service/dynamodb存execution_id+step_name+payload，避免用 S3/GCS 存中间状态 - 如果非要用
go-cloud/blob，务必给每个 execution 加唯一前缀（如"exec_abc123_step2"），并用blob.Attributes.ModTime做乐观锁判断是否被覆盖 - Pub/Sub 只用于触发下一步，不要依赖它的 delivery guarantee 做状态跃迁——加幂等 key（如
execution_id:step_name）写入 DB 才算真正“执行完成”
context.Context 在跨函数调用中为什么经常失效
Serverless 函数每次调用都是全新 context，父函数传进来的 context.Context 到子函数里只剩 context.background()，超时、取消信号全断了。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要试图序列化/反序列化
context.Context——它不可导出，也没意义 - 把超时时间转成显式字段：父函数计算
deadline := time.Now().Add(30 * time.Second)，写进事件 payload 的deadline_unix字段，子函数自己重建context.WithDeadline(context.Background(), time.Unix(...)) - 取消信号靠外部协调：比如用 redis SETNX 写
"exec_abc123_cancel"，各函数定期检查该 key 是否存在，而不是监听父 context.Done()
本地调试编排链路时，os.Getenv("AWS_LAMBDA_FUNCTION_NAME") 总是空怎么办
本地没环境变量，硬读会 panic 或走错分支；但加一堆 if-else 又让测试逻辑和生产逻辑不一致。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
flag.String或os.LookupEnv包一层，默认 fallback 到"local_dev"，所有函数名判断逻辑都走这个统一出口 - 写个
testutil.NewTestContext()工具函数，返回带 mock deadline 和 cancel 的 context，别在测试里直接 new context - 用
github.com/aws/aws-lambda-go/events的 Struct 做单元测试输入，别用真实 API Gateway event——它字段多、嵌套深，mock 成本高且易过时
编排真正的复杂点不在调度逻辑，而在状态一致性边界：函数成功返回 ≠ 步骤真正完成，网络抖动、平台重试、冷启动延迟都会让“执行完成”和“状态落库”之间出现时间差。这点很容易被日志误导。