CoolkHz/gptibo

GPTibo 是一个以 MIT 许可开源的数字商品商城源码，适合想自己运营店铺、把下单交付和代理商体系放在一套系统里的开发者，但它不是开箱即用的成品。

解决什么问题

卖数字商品通常要把商品展示、下单支付、订单交付、售后处理拆到不同工具里，订单状态在一处、发货在另一处，代理商的定价与结算又靠手工表格。GPTibo 把商品与套餐展示、下单、支付状态、订单查询和售后申请放进同一个前台，另外提供管理后台和独立的代理工作台——代理商可以有自己的品牌店、自定义域名和下级代理。改变在于，一笔订单从购买到交付、退款可以在同一套界面里追踪，而不是在互不相通的服务之间来回核对。

有什么不同

结构上最值得注意的选择是两套可替换后端：一套 Go + Gin + PostgreSQL，把 API 和负责异步任务的业务 Worker 分成两个进程；另一套 Cloudflare Workers + D1，通过 Wrangler 在本地运行。两者服务同一个商城，所以这是部署形态的选择，而不是功能差异。前端是 React 19 + TypeScript，邮件用 React Email 模板，测试和静态检查都有文档化的流程。代价也在这里：两套后端加上代理层，意味着更多需要保持一致的配置面；而且仓库明确不含独立供货平台和供应商执行系统，只有商城侧的供应商适配器。

支付与供应商接入被刻意匿名化：适配器使用通用名称，聚合支付网关叫 gatewaya/gatewayb，example.invalid 是不可用于真实接入的保留域名。要真正收款或发货，你得按自己的服务协议核对地址、签名、商品映射、金额和回调，再开启对应功能。这是一个能跑起来的骨架，不是现成店铺。

谁值得试

适合已经拥有支付和供应商账号、想自建带代理体系的数字商品商城的开发者或小团队，并且愿意自己接适配器、在自己的环境里把完整交易流程跑一遍。偏好 PostgreSQL 和独立伸缩的 API/Worker 可以选 Go 方式；偏好 D1 和 Wrangler、想要更轻的本地环境可以选 Cloudflare 方式。不适合期待开箱即用的人：默认配置没有可直接登录的管理员账号，也不发起真实支付、采购或通知，更没有随源码提供的供货系统。

使用条件与边界

环境需要 Node.js 24、npm、Git 和 Python 3；Go 后端还需要 Docker Compose，或用 Go 1.26+ 配合 PostgreSQL 原生开发；Cloudflare 后端则要创建自己的 Wrangler 资源。管理员登录要自己配置身份、TOTP 和邮件验证服务，没有绕过后台的捷径。安装必须使用新数据库，匿名化后的迁移明确不兼容原生产数据库，示例商品和金额仅用于演示。完整数据库测试需要连接库名以 _test 结尾的专用数据库，未配置时集成测试会被跳过，所以测试通过本身并不覆盖数据库行为。自动化测试不会连接真实的支付或供应商服务，生产部署前要自行验证完整交易流程。动手前先看 Go 后端文档 和接入示例配置。

HotRepo 点评

HotRepo 从 2026-10-24 开始记录这个 11 天大的仓库；2026-10-25 的 TypeScript 新项目榜上显示总星数 857、排第 #11。这是新项目榜的位次，不是总榜排名，两天的样本也不足以判断热度能否持续。考虑到缺少供货平台、适配器已匿名化，真正要确认的是你自己的支付和供应商服务能否按文档中的适配器接口对上，这比急着部署更值得先查清楚。