Floci：在本机用 4566 端口模拟 AWS
Floci 在本機上模擬選定的 AWS 服務，因此無需遠端帳戶即可開發和測試雲端應用程式。
秒懂
- 它是什麼？
- 免费開源的本地 AWS 模拟器，支援 CLI、Docker Compose、標準 SDK、Terraform 與 CDK，部分服務使用真實 Docker 容器。 聚焦本專案的實際功能、技術入口、部署條件、資料流、版本變化與授權邊界，並依官方 README 所列能力判斷適用工作情境和不適合的替代用途。
- 適合誰用？
- 適合本地開發、自動化測試和 CI 中需要 AWS 形状接口的團隊；不適合未经兼容性驗證就把模拟結果當成真實 AWS 行為。先執行 `floci start`、`eval $(floci env)` 和一条 S3/DynamoDB 指令，随後驗證存储模式、账戶隔离、Docker 後端服務和目標 IaC 流程，再决定是否替换現有 LocalStack 流程。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Java（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
floci-io-floci-deep-analysis｜CLI 启動後所有請求指向 4566
floci-io-floci-deep-analysis｜CLI 启動後所有請求指向 4566 的專案脈絡：Floci 的快速開始是 `floci start`，然後執行 `eval $(floci env)` 导出本地 AWS 環境變量。AWS CLI 可以照常創建 S3 bucket、創建 DynamoDB 表並列出表。服務入口是 `http://localhost:4566`，README 說任意 region 都可用，凭據只需非空值，除非显式启用更严格的服務級认證檢查。
floci-io-floci-deep-analysis｜CLI 启動後所有請求指向 4566：Docker Compose 路径使用 `floci/floci:latest` 並映射 `4566:4566`，之後手工設置 `AWS_ENDPOINT_URL`、`AWS_DEFAULT_REGION`、`AWS_ACCESS_KEY_ID` 和 `AWS_SECRET_ACCESS_KEY`。旧的 `hectorvent/floci` 镜像不再更新，應改用新镜像名。測試腳本應显式寫 endpoint，避免把本地凭據發到真實 AWS。
floci-io-floci-deep-analysis｜CLI 启動後所有請求指向 4566：floci 的边界還要從輸入和輸出两端确认。輸入端記錄版本、設定、凭證來源、操作系統和依赖，輸出端記錄檔案、日志、網络請求、状態變化和錯誤信息。一次通過只能證明這組条件下可執行，不能替代升級後的回归。對專案 README 沒有明确說明的功能，驗收报告應保留“文檔未說明”的標記，並把實際观察與作者声明分開。這樣在後续换机器、换版本或换資料時，團隊才能定位差异來自哪裡。
floci-io-floci-deep-analysis｜CLI 启動後所有請求指向 4566：floci 的失败路径也應成為測試樣本。故意提供無效参數、缺少依赖、過期凭證、不可存取的路径和中途退出，記錄程序是拒绝、重试、部分完成還是留下残留。若專案会触碰远程服務、Docker、模型或用戶資料，應在隔离账號與临時目錄中執行，並在結束後清除測試资源。README 描述的是專案能力边界，具體故障恢複、權限最小化和資料清理仍需由使用方确认。
floci-io-floci-deep-analysis｜進程內服務與真實 Docker 服務
floci-io-floci-deep-analysis｜進程內服務與真實 Docker 服務 的專案脈絡：README 的架構把請求交給 4566 端口的 HTTP Router，再分發到無状態、有状態和容器服務。S3、DynamoDB、SQS、SNS、IAM、KMS、Step Functions、CloudFormation 和 EventBridge 等属於進程內模拟示例；Lambda、RDS、Neptune、ElastiCache、MSK、ECS、EC2、EKS、OpenSearch 和 CodeBuild 等使用真實 Docker 後端。
floci-io-floci-deep-analysis｜進程內服務與真實 Docker 服務：這一区分影响启動時間、资源消耗和兼容性floci判断。RDS PostgreSQL 預設镜像是 `postgres:16-alpine`，Lambda 使用 `public.ecr.aws/lambda/<runtime>`，MSK 使用 Redpanda，EKS 使用 k3s。預設镜像可通過 `FLOCI_SERVICES_RDS_DEFAULT_POSTGRES_IMAGE` 等環境變量覆盖。README 沒有說明 Docker 不可用時每項服務怎樣失败，CI 應先檢查 Docker 套接字和镜像拉取權限。
floci-io-floci-deep-analysis｜進程內服務與真實 Docker 服務：選擇 floci 時還要把“能做什么”和“怎樣維護”放在同一张表中。記錄首次安裝需要的工具、預設路径、启動入口、可选服務和必须锁定的版本。對設定項逐個寫明來源，不把示例值當成生產預設值。若 README 只給出了概念介绍，就回到對應官方文檔核對参數；若两處說明不一致，以實際版本的指令輸出和倉庫檔案為準，並在記錄中注明差异。
floci-io-floci-deep-analysis｜進程內服務與真實 Docker 服務：floci 的回归樣例應盡量小而稳定。固定輸入後保存一次成功結果，再保存一次預期失败結果，确保升級時能發現行為改變。對於網络、模型、远程倉庫或容器服務，記錄是否存取外部资源、哪些資料会持久化、停止後怎樣清理。對於纯本地流程，仍要檢查日志中是否出現秘密和临時檔案。這樣的記錄能把專案 README 中的事實转成可重複的工程floci判断。
floci-io-floci-deep-analysis｜四種存储模式對應不同測試语義
floci-io-floci-deep-analysis｜四種存储模式對應不同測試语義 的專案脈絡：`FLOCI_STORAGE_MODE` 支援 memory、persistent、hybrid 和 wal。memory 將資料留在內存，容器停止後丢失；persistent 每次寫入後刷盘；hybrid 每 5 秒异步刷新；wal 在响應前記錄變更。README 建議 memory 用於 CI 和临時測試，hybrid 用於本地開發。
floci-io-floci-deep-analysis｜四種存储模式對應不同測試语義：選擇模式前要明确測試想floci驗證什么。若每個用例都從空環境開始，memory 能减少残留；若要檢查重启後的资源，使用 persistent 或 wal，並寫恢複断言；hybrid 则必须接受异步刷新窗口。不要僅凭成功返回floci判断資料已经落盘，重启進程並讀取目標 bucket、table 和 queue 才能floci驗證實際语義。
floci-io-floci-deep-analysis｜四種存储模式對應不同測試语義：floci 的版本記錄還應包含實際執行日期、系統版本和關键依赖版本。出現差异時先回看這三項，再定位設定或輸入變化。
floci-io-floci-deep-analysis｜账戶 ID 讓本地资源彼此隔离
floci-io-floci-deep-analysis｜账戶 ID 讓本地资源彼此隔离 的專案脈絡：README 說明，當 `AWS_ACCESS_KEY_ID` 恰好是 12 位數字時，Floci 把它视為账戶 ID，並按账戶隔离资源。其他格式会退回 `FLOCI_DEFAULT_ACCOUNT_ID`，預設是 `000000000000`。STS AssumeRole 產生的临時凭據会路由到被假定角色所属账戶。
floci-io-floci-deep-analysis｜账戶 ID 讓本地资源彼此隔离：這使同一模拟器可以承載多個測試上下文，但也带來設定陷阱：随意使用 `test` 作為 access key 会讓资源落到預設账戶。測試應為每個場景明确設置账戶 ID，創建同名资源後分別讀取，确认不会串資料，再測試 AssumeRole 的路由。README 沒有把账戶隔离描述為真實 AWS 的完整 IAM 安全边界，不能據此降低權限審查。
floci-io-floci-deep-analysis｜账戶 ID 讓本地资源彼此隔离：升級後還要重開编辑器，确认設定加載顺序和插件錯誤提示沒有改變；再檢查新旧快捷键、終端行為和语言服務器連接。
floci-io-floci-deep-analysis｜SDK、IaC 與專案自报測試數量
floci-io-floci-deep-analysis｜SDK、IaC 與專案自报測試數量 的專案脈絡：README 展示 Java v2、Python boto3、Node.js v3、Go v2、Rust 和 AWS CLI 的連接方式，也列出 Java、Node.js、Python 的 Testcontainers 模块，Go 模块標為進行中。compatibility-tests 目錄包含 2,506 個自動化測試，覆盖 5 個 SDK 和 Terraform、OpenTofu、AWS CDK 三種 IaC 工具。
floci-io-floci-deep-analysis｜SDK、IaC 與專案自报測試數量：README 的细分數字是 Java 1,326、Node.js 449、Python 311、Go 157、AWS CLI 205、Terraform 22、OpenTofu 16、CDK 20。這些是專案自己的測試套件，不是独立floci驗證。floci采用前應抽取與自己服務相關的測試，补充業務操作、錯誤路径和並發場景，並記錄 Floci 版本與 Docker 镜像標簽。
floci-io-floci-deep-analysis｜迁移 LocalStack 時檢查兼容層
floci-io-floci-deep-analysis｜迁移 LocalStack 時檢查兼容層 的專案脈絡：Floci README 將自己定位為 LocalStack Community 的替代品，並寫明旧社区版本在 2026 年 3 月停止維護。迁移時可把镜像改為 `floci/floci:latest`；若初始化腳本需要 AWS CLI 或 boto3，则使用 `floci/floci:latest-compat`。`LOCALSTACK_HOST` 会翻译為 `FLOCI_HOSTNAME`，`PERSISTENCE=1` 会翻译為 `FLOCI_STORAGE_MODE=persistent`，`DEBUG=1` 会翻译為 `QUARKUS_LOG_LEVEL=DEBUG`。
floci-io-floci-deep-analysis｜迁移 LocalStack 時檢查兼容層：`/etc/localstack/init/` 下的腳本保持不變，README 還保留 `/_localstack/init`、`/_localstack/health` 和 `Ready.` 行供等待工具使用。可設置 `LOCALSTACK_PARITY=false` 關闭自動翻译。迁移不能只替换镜像名，應比較启動日志、健康端点、初始化顺序、服務响應和資料清理；標簽有 latest、固定版本、nightly 及日期 nightly，生產 CI 應固定版本。
floci-io-floci-deep-analysis｜迁移 LocalStack 時檢查兼容層：Floci 的兼容性驗收應同時測試進程內服務和 Docker 後端。先用 floci start、eval $(floci env)、aws s3 mb 與 dynamodb create-table floci驗證端点，再切换 compose.yaml，确认 4566 端口、AWS_ENDPOINT_URL 和非空凭據設置一致。為 memory、persistent、hybrid、wal 分別寫入资源並重启，記錄哪些資料保留。用两個 12 位 AWS_ACCESS_KEY_ID 創建同名资源，檢查账戶隔离，再floci驗證 AssumeRole 路由。迁移 LocalStack 時固定镜像標簽，比較初始化腳本、Ready. 行、/_localstack/health、錯誤响應和清理結果。compatibility-tests 的 2,506 個測試是專案自报數量，應從中挑选目標 SDK 與 Terraform 流程再补充業務用例。
編輯結論
適合本地開發、自動化測試和 CI 中需要 AWS 形状接口的團隊；不適合未经兼容性驗證就把模拟結果當成真實 AWS 行為。先執行 `floci start`、`eval $(floci env)` 和一条 S3/DynamoDB 指令，随後驗證存储模式、账戶隔离、Docker 後端服務和目標 IaC 流程，再决定是否替换現有 LocalStack 流程。
社群筆記