云函数这个能力，我最早接触是在做一个小型活动页后端的时候。当时的需求很简单：几十个用户提交表单，需要写库、发通知、做一点简单的数据校验。按老办法得租一台服务器、配环境、挂进程守护、搞日志轮转，一套下来半天没了，结果活动只跑三天。后来换成云函数，从写代码到上线不到二十分钟，跑完活动直接把触发器一删，干干净净。从那以后，凡是遇到"低频但必须有"、"突发流量扛不住"、"不想养服务器"的场景，我第一反应就是云函数。
这篇内容想聊的，就是云函数使用指南这件事本身——它是什么、能干什么、适合谁、怎么用才不踩坑。云函数说白了就是"把一段代码扔上去，平台帮你跑，按实际执行次数和时长计费"的运行时环境。你不需要关心机器在哪、系统怎么打补丁、进程怎么保活，只负责写好那个入口函数。它特别适合几类人：前端想独立做全栈的、小团队想省运维成本的、做自动化脚本和定时任务的、以及需要给第三方系统做轻量集成的开发者。哪怕你完全没碰过后端，只要会写一个接收参数、返回结果的函数，就能上手。
但"能用"和"用得好"之间隔着不少细节。冷启动怎么缓解、超时怎么设、并发怎么控、日志去哪看、费用怎么算、什么场景根本不该用云函数——这些才是真正决定项目稳不稳的地方。下面我按自己实际落地的顺序，把整套东西拆开讲，尽量让你看完就能照着做。
1. 云函数到底解决什么问题：先想清楚再动手
1.1 从"养服务器"到"只写函数"的思维转变
传统后端的心智模型是"一台机器一直在那跑着，我的代码常驻内存"。云函数的心智模型完全不同：代码平时不存在于任何一台正在运行的机器上，只有事件到来时才被唤醒执行，执行完就回收。这个差别听起来抽象，但它直接决定了你后面所有的设计选择。
打个生活化的比方。传统服务器像你雇了一个全职前台，人一直坐在那，来不来客人工资照发；云函数像你叫了一个随叫随到的兼职，有客人打电话他才来，干完活就走，你按他实际工作的时间付钱。全职前台的好处是客人一来就能接待（没有冷启动），坏处是没客人时你也在花钱；兼职的好处是闲时几乎零成本，坏处是第一次叫他的时候他得从家里赶过来（冷启动延迟）。
理解了这个模型，很多"为什么"就通了。为什么云函数不适合跑长连接？因为执行完就回收，连接留不住。为什么不能把大文件缓存在本地？因为下次执行可能换了台机器，本地盘是空的。为什么要有"预留实例"这种产品？就是为了花钱买一个"兼职变全职"的效果，消除冷启动。这些设计不是平台故意为难你，而是模型本身的必然结果。
我见过不少团队第一次用云函数，直接把原来写在常驻服务里的代码整段搬过来，结果各种诡异问题：全局变量不生效、定时任务重复执行、连接池被打爆。根子都在于没转换这个心智模型。所以动手之前，先问自己一句：我这个逻辑，是"事件驱动、短时执行、无状态"的吗？如果是，云函数很合适；如果不是，往下看第 1.3 节，有些场景真不该硬上。
1.2 三类最典型的适用场景与判断标准
我把实际项目中用得最顺的场景归成三类，你可以对照自己的需求看看落在哪一类。
第一类是事件触发的轻量处理。比如对象存储里上传了一张图片，触发函数去做压缩和生成缩略图；数据库插入了一条记录，触发函数去同步到另一个系统；消息队列来了一条消息，触发函数去消费。这类场景的特点是"有事才干活"，闲时完全没成本，而且天然适合并行——来一百个事件，平台自动拉起多个实例并行处理，你不用自己写线程池。
第二类是定时任务。每天凌晨跑一次数据汇总、每小时清理一次过期缓存、每周生成一份报表。传统做法是搞个 cron 机器，机器挂了任务就断了，还得自己监控。云函数配定时触发器，平台保证触发，你只管写逻辑。这类任务通常执行时间不长、频率不高，用云函数性价比极高。
第三类是对外的轻量 API。给小程序、给内部工具、给第三方回调提供一个 HTTP 接口。请求量不大、逻辑不复杂、偶尔有突发。这种场景用云函数可以做到"零服务器"，前端同学自己就能把后端接口写完上线。
判断标准我总结成一张表，实际选型时对着看：
| 判断维度 | 适合云函数 | 不适合云函数 |
|---|---|---|
| 执行时长 | 秒级到分钟级 | 持续数十分钟以上 |
| 调用频率 | 低频、突发、不均匀 | 持续高并发稳定流量 |
| 状态依赖 | 无状态、每次独立 | 需要常驻内存或长连接 |
| 流量特征 | 波峰波谷明显 | 平稳且量大 |
| 团队规模 | 小团队、无专职运维 | 有成熟运维体系 |
这张表不是绝对的，但它能帮你快速排除掉明显不合适的场景。比如一个持续每秒几千请求的核心交易接口，用云函数大概率又贵又难调，老老实实上容器或虚拟机更稳。反过来，一个一天只跑几次的报表任务，用云函数几乎是最优解。
1.3 什么情况下不该用云函数：三个真实的反面案例
说适用场景容易，说"不该用"才是经验。我踩过三个典型的坑，值得单独拎出来。
第一个坑：把云函数当常驻服务用。有个项目需要在内存里维护一个不断更新的排行榜，我图省事写成了云函数的全局变量，想着"反正每次执行都能读到"。结果发现排行榜时有时无——因为不同请求可能落在不同实例上，每个实例的全局变量是独立的，而且实例随时会被回收。这种需要跨请求共享状态的逻辑，本质上是常驻服务的活，硬塞给云函数只会自找麻烦。正确做法是把状态放到外部存储（数据库、缓存服务），云函数只做无状态的计算。
第二个坑：长耗时任务。有个批量处理任务，一次要跑十几分钟。云函数有执行超时上限（不同平台从几十秒到十几分钟不等），超时直接被掐断，而且中途失败很难断点续跑。这种任务更适合放到容器任务或者批处理服务里，云函数只负责"触发"它，不负责"执行完"它。
第三个坑：对冷启动极度敏感的交互。有个实时性要求很高的接口，用户点击后要求百毫秒内返回。云函数冷启动时首次调用可能要几百毫秒甚至更久，虽然可以靠预留实例缓解，但成本上去了。这种场景要么用预留实例兜底，要么干脆用常驻服务。
提示：判断一个逻辑该不该上云函数，最快的办法是问自己——"这段代码执行完就可以彻底忘掉它吗？"能忘掉，就适合；忘不掉（要保留状态、要保持连接、要长期驻留），就别硬上。
2. 上手前的关键准备：账号、运行时与触发器
2.1 运行时怎么选：语言、版本与依赖管理
选运行时这件事，很多人随手一点就过了，但它影响后面依赖怎么装、调试顺不顺、冷启动快不快。我的经验是：优先选团队最熟的语言，其次看冷启动表现，最后才看生态。
主流平台一般支持 Node.js、Python、Java、Go 等几种运行时。冷启动速度上，脚本类语言（Node.js、Python）通常启动更快，因为不用编译、运行时体积小；编译型语言（Java、Go）启动相对慢一些，但执行效率高。如果你的函数逻辑很轻、调用又比较零散，选脚本类语言体验更好；如果是计算密集、单次执行较重的任务，编译型语言更划算。
版本选择上有个容易被忽略的点：尽量选平台标注为长期支持的版本。老版本运行时可能某天就被平台下线，到时候你被迫升级，依赖一升级又是一堆兼容问题。我吃过一次亏，一个跑了一年多的定时任务，因为运行时版本被弃用，某天突然报错，排查半天才发现是环境变了。
依赖管理是另一个高频坑点。云函数的运行环境是"干净"的，你本地装的那些包它不一定有。正确做法是把依赖和代码一起打包上传，或者用平台提供的依赖安装机制。以 Node.js 为例，通常是把node_modules一起打包，或者用package.json让平台在构建时安装。这里有个细节：打包时只装生产依赖，别把测试框架、构建工具这些开发依赖也塞进去，否则包体积暴涨，冷启动变慢。
# Node.js 项目打包前的依赖精简示例 npm install --production # 或者用 npm ci 保证依赖版本与 lock 文件一致 npm ci --omit=devPython 项目类似，用requirements.txt声明依赖，注意锁定版本号，别写requests这种不带版本的，否则某天上游发新版可能就把你搞挂了。
2.2 触发器类型全解析：HTTP、定时、事件与消息
云函数本身只是"一段等着被调用的代码"，真正让它跑起来的是触发器。触发器就是"什么情况下叫醒这个函数"的规则。常见的有四类，用途差别很大。
HTTP 触发器：给函数一个 URL，外部通过 HTTP 请求调用。适合做 API、做 webhook 接收、做第三方回调。配置时要注意请求方法、路径、鉴权方式。很多平台默认不开公网访问，需要显式开启，这点新手容易漏。
定时触发器：用类似 cron 的表达式描述"什么时候跑"。比如每天凌晨两点、每小时整点。cron 表达式是五个或六个字段，分别代表分、时、日、月、周（有的还带秒）。这里最常见的错误是把"每天"和"每周"的字段搞混，建议写完用在线工具核对一遍再上线。
事件触发器：绑定到某个云资源上，资源发生变化时触发。比如对象存储有新文件、数据库有新记录、某个资源被删除。这类触发器是"被动"的，你不需要关心谁调的，只管处理事件内容。
消息触发器：绑定到消息队列，队列里有消息就触发消费。适合做削峰填谷、异步解耦。配置时要特别注意消费失败的重试策略和死信队列，否则一条处理不了的消息可能被反复重试，把函数调用次数和费用都拉上去。
| 触发器类型 | 典型用途 | 配置要点 | 常见坑 |
|---|---|---|---|
| HTTP | API、webhook | 方法、路径、鉴权 | 忘记开公网访问 |
| 定时 | 报表、清理 | cron 表达式 | 时区、字段含义搞错 |
| 事件 | 文件处理、数据同步 | 事件源、过滤规则 | 事件格式没对齐 |
| 消息 | 异步消费、削峰 | 重试、死信队列 | 失败无限重试 |
2.3 权限与网络配置：最小权限原则落地
权限这块，新手最容易图省事给函数一个"管理员权限"，觉得这样什么都能干、不会报错。这是大忌。云函数一旦有了过大的权限，万一代码有漏洞或者被恶意调用，影响面会非常大。正确做法是最小权限原则：这个函数只需要读某个存储桶，就只给它读那个桶的权限，别的一概不给。
具体落地时，先梳理函数要访问哪些资源：要读数据库？要写对象存储？要发消息？把每个资源对应的最小权限动作列出来，然后建一个只包含这些动作的权限策略，绑定给函数的执行角色。这个过程一开始麻烦，但后面排查问题和做安全审计时会感谢自己。
网络配置是另一个容易忽略的点。如果函数要访问内网资源（比如内网数据库），需要把它放到对应的网络环境里，配置好子网和安全组。如果函数只访问公网资源，通常用默认配置即可。这里有个细节：放内网之后，函数访问公网可能需要额外的出口配置，否则会出现"内网能通、公网不通"的怪现象。我第一次遇到时排查了很久，后来才明白是网络出口的问题。
注意：权限和网络配置改完之后，一定要用一个最小化的测试请求验证一遍，别等上线后才发现某个权限没给够。测试时故意访问一个没授权的资源，确认它确实被拒绝，这样才能验证最小权限真的生效了。
3. 函数代码怎么写：从入口到返回的完整实操
3.1 入口函数的结构与参数约定
不管哪种语言，云函数的代码都有一个固定的"入口"——平台调用你的时候，从这个入口进来，把事件数据传给你，等你返回结果。理解入口的签名，是写对函数的第一步。
以常见的 Node.js 运行时为例，入口通常长这样：
// 入口函数：event 是触发事件的数据，context 是运行时上下文 exports.main = async (event, context) => { // event 里装着触发源传过来的数据 // context 里有一些运行时信息，比如请求 ID、剩余执行时间 const name = event.name || 'world'; return { code: 0, message: 'ok', data: `hello, ${name}` }; };这里有两个参数要分清。event是业务数据，HTTP 触发器时它包含请求方法、路径、请求头、请求体；定时触发器时它包含触发时间等信息；消息触发器时它就是消息内容。context是运行时信息，比如这次调用的唯一 ID（排查问题时非常有用）、函数还剩多少执行时间、函数配置等。
Python 运行时的入口类似：
def main(event, context): name = event.get('name', 'world') return { 'code': 0, 'message': 'ok', 'data': f'hello, {name}' }关键约定是：返回值会被平台序列化后返回给调用方。HTTP 触发器时，返回值通常要符合一定的结构（比如包含状态码、头、体），具体格式看平台文档。很多新手写完函数发现返回的东西不对，往往是没按平台的返回格式来。
还有一个容易忽略的点：入口函数的名称和文件路径要在配置里对上。平台需要知道"从哪个文件的哪个函数进去"，这个配置叫"处理程序"或"入口"。写错了就是"函数找不到入口"的报错，第一次遇到会懵，其实就是配置和代码没对齐。
3.2 环境变量与配置分离：别把密钥写进代码
把数据库密码、第三方 API 密钥直接写死在代码里，是新手最常见的坏习惯。一旦代码泄露（比如传到公开仓库），密钥就裸奔了。正确做法是用环境变量：把敏感配置放到函数的环境变量里，代码里通过读取环境变量来获取。
// 从环境变量读取配置，而不是写死在代码里 const dbHost = process.env.DB_HOST; const apiKey = process.env.THIRD_PARTY_KEY; exports.main = async (event) => { // 使用配置 return { host: dbHost }; };环境变量的好处不只是安全，还有配置与代码分离。同一份代码，测试环境和生产环境用不同的环境变量，就能跑出不同行为，不用改代码。这在多环境部署时特别有用。
配置环境变量时有几个实操要点。第一，区分敏感和非敏感。密码、密钥这类敏感信息，很多平台提供"加密环境变量"或"密钥管理"功能，优先用这些，别用明文。第二，给环境变量起清晰的名字，比如DB_HOST、DB_PORT，别用A、B这种，过俩月自己都不认识。第三，本地开发时用.env文件模拟，但记得把.env加进.gitignore，别提交上去。
提示：环境变量改完之后，通常需要重新部署或重启函数才生效。改完记得验证一下，别以为保存了就完事了。
3.3 日志、监控与本地调试的实用套路
云函数最让人不适应的一点是"看不见"。代码跑在平台的机器上，出问题了不能像本地那样打断点。所以日志和监控是云函数开发的命根子。
日志方面，最基础的是往标准输出打印。不同语言写法不同，Node.js 用console.log，Python 用print或 logging 模块。这些输出会被平台收集，在控制台里能按请求 ID 查。这里的关键技巧是：每条关键日志都带上请求 ID 或业务标识，这样出问题时能快速把一次调用的所有日志串起来。我习惯在入口处先打一条"开始处理，参数是 xxx"，结束时打一条"处理完成，结果是 xxx"，中间关键分支再打点，排查时一目了然。
exports.main = async (event, context) => { const requestId = context.requestId; console.log(`[${requestId}] 开始处理`, JSON.stringify(event)); try { // 业务逻辑 const result = { code: 0 }; console.log(`[${requestId}] 处理完成`, JSON.stringify(result)); return result; } catch (err) { console.error(`[${requestId}] 处理失败`, err.message); throw err; } };监控方面，平台一般会提供调用次数、错误率、执行时长、并发数等指标。这些指标要定期看，尤其是错误率和执行时长的趋势。错误率突然上升，往往是上游依赖出了问题；执行时长逐渐变长，可能是数据量涨了或者某个依赖变慢了。提前发现趋势，比等用户投诉再排查强得多。
本地调试这块，很多平台提供了本地运行工具，可以在本机模拟触发事件、跑函数逻辑。我的建议是：核心业务逻辑抽成独立的纯函数，和云函数的入口解耦。这样本地测试时直接测纯函数，不用依赖平台工具，测试写起来也简单。入口函数只负责"解析事件、调用纯函数、组装返回"，薄薄一层，不容易出错。
4. 性能与成本：冷启动、并发与计费的真实账
4.1 冷启动的成因与四种缓解手段
冷启动是云函数绕不开的话题。它的本质是：函数实例不是常驻的，第一次调用（或实例被回收后再次调用）时，平台需要重新拉起运行环境、加载代码、初始化依赖，这段准备时间就是冷启动。表现出来就是"第一次慢，后面快"。
冷启动的耗时跟几个因素有关：运行时类型（脚本类快、编译类慢）、代码包大小（越大越慢）、初始化逻辑（连数据库、加载大文件越慢越久）、以及平台本身的调度。我实测过一个 Node.js 函数，代码包几十 KB、初始化很轻，冷启动大概几百毫秒；换成包体积几 MB、初始化要连数据库的，冷启动能到一两秒。
缓解手段主要有四种，按成本从低到高排：
第一，减小代码包体积。只打包必要文件，剔除开发依赖、测试文件、大体积静态资源。这是零成本的优化，效果却很明显。
第二，精简初始化逻辑。把耗时的初始化（比如建立连接、加载配置）尽量延后到真正需要时再做，或者做成懒加载。全局作用域里别放重活。
第三，合理设置预留实例。预留实例就是"提前拉好几个实例等着"，调用来了直接用，没有冷启动。代价是要为这些预留的实例付费（即使没调用）。适合对延迟敏感、流量可预测的场景。设置数量要结合流量曲线，设多了浪费钱，设少了还是会有冷启动。
第四，用定时触发器"保活"。有些团队用定时任务每隔几分钟调一次函数，让实例别被回收。这招能用但不优雅，因为平台回收实例的策略不完全可控，而且保活本身也产生调用费用。我一般只在临时应急时用，不作为长期方案。
| 缓解手段 | 成本 | 效果 | 适用场景 |
|---|---|---|---|
| 减小包体积 | 零 | 中等 | 所有函数都该做 |
| 精简初始化 | 零 | 中等 | 初始化重的函数 |
| 预留实例 | 较高 | 显著 | 延迟敏感、流量可预测 |
| 定时保活 | 低 | 不稳定 | 临时应急 |
4.2 并发模型：单实例并发与账号级并发限制
并发这块有两个层面的概念，搞混了会出问题。
第一个层面是"单实例能同时处理几个请求"。有的平台默认一个实例一次只处理一个请求（处理完才接下一个），有的支持一个实例并发处理多个请求。前者隔离性好、逻辑简单，后者资源利用率高、冷启动影响小。如果你的函数是无状态的、逻辑不重，开启单实例多并发通常能提升吞吐、降低成本。但要注意：开了多并发之后，全局变量会在多个请求间共享，如果代码里依赖全局变量做请求隔离，就会出问题。
第二个层面是"账号级别的并发上限"。平台通常给每个账号一个总的并发配额，所有函数共享。当流量突增、并发打满时，新的请求会被限流或排队。这个上限要提前了解，做容量规划时留足余量。我遇到过一次活动流量突增，函数并发打满，部分请求直接失败，后来申请提额并加了限流兜底才稳住。
实操建议：给关键函数单独评估并发需求，非关键函数设置并发上限做保护。比如一个函数下游依赖的数据库连接数有限，就给这个函数设一个并发上限，避免把数据库连接打爆。这个上限不是拍脑袋定的，要结合下游资源的承载能力算：数据库最大连接数除以单实例占用连接数，就是理论上限，再打个折留余量。
4.3 计费构成与省钱的实际策略
云函数的计费一般由几部分组成：调用次数、执行时长（按配置的内存规格折算）、以及可能的预留实例费用和公网流量费用。理解计费构成，才能有针对性地省钱。
调用次数通常很便宜，真正的大头往往是执行时长乘以内存规格。这里有个反直觉的点：内存配得越大，单价越高，但执行可能更快（因为 CPU 也按比例给得多），总费用不一定更高。我做过对比，一个计算密集的函数，内存从 128MB 提到 512MB，单次执行时长从 800ms 降到 250ms，算下来总费用反而略降。所以内存规格不是越小越省，要实测找平衡点。
省钱的几个实际策略：
- 按需调低内存：对轻量函数，把内存调到刚好够用的档位，别默认给大规格。
- 缩短执行时长：优化代码、减少不必要的网络请求、把能并行的事并行做。
- 避免无效调用：定时任务别设得过密，消息消费失败要有死信队列兜底，别让一条坏消息反复重试烧钱。
- 合理使用预留实例：只在真正需要低延迟的地方用，别全量开。
- 关注公网流量：如果函数往外传大量数据，流量费可能超过计算费，能走内网就走内网。
注意：上线前一定要用真实流量模型估算一遍费用，别只看单价。我见过一个团队因为定时任务设成了每分钟一次、每次跑几秒，一个月下来费用远超预期，后来改成每十分钟一次、批量处理，费用降了一个数量级。
5. 上线之后：排障、安全与持续维护
5.1 高频报错速查：从超时到内存溢出
函数上线后，报错是常态。我把实际遇到的高频问题整理成一张速查表，出问题时先对着表定位，能省不少时间。
| 报错现象 | 可能原因 | 排查方向 | 解决思路 |
|---|---|---|---|
| 执行超时 | 逻辑太慢、依赖卡住 | 看日志定位卡在哪一步 | 优化逻辑、调高超时、拆分任务 |
| 内存溢出 | 一次加载数据太多 | 看处理的数据量 | 分批处理、调高内存 |
| 权限拒绝 | 角色权限不足 | 看报错里的资源名 | 补最小必要权限 |
| 连接失败 | 网络不通、地址错 | 测内网/公网连通性 | 检查网络配置和出口 |
| 冷启动慢 | 包大、初始化重 | 看首次调用耗时 | 减包、懒加载、预留实例 |
| 重复执行 | 消息重试、定时重叠 | 看调用记录 | 加幂等、调重试策略 |
超时是最常见的。排查时先看日志，确认卡在哪个环节——是连数据库慢，还是某个外部接口没响应。定位到环节后，要么优化，要么把超时时间调大（但别无限调大，超时太长会占着并发资源）。内存溢出通常是"一次性把大文件或大结果集读进内存"，改成流式处理或分批处理就能解决。
5.2 幂等设计：让重复执行不出乱子
云函数环境里，"同一个事件被处理多次"是常态而非例外。消息队列重试、定时任务重叠、网络抖动导致的重发，都可能让同一个逻辑跑两遍。如果你的逻辑不幂等（跑两遍结果就错），迟早出事。
幂等的核心思路是：给每次处理一个唯一标识，处理前先检查这个标识是否已经处理过，处理完记录下来。比如消息触发器，消息本身通常带一个唯一 ID，处理前先查一下这个 ID 有没有处理记录，有就直接返回，没有就处理并记录。
// 幂等处理的简化示例 async function handleOnce(messageId, logic) { const key = `processed:${messageId}`; const done = await cache.get(key); if (done) { console.log(`消息 ${messageId} 已处理，跳过`); return; } await logic(); await cache.set(key, '1', { ttl: 86400 }); // 记录保留一天 }这里有个细节：记录和业务操作最好在同一个事务里，或者用"先占位再处理"的方式，避免"处理成功但记录失败"导致下次重复处理。另外，幂等记录的过期时间要合理，太短起不到防重作用，太长占存储。一般按业务的最长重试窗口来设。
5.3 版本管理与灰度：别让一次发布全量翻车
云函数虽然轻，但发布也该有章法。我的习惯是：每次发布都带版本号，新版本先小流量验证，确认没问题再全量。
具体做法上，很多平台支持"版本"和"别名"的概念。版本是代码的快照，别名是指向某个版本的指针。你可以发布一个新版本，把测试别名指向它，用测试流量验证；验证通过后，把生产别名切过去。这样出问题时可以快速把别名切回旧版本，回滚成本极低。
灰度方面，如果平台支持按流量比例分流，可以先切 5% 流量到新版本，观察错误率和耗时，没问题再逐步放大。如果不支持流量分流，至少做到"先在测试环境跑通、再用小号触发验证、最后全量"。我吃过一次亏，改了一个看似无害的配置直接全量发布，结果触发了一个边界条件，线上报错一片，回滚花了好几分钟。从那以后，再小的改动也走一遍灰度。
提示：发布前把"回滚步骤"写下来，包括切回哪个版本、需要改哪些配置。真出问题时人是慌的，有张纸照着做能少犯错。
6. 我踩过的坑与几条实在建议
6.1 五个真实踩坑记录
坑一：全局变量当缓存用。前面提过，不同实例的全局变量不共享，而且实例随时回收。我早期用它缓存配置，结果时好时坏。后来改成每次从环境变量或配置中心读，虽然多了一点开销，但行为稳定。
坑二：定时任务没考虑时区。cron 表达式默认时区可能和你想的不一样，我设的"凌晨两点"实际跑在了别的时间。上线前一定确认时区，最好在日志里打出实际执行时间核对。
坑三：消息消费没设死信队列。一条格式错误的消息被反复重试，调用次数飙升。后来加了死信队列，处理失败几次后转入死信，人工排查，费用和噪音都降下来了。
坑四：依赖没锁版本。某次重新部署，上游依赖发了新版，行为变了，函数挂了。从那以后所有依赖都锁死版本，升级走显式流程。
坑五：日志打太多。为了排查方便，我在循环里打了大量日志，结果日志费用上去了，而且关键信息被淹没。后来改成只打关键节点，并且带上请求 ID，排查效率反而更高。
6.2 给不同阶段使用者的建议
如果你是刚接触云函数，建议从一个最小的定时任务或 HTTP 接口开始，把"写代码、配触发器、看日志、改配置"这一整条链路走通，别一上来就搞复杂架构。走通一遍，你对这个模型的理解会扎实很多。
如果你是要把业务迁上来，先做场景筛选，把明显不适合的（长任务、强状态、稳定高并发）排除掉，剩下的再逐个评估。迁移时优先迁"独立、无状态、低频"的模块，风险小、见效快。
如果你是已经在用、想优化，重点看三件事：费用构成里哪块占比最高、错误率趋势有没有异常、冷启动对体验影响大不大。这三件事优化好，整体质量能上一个台阶。
云函数这个工具，用对了是真省心，用错了是真添堵。核心就一句话：顺着它的模型用，别跟它较劲。它是事件驱动、短时执行、无状态的，你就按这个来设计；它不擅长的，就老老实实换别的方案。我现在的习惯是，新需求先问一句"这个能不能用云函数快速验证"，能就用它快速跑通，跑通了再看要不要换成更重的方案。这种"先用轻的验证、再按需加重"的思路，帮我省下了不少前期投入，也避免了很多过度设计。
