函数计算是少数几个"账单上找不到机器"的计算产品。ECS 你能看到几核几 G、包月还是按量；ECI 至少还有容器实例数。到了 FC，账单上只有一个词：CU。很多人第一次看账单的反应是"我明明没跑多少请求，怎么还有钱"，第二次的反应是"这个 CU 到底等于多少 CPU"。
这篇把两件事讲清楚：CU 是怎么被算出来的，以及什么样的活该交给函数、什么样的活不该。所有价格以官方页面实时展示为准，文中数字是按公开单价做的算例，只用来判断量级。
一、先把三个"跑代码的地方"摆在一张表上
选型的第一步不是比较价格，是比较生命周期归谁管。
| 维度 | ECS | ECI（弹性容器实例） | 函数计算 FC |
|---|---|---|---|
| 你交付的东西 | 整台虚拟机 | 容器镜像 | 代码包 / 镜像 |
| 计费单位 | 实例时长（包月或按秒） | 实例时长（按秒） | CU 使用量（按毫秒折算） |
| 空闲时是否收费 | 收 | 收（实例存在就收） | 最小实例数为 0 时不收 |
| 启动耗时 | 分钟级 | 秒级 | 冷启动通常百毫秒到秒级，弹性效率比虚机、容器快 5~10 倍 |
| 运维面 | 系统、补丁、扩缩容全自理 | 免宿主机，容器配置自理 | 全托管，只管代码和配置 |
| 典型合适场景 | 常驻服务、需要 SSH 调试、有状态中间件 | 突发批处理、需要自定义镜像 | 事件驱动、流量波动大、低频任务 |
| 典型不合适场景 | 流量极不规律、大量闲置 | 长稳负载（不如包月） | 长连接、需要本地状态、7×24 恒定高负载 |
一句话边界：负载越"平"，越该用包月 ECS；负载越"尖"，越该用 FC。 FC 卖的不是算力，是"不用为闲置付费"。
二、CU 是唯一的计费单位
FC 把所有资源消耗折算成一个统一单位 CU，再乘单价。转换系数如下（CPU 实例）：
| 计费项 | 单位 | CU 转换系数 | 说明 |
|---|---|---|---|
| vCPU 使用量 | CU/(vCPU·秒) | 1.0 | 活跃状态才收 |
| 内存使用量 | CU/(GB·秒) | 0.15 | 浅休眠状态仍收 |
| 磁盘使用量 | CU/(GB·秒) | 0.05 | 前 10 GB 免费，默认 512 MB 档不计费 |
| 函数调用次数 | CU/万次 | 75 | 按调用次数摊 |
| 深休眠存储空间 | CU/(GB·秒) | 0.05 | 深休眠态唯一的收费项 |
单价是按月阶梯累计的，而且按地域独立累计，不同地域的用量不会合并进同一档：
| 月度 CU 使用量 | 目录价（元/CU） | 活动折扣价（元/CU） |
|---|---|---|
| (0, 2 亿] | 0.00011 | 0.000088 |
| (2 亿, 10 亿] | 0.00010 | 0.000080 |
| > 10 亿 | 0.00009 | 0.000072 |
几个容易忽略的规则：
- CPU 实例按毫秒计量，GPU 实例按秒计量；
- 单小时费用低于 0.01 元时按 0.01 元收取，所以极低频任务的账单会被这个地板价托住；
- 公网出流量不在这张账单里，它走 CDT 统一计费，函数内发起的公网请求、响应流量、被 CDN 回源的流量都算；
- 新用户有 CU 试用额度（官方免费试用页给的是每月 15 万 CU、有效期 3 个月，具体以当期活动为准），额度内不产生费用。
三、决定账单的第三个变量：实例处于哪种状态
同样一个函数，实例状态不同，收费项完全不同。这是 FC 计费最容易误判的地方。
| 实例状态 | vCPU 费 | 内存费 | 磁盘费 | 触发条件 |
|---|---|---|---|---|
| 活跃 | 收 | 收 | 收（10 GB 内免） | 正在处理请求 |
| 浅休眠（原"闲置"） | 不收 | 收 | 收（10 GB 内免） | 无请求但实例被保留 |
| 深休眠 | 不收 | 不收 | 按深休眠存储收，10 GB 免费额度不适用 | 深休眠功能开启且实例冻结 |
按量模式下，最小实例数为 0 时没有请求就不分配实例、不产生费用；一旦把最小实例数设成 1 以上，实例就常驻，无请求时进入浅休眠继续计费。这就是"我几乎没调用，为什么每天都有账单"的标准答案——不是计费错了，是为了消冷启动主动买了常驻。
深休眠还要注意一个反直觉的点：它的计费量是 内存 × 2 + 磁盘，而且不再享受 10 GB 磁盘免费额度。内存给得越大，深休眠越不划算。
四、算三笔账
以下用目录价 0.00011 元/CU 粗算，实际以官网实时价格和活动为准。
第一笔：每天跑一次的定时任务。 规格 0.5 vCPU / 1 GB，每次执行 30 秒。
每次 CU = 0.5×30 (vCPU) + 1×0.15×30 (内存) + 75/10000 (调用)
= 15 + 4.5 + 0.0075 ≈ 19.5 CU
每月 30 次 ≈ 585 CU ≈ 0.06 元
再叠加"单小时不足 0.01 元按 0.01 元"的地板价，实际账单是几毛钱量级。同样的活放一台包月 ECS 上，光闲置就是几十上百元。这是 FC 最没有争议的战场。
第二笔：一个有波峰的 Web API。 日均 10 万次调用，每次 100 毫秒，规格 0.5 vCPU / 1 GB。
单次 = 0.5×0.1 + 1×0.15×0.1 + 75/10000 ≈ 0.0725 CU
每月 = 0.0725 × 10万 × 30 ≈ 21.75 万 CU ≈ 24 元
注意这里的假设：0.1 秒是真正的处理时间，不含冷启动。如果每次请求都要拉一个 200 MB 的依赖再初始化数据库连接，实际计费时长会翻几倍，账单跟着翻几倍。
第三笔：图片处理。 每张 2 秒，规格 1 vCPU / 2 GB，月处理 10 万张。
单张 = 2 + 2×0.15×2 + 0.0075 ≈ 2.61 CU
每月 = 2.61 × 10万 ≈ 26.1 万 CU ≈ 29 元
算力之外还有两笔：图片存 OSS 的存储与请求费、分发出去的 CDN 流量费。函数费往往不是这类方案里最贵的一项，别只盯着 CU。
把这三笔放在一起看，会得到一个粗略的换算：百元级的包月实例，大约相当于每月 90 万 CU 的按量消耗。月用量稳定超过这个量级，就该认真考虑包月或常驻资源池，而不是继续按量。
五、反转：五个不该用 FC 的场景
选型文章如果只讲优点就是广告。以下五类活，交出去大概率要返工。
- 长连接与常驻进程。 WebSocket 长会话、MQTT broker、需要维持心跳的后台任务，都不适合。实例会被冻结、被回收，连接跟着断。函数里若确实要跑后台异步逻辑，得关掉浅休眠，成本随即变成常驻。
- 依赖本地状态的服务。 临时磁盘上限 10 GB，实例随时可能被替换。会话、上传的临时文件、本地缓存目录都不能当持久层用。
- 7×24 恒定高负载。 峰值和谷值差不多的业务，按量单价一定打不过包月。这种负载用 FC 是把省钱的前提（有闲置）主动放弃掉了。
- 强依赖固定公网 IP 或需要 SSH 进去排查的。 FC 支持配置固定公网 IP，但要求关闭默认网卡的公网访问，配置错了表现为"函数能跑但访问不了外网"。也没有 SSH，排障只能靠日志和本地复现。
- 超长批处理。 单次执行上限是 86400 秒，看似够长，但长任务一旦中途失败重试成本很高。几小时以上的离线计算，用 ECI 或大数据产品更稳。
六、上线前必须确定的七个参数
FC 的坑八成不在代码里，在配置里。这张表建议照着过一遍。
| 参数 | 默认 / 范围 | 踩坑点 |
|---|---|---|
| 规格（vCPU / 内存） | vCPU 0.05~16 核（0.05 步长），内存 128 MB~32 GB（64 MB 步长） | vCPU 与内存比例必须落在 1:1 ~ 1:4，超了建不出来；内存给大不等于跑得快 |
| 执行超时 | 默认 60 秒，最长 86400 秒 | 默认 60 秒是最常见的线上故障源，批量任务务必调大 |
| 单实例并发度 | 1~200 | 调高能省实例费，但多请求共享同一份 CPU/内存，是"抢占式共享" |
| 最小实例数 | 0 | 设 ≥1 即常驻计费，仅为消冷启动才设，且配合浅休眠 |
| 临时磁盘 | 512 MB 默认，最大 10 GB | 前 10 GB 免费，写大文件先确认落盘位置 |
| 日志 | 需显式接入 SLS | 不接日志等于线上黑盒，出问题只能猜 |
| 网络 | 默认网卡可访问公网；可绑定 VPC | 访问 VPC 内 RDS/Redis 必须配 VPC 与交换机，否则连不上内网地址 |
另外两个配额值得提前知道：单账号单地域按量模式实例总数默认 100，实例交付速度约 300 个/分钟。突发流量打进来时，扩容不是无限的。
七、从零到跑起来：四步
用 Serverless Devs 走一遍最小闭环。
# s.yaml
edition: 3.0.0
name: demo-fc
access: default
resources:
web:
component: fc3
props:
region: cn-hangzhou
functionName: demo-web
runtime: python3.10
code: ./code
handler: index.handler
memorySize: 512
cpu: 0.35
timeout: 60
instanceConcurrency: 10
triggers:
- triggerName: httpTrigger
triggerType: http
qualifier: LATEST
triggerConfig:
authType: anonymous
methods: [GET, POST]
# 部署（首次会引导配置 AccessKey）
s deploy -y
# 本地触发一次，先验证业务逻辑
s invoke -e '{"queryStringParameters": {"name": "fc"}}'
# 查看线上日志
s logs --tail
部署完在控制台拿到公网访问地址，再用 curl 验收：
curl -i "https://<your-endpoint>/<path>?name=fc"
# 记下响应头里的 X-Fc-Request-Id，查日志时用它精确定位一次调用
验收清单三件事：响应头有 X-Fc-Request-Id；日志里能看到本次调用的完整耗时；用 s info 确认 instanceConcurrency 和 timeout 是你要的值而不是默认值。
八、避坑清单
- 把默认 60 秒超时当成"够用"，批量任务跑到一半被截断。
- 最小实例数设了 5 却以为"没请求就不收费"，月底账单不对。
- 为了消冷启动把内存拉满，结果冷启动没消掉，浅休眠的内存费翻倍。
- 在函数里初始化数据库连接池、加载大模型，每次调用都重新付一遍初始化时间的钱。
- 用临时磁盘存用户上传的文件，实例回收后文件消失。
- 忘了配 VPC，连不上 RDS 内网地址，误判为"函数不能访问数据库"。
- 函数挂在 OSS 触发器上做全量处理，一次误传几万个对象直接把月度 CU 打穿——上线前先确认触发范围与幂等。
- 只看 CU 单价做对比，漏算公网出流量和下游存储、CDN 的费用。
最后
FC 的价值不在"便宜"，在于把闲置成本转移到平台。判断标准其实只有一条：这段代码是不是"有事才跑、跑完就没事"。是，就交给函数；不是，老老实实包一台机器。
产品页和当前计费规则在这里，价格随活动和地域变化，动手前建议自己核一遍：函数计算 FC 产品页与计费说明。
