floci 是一套跑在本机的云模拟器：AWS、Azure、GCP、OCI 四个云各对应一个独立程序，各占一个端口，各自是一份 MIT 许可的原生二进制，四个之间互不依赖，可以只开一个，也可以并排开满。它不要云账号，不要 auth token，没有功能门控，也不埋遥测；只要能跑 Docker，Windows、macOS、Linux 用的是同一套东西。刚发的 2.4.0 里塞了五百多条变更，几乎全部落在服务覆盖的深度上。

四朵云，四个程序，四个端口

四个模拟器的分派很直白：主程序对应 AWS，监听 4566；Azure 版监听 4577；GCP 版监听 4588；OCI 版监听 4599。每个都是一只容器、一个端口、一套协议，数据彼此不串。对同时要碰多云的人来说，这比功能清单更实用——同一个测试脚本把 endpoint 换掉就能在另一朵云上重跑，不必为每个云各维护一台虚拟机、各准备一份账号。

名字来自卷积云里一类形状像爆米花的云团，英文写作 cirrocumulus floccus。这个起名和定位是吻合的：它没打算把云搬进本地，只是把云的接口在本地摆一份，让代码先在小尺度上跑通。

原生二进制省下的那几秒

模拟器用 Quarkus Native 编译，底层是 GraalVM 的 Mandrel 发行版，产物是原生机器码而不是跑在 JVM 里的包。官方标称的数字是 24 毫秒冷启动、空闲时占 13 MiB 内存，镜像约 90 MB。对写代码的人，这组数字只意味着"快"；对流水线的意义不同：每个任务起一套环境、跑完就拆，只有启动开销足够小，才敢在二十个并行任务里这么做。

这类工具的常见做法是在容器里跑一个完整的服务进程，冷启动几秒到几十秒，常驻几百 MB 内存，进了并行矩阵就开始抢内存、等超时。原生编译把这两项一起压了下去，代价是构建时间长、部分依赖要补反射配置，这是所有提前编译方案共有的取舍。

真引擎撑起来的协议保真

模拟器最容易翻车的地方是"看起来对"：数据结构一样、状态码一样，行为不一样，本地测试全绿，上线头一小时就炸。floci 的对策是不打桩，把复杂的数据服务交给真实引擎。Lambda 的每次调用都跑在真实的 Docker 容器里，Node.js、Python、Java、Go 的运行时环境变量与线上对齐。RDS 起的是真的 PostgreSQL、MySQL 或 MariaDB，有完整生命周期与快照恢复，走 JDBC 流量与 IAM 数据库认证；ElastiCache 是真 Redis 容器，floci 自己在前面做 SigV4 代理；MSK 背后是 Redpanda，Athena 的查询落在 DuckDB 边车容器里；EC2 的 RunInstances 直接拉起容器，带 SSH 密钥注入、UserData 执行和两代 IMDS 元数据服务。

协议层面有两处细节值得单独说。IAM 不是摆设：Lambda、RDS、ECS、EC2、MSK、ECR、OpenSearch 都做完整的 SigV4 校验，策略写错在本机就会报错，而不是到了线上才暴露。项目自己维护的 AWS SDK 兼容性测试共 1925 条，公布的口径是全部通过。这是官方自报的数，不是第三方复核，但用来判断能不能替掉手上那套环境已经够参考。

一个控制台，四套运行时

命令行之外还有个图形界面，结构比看上去讲究。浏览器里的 Floci UI 用 React 和 Vite 构建，监听 4500，只认 /api 开头的请求；背后是 Bun 和 Hono 写的 Cloud Proxy API，监听 4501，按云把请求分给 AWS、Azure、GCP、OCI 四个适配器；适配器再翻译成各运行时自己的协议，落到 4566 到 4599 那几个端口上。图里那行"UI 不知道云，代理不知道实现，适配器负责翻译，运行时负责执行"，说的就是这条链路的分工。

好处是界面与云解耦：新增一朵云，只要补一个适配器和一份服务描述，控制台不用改。实际用起来，首页给出当前实例的服务可用数与资源数，云切换是右上角一个按钮；存储页能看到桶的名字、类型、所属云和创建时间，新建与删除都在同一行里。Azure 那个实例显示的是 9 of 28 services available，覆盖面按云的成熟度在走，不是四朵云一视同仁。

2.4.0 把力气花在了哪

2.4.0 发于 10 月 31 日。按仓库自动生成的变更记录，这个版本有 210 条新功能、10 条性能改进、294 条缺陷修复，合计 514 条。集中在哪几个服务上一眼能看出来：EC2 占 62 条，CloudFormation 占 59 条，DynamoDB 占 40 条，Lambda Web 占 22 条。CloudFormation 那一批补的是具体资源类型：EC2 前缀列表、WAFv2 的 IP 集、SES 邮件身份与接收规则、Route53 记录组、Redshift 事件订阅，以及 RDS 集群的角色关联。

这些条目单看都很枯燥，合起来说明的是一件事：它想让你把基础设施代码直接跑在本地。Terraform、OpenTofu、CloudFormation 的模板在真云上试错的成本是钱和时间，在本地试错的成本只是一次重启。发布节奏也配合这个用法——稳定版每月 15 日和月末各切一班，班次之间 nightly 标签跟着主干走，修完的第二天就能拿到。

上手之前该知道的几件事

覆盖不均是第一个要接受的现实。AWS 侧是主力，服务上百项；Azure、GCP、OCI 的量级明显小一截，控制台里还有一批标着 coming soon 的条目。项目主要落在哪朵云上，先翻对应那页的服务清单再决定，别默认四个云一样厚。

它还需要 Docker。凡是背后要起真实引擎的服务，都得有容器运行时，机器上没有这一层，那部分能力就是空的。状态也是默认一次性的：停掉再起，拿到的是一朵干净的云。这对跑测试是优点，对想攒一份长期本地数据的人是缺点，用之前先把存储配置看清楚。

也别拿它做压测。它保的是协议行为，不是吞吐指标。官方给的 Lambda 吞吐是每秒 289 次请求，这个数用来验证功能足够，用来衡量容量没有意义。

更根本的一层判断是：本地云的价值不在省下那点云账单，而在于把改一版、跑一遍、看结果的循环压到几十秒以内，同时让编码代理有一个随便折腾也不会出事的地方。四个模拟器、一个控制台、一套原生二进制，都是围绕这个循环做的取舍——所以它做得最细的地方是协议与引擎，最粗的地方是覆盖面。

把云搬到本机是做不到的，把云的接口搬到本机却可以。floci 选的是后一条路：它不承诺替掉真实环境，只承诺让每一次试错都发生在账单之外。