企业官网建设流程全解析

Lago 开源用量计费：4 步跑通第一条计费事件

【免费下载链接】lagoOpen Source Metering and Usage Based Billing API ⭐️ Consumption tracking, Subscription management, Pricing iterations, Payment orchestration & Revenue analytics项目地址: https://gitcode.com/GitHub_Trending/la/lago

当你的产品开始按量收费——按 token、GPU 时长还是 API 调用次数——计费问题会直接砸到工程师头上：用量数据怎么收、重复上报怎么去重、阶梯价怎么算、信用额度怎么抵扣、最后怎么出账。Lago 是一款开源的计量与基于使用的计费系统，API 优先、无头（headless），发事件进去、出账单出来。如果你正在纠结计费系统自建还是购买，它值得看。

它到底能帮你干什么

做按量计费：API 发 token 事件，拿到美元金额

你每次调用发一条 JSON 事件（订阅 ID + 用量字段），Lago 按计费指标聚合、套用定价规则，输出一个金额。仓库自带的 demo 里，3 次 AI 请求共发 6 条 token 事件：5000 输入 token × $0.000002 + 1250 输出 token × $0.000008，合计恰好 $0.02，且由脚本独立对账。事件按transaction_id去重——同一事件重试会返回 422 而不是重复计费，这是自建系统最容易写错的地方。

替代 Stripe Billing：定价收进自己手里，收款仍留在 Stripe

Lago 管的是计费目录层：计划、定价（usage、recurring、prepaid、graduated、volume、package、minimum commitment、混合计费）、订阅、优惠券、credit notes。收款交给 Stripe、Adyen 或 GoCardless，Lago 只做编排、重试和逾期催收（dunning）。收款方可以换，Lago 不会反过来成为你产品目录的单点依赖。自助公开的价目表和销售主导的自定义报价在同一套系统里并存。

开票前抵扣信用额度：预付费钱包与超额计费同计划生效

如果你卖预付费额度（wallet）或给客户发放 credit grants，Lago 在开票前同一管线内先扣钱包余额，超出部分才进账单，不用等计费周期结束。订阅计划同时支持 allowance（包含额度）、minimum commitment 和超额计费，三者在同一个 plan 里配置。

从克隆到第一条请求

环境只需 Docker + Docker Compose，外加 OpenSSL 生成签名密钥；跑 demo 还要 curl 和 jq。四步走：

先克隆仓库，生成 Lago 给 webhook 签名用的 RSA 私钥，然后拉起全栈（PostgreSQL、Redis、API、前端）：

git clone --depth 1 https://gitcode.com/GitHub_Trending/la/lago.git cd lago echo "LAGO_RSA_PRIVATE_KEY=\"$(openssl genrsa 2048 | openssl base64 -A)\"" >> .env docker compose up -d

主服务起来后，前端在 http://localhost（80 端口），API 在 http://localhost:3000/api/v1。冒烟测试先打 health 端点确认 API 存活（compose 文件里的健康检查就是这条路径），再跑自带的 AI 计费 demo——它自动建组织、客户、计划、订阅，发 3 次 AI 请求并对账，最后重试一条事件验证幂等：

curl -fsS http://localhost:3000/health ./examples/agentic-ai-demo/run.sh

脚本打印 $0.02 用量合计即为通过；demo 用独立栈跑在 8080/3001 端口，按提示用agentic-ai-demo@example.local登录，能在 UI 里看到这条订阅的 token 用量和账单。玩完执行./examples/agentic-ai-demo/run.sh --cleanup清理容器和数据卷。

背后怎么工作

Lago 是一个无头、API 优先的计费引擎：Rails API 接住请求、把大部分工作排入 Sidekiq，worker 从多个队列消费，完成计量、开票与收款。Sidekiq 就像计费系统的后台厨房，API 只是点单的窗口。

最容易踩坑的是队列路由和 Redis 拓扑。事件落进 API 后写入主 Redis（专给 Sidekiq 队列用），worker 按 high_priority → default → 低优先级队列的顺序消费。注意 Lago 跑着三个独立 Redis：主队列、Rails 缓存、事件处理数据各占一个，迁移和备份时别只盯一个。事件量大时启用 events-processor 组件，从 Kafka 或 SQS 拉事件独立聚合（接入配置见 connectors 目录），生产环境再用SIDEKIQ_EVENTS=true把事件处理拆到专用 worker，与开票等作业隔离。

选型决策 & 上手建议

• 选它：你计费的是用量（token、算力、API 调用），希望计划、定价、额度、发票全部通过代码和 API 管，且需要审计事件管线与幂等逻辑
• 不必选它：纯按座位、固定月费的 SaaS——Stripe Billing 这类托管服务一个订阅价就够，Lago 的队列 + worker 栈属于过度设计
• ⚠️ 核心代码是 AGPLv3，若打算嵌进商业产品对外提供，先评估许可证条款，或直接用官方云版本

clone 下来，把「从克隆到第一条请求」那节四步跑通，看到 $0.02 对账通过，再决定要不要深用。

【免费下载链接】lagoOpen Source Metering and Usage Based Billing API ⭐️ Consumption tracking, Subscription management, Pricing iterations, Payment orchestration & Revenue analytics项目地址: https://gitcode.com/GitHub_Trending/la/lago