函数生命周期：创建、部署、调用、更新、版本控制、别名管理

咱们要深入理解一个Serverless函数的来龙去脉。
说白了，函数从生到死有一套固定的流程。我见过不少新手上来就写代码，部署完就跑，结果线上出问题找不到原因。嗯，这就是没搞懂生命周期的每个环节。

我把这个过程拆成六个核心动作：创建 → 部署 → 调用 → 更新 → 版本控制 → 别名管理。
你想想看，这不就跟软件开发中的代码编写、构建发布、上线运行、迭代升级、版本打标签、环境切换一模一样？搞懂这套，你基本就拿到Serverless的入场券了。

创建：从零开始搭架子

创建函数，不是单纯地写个 handler 就完事。我个人的习惯是先确定三件事：运行时环境、内存配置、超时时间。

比如你要处理图片压缩，那内存给个 512 MB 起步，超时设 30 秒。
要是接口型函数，响应得快，内存 128 MB、超时 3 秒就行。为什么？
超时设得越大，费用越高，而且并发等待也越危险。

创建时还会生成一个默认版本（通常是 $LATEST）。记住，这只是个草稿版，还不能直接线上用。

部署：把代码推上线

部署说白了就是让平台知道：嘿，我有新代码了，你准备好运行吧。
过程包括打包代码、上传到对象存储、平台分配计算资源、预热实例。

有些平台支持直接上传 ZIP 包，也支持从 Git 仓库同步。我推荐用 CI/CD 自动部署，别手动上传，否则容易出事故。

部署完成后，函数就处于可调用状态了。但要注意，此时还在 $LATEST 版本下，线上用户访问不到——除非你显式创建一个版本。

调用：让函数跑起来

调用分两种：同步调用和异步调用。

调用模式	典型场景	注意事项
同步调用	HTTP API、WebSocket 响应	需要等函数返回，超时风险
异步调用	消息队列、定时任务、事件通知	不关心返回值，可设置死信队列

我有个小技巧：调试阶段用同步调用，方便看日志；生产环境下，能用异步就别用同步，节省资源还能自动重试。

更新：改了代码怎么上线

更新操作很频繁，但有个关键点——更新前记得创建版本。

为什么？直接更新 $LATEST 会导致线上服务瞬时中断。比如你改了个函数名，但旧请求还在跑，新代码上来直接报错。

更新时也可以只更新环境变量或配置，不用改代码。比如切换数据库连接字符串，改个环境变量重新部署就行。

这里有个容易忽略的事：更新代码后，下次调用会触发冷启动。因为实例被销毁了，平台要重新初始化。嗯，冷启动确实烦人，但可以通过预留实例解决。

版本控制：给代码打上不可变的标签

版本号一旦创建就不可变更。你想想看，这多像 Git tag 打快照？

版本控制的真正价值是回滚。线上出 bug 了，我可以立即切回 v1、v2，而不是重新部署旧代码。
我以前遇到过发布新功能导致用户全挂的情况，当时靠版本回滚，3 秒解决问题。

版本特性	说明
不可变性	创建后代码、配置、依赖都锁定，不能修改
独立调用地址	每个版本有一个独立 ARN（资源名称），可以直接触发
与 $LATEST 隔离	$LATEST 可以随便改，版本是快照，两者互不影响

我建议每发布一次小功能就创建一个版本，别攒一堆再发。版本多了不占资源，只是个逻辑快照，放心打标签。

别名管理：用名字代替版本号

别名就像是一个指针，指向某个版本。你可以把别名理解为环境名称。

比如 prod 别名指向 v5，staging 别名指向 v3，dev 别名指向 $LATEST。这样你就可以通过别名来组织上线流程。

别名的核心用法是灰度发布。你可以让一个别名同时指向两个版本，并分配流量权重。
比如：prod 别名 90% 流量给 v5，10% 给 v6。观察没问题，慢慢把权重调到 100%。万一新版本有问题，直接把别名切回 v5 就行。

别名还有个用法是路由到最新版本。你可以设置别名总是跟随 $LATEST，这样部署就能自动生效。但我不建议生产环境这么干——不可控。

你想想看，有了版本控制和别名，是不是就跟微服务的蓝绿部署、金丝雀发布一个意思？只是 Serverless 帮你把底层调度全包了，你只需要关心业务。

好了，这六个环节串起来，就是函数从生到死的完整轨迹。我到现在每次做 Serverless 项目，都会把这张生命周期图贴在团队白板上。不是因为它难，而是因为你漏了任何一步，线上都可能出事。记住：先把流程跑通，再去优化性能和成本。