Hi.Events v1.11.2 介绍与选型指南
目标：面向准备自建活动售票与活动管理系统的技术选型者，全面介绍开源票务平台 Hi.Events 的定位、架构、功能、部署形态与同类横向对比。本文为认知篇，全部信息均来自官方渠道（官网、官方文档、GitHub 仓库、GitHub Releases、Docker Hub），溯源查询日期统一为 2026-10-23，本文不做
Hi.Events v1.11.2 介绍与选型指南
目标：面向准备自建活动售票与活动管理系统的技术选型者，全面介绍开源票务平台 Hi.Events 的定位、架构、功能、部署形态与同类横向对比。本文为认知篇，全部信息均来自官方渠道（官网、官方文档、GitHub 仓库、GitHub Releases、Docker Hub），溯源查询日期统一为 2026-10-23，本文不做本地实测；安装与部署的实操验证见本专栏后续篇章。
一、环境信息
| 项目 | 内容 |
|---|---|
| 项目名称 | Hi.Events |
| 代码仓库 | HiEventsDev/Hi.Events（GitHub） |
| 官网 / 在线服务 | https://hi.events |
| 官方文档 | https://hi.events/docs |
| 部署文档 | https://hi.events/docs/getting-started/deploying |
| 最新稳定版本 | v1.11.2-beta（GitHub Releases，发布于 2026-10-21；本文以 v1.11.2 指代该稳定线） |
| 候选版本 | v2.0.0-rc.3（GitHub Releases，发布于 2026-10-21；develop 分支 VERSION 文件已为 2.0.0-rc.3，处于发布候选阶段） |
| 开源许可证 | AGPL-3.0 with additional terms（仓库页面标注；附加条款主要约束 SaaS 转售与署名移除） |
| 社区热度 | GitHub Stars 4.1k、Forks 约 744（shields.io 徽章，2026-10-23 实查） |
| 技术栈 | 后端 Laravel（PHP，源码 composer.lock 实测 Laravel 12.34.0）；数据库 PostgreSQL 13+（需 pg_trgm 扩展）；缓存/队列/会话 Redis；前端 React + Vite + Node.js SSR |
| 官方镜像 | daveearley/hi.events-all-in-one:v1.11.2-beta（Docker Hub，多架构 amd64/arm64，压缩体积约 276MB、解压后约 1.47GB，累计拉取 213,577 次，2026-10-23 实查） |
| 分离镜像 | hi.events-frontend（累计拉取 10,879 次）、hi.events-backend（累计拉取 6,609 次），官方推荐生产环境前后端分离部署 |
版本甄别说明：GitHub Releases 上 v1 线最新为 v1.11.2-beta，v2 线处于 v2.0.0-rc.3 候选阶段；Docker Hub latest 标签当前指向 v2.0.0-rc.3。生产选型建议以 v1.11.2 稳定线为基准，v2 正式发布后再行评估升级。
二、软件概述
Hi.Events 是一个开源的活动票务与活动管理平台，定位为 Eventbrite 的自托管替代方案，覆盖「创建活动 → 配置票种 → 售票收款 → 订单与购票人管理 → 现场签到 → 数据报表」的完整业务闭环。项目由商业化团队维护（同站提供官方托管 SaaS 服务），开源自托管版与 SaaS 共用同一套代码基线，迭代节奏明显快于同类老牌开源票务项目。
核心卖点可以概括为三点：
- 现代化售票页：前端为 React 单页应用（支持 Node.js 服务端渲染），购票流程、活动主页观感明显优于多数 PHP 系老牌票务项目，移动端适配良好。
- 组织者多活动管理：以「组织者（Organizer）→ 活动（Event）→ 票务产品（Product）」三级结构管理多场次、多活动业务，支持活动分类、报表汇总到组织者维度。
- 完整的开放能力：REST API 全域覆盖（认证、组织者、活动、票务产品、订单、购票人、统计、Webhook），JWT 认证开箱即用，便于与自有系统集成。
许可证为 AGPL-3.0 且附带附加条款（additional terms），约束点与 Pretix 类似：以 SaaS 形式对外提供服务或移除界面署名需购买商业授权。选型前应评估自身使用形态是否触及附加条款边界。
三、核心架构
官方部署文档将系统拆分为两大组件：
- 前端（Frontend）：Node.js React 应用，负责用户界面与购票页渲染，支持 SSR（服务端渲染进程默认监听 5678 端口）；
- 后端（Backend）：Laravel PHP 应用，承载 REST API 与全部业务逻辑，统一入口由 nginx 将
/api前缀路由到 PHP-FPM。
周边依赖与运行形态如下：
| 组件 | 说明 |
|---|---|
| 数据库 | PostgreSQL 13+，官方唯一正式支持的数据库；需启用 pg_trgm 扩展（迁移脚本自动创建）。Laravel 框架理论上可切换连接器，但官方镜像、迁移与文档口径均仅覆盖 PostgreSQL |
| Redis | 承担缓存（CACHE_STORE）、队列（QUEUE_CONNECTION=redis）与会话（SESSION_DRIVER=redis）三类职责，属必装依赖 |
| 队列 Worker | php artisan queue:work --queue=default,webhook-queue --sleep=3 --tries=3 --timeout=60，订单邮件、Webhook 分发均走异步队列，官方要求生产环境常驻运行 |
| 调度器 | php artisan schedule:run 每分钟触发（cron 或常驻循环），负责报表聚合等周期任务 |
| all-in-one 镜像内部 | 官方将 nginx、php-fpm、队列 Worker、调度器、前端 SSR 五个进程以 supervisord 托管在单容器内，并提供自动建表启动脚本（storage:link、migrate --force 等），适合快速起栈；生产环境官方推荐前后端分离部署 |
| 认证体系 | 管理端与 API 使用 JWT（默认有效期 7 天，expires_in=604800），公开展单、公开下单走独立的公开路由 |
官方支持三种部署形态：一键云部署（verified cloud partners）、Docker 部署（官方推荐，all-in-one 或前后端分离镜像）、手动部署（PHP + Composer + nginx + php-fpm + systemd 自行编排，适合深度定制与内网环境）。
四、功能特性
基于官方文档与仓库功能清单归纳（2026-10-23 溯源）：
- 活动与组织者管理：多组织者、多活动、活动分类、活动状态机（DRAFT / LIVE / ARCHIVED）、活动公开页与售票期控制（起售/停售时间）。
- 票务产品体系：产品分票券（TICKET）与普通商品（GENERAL）两类；价格类型覆盖免费（FREE）、付费（PAID）、捐赠（DONATION）、阶梯价（TIERED）、报名登记（REGISTRATION）；支持每票种独立库存、每人限购、税费与促销码。
- 订单与购票人：完整订单生命周期（待支付/已完成/已取消/退款）、购票人信息采集与导出、订单明细与支付记录。
- 支付集成：Stripe 官方集成（公钥/私钥/Webhook 密钥三件套配置），订单回调用 Stripe Webhook 驱动；PayPal 等支付渠道见官方路线图与 v2 规划。
- Webhook 事件分发：订单创建、订单完成、购票人签到等业务事件可配置 Webhook 推送，队列独立（webhook-queue），带签名密钥校验与 SSRF 防护（拒绝内网地址）。
- 数据报表：按活动/组织者维度的销量、收入、订单来源、渠道统计 API 与后台报表页。
- 开放 API：REST API 覆盖认证、组织者、活动、票务产品、订单、购票人、统计、Webhook 等域；v1 线以 JWT 认证，个人 API Key 管理为 v2 线新增能力。
- 消息通知：基于 Laravel Mail 的订单确认、票券发放等邮件通知，支持 SMTP 与多种 mailer 驱动。
- 多币种：账户级货币设置（创建账户时指定 currency），票价以最小货币单位（分）存储。
五、快速开始（最小可用示例）
官方推荐的快速路径是 Docker all-in-one 镜像（本节为官方口径转述，完整实测流程见本专栏《Hi.Events v1.11.2 Docker Compose 部署指南》）：
- 准备
APP_KEY（base64 编码的 32 字节密钥）与JWT_SECRET； - 使用官方
docker/all-in-one/docker-compose.yml拉起三服务栈：hi.events-all-in-one（Web 入口 80）、postgres:17-alpine、redis:7-alpine； - 首次启动时镜像内置启动脚本自动完成
migrate --force、缓存清理与storage:link； - 访问
http://<主机>:<端口>/进入前端，首次使用注册管理员账号，随后在管理后台创建组织者与活动。
官方分离镜像路径（生产推荐）：daveearley/hi.events-frontend + daveearley/hi.events-backend，各自独立扩缩容；注意分离镜像的 backend 不内置自动建表，需自行执行迁移命令。
六、适用场景与限制
适用场景：
- 会议、演出、培训、社群活动等需要公开售票页与在线下单的场景；
- 组织者维度管理多活动、需要统一报表的中小型主办方；
- 需要 REST API 深度集成（例如将订单数据同步到内部系统）的技术团队；
- 希望摆脱 SaaS 按票抽成、数据自持的自托管用户。
限制与注意事项：
- 数据库仅支持 PostgreSQL：官方迁移、镜像与文档均不提供 MySQL 支持口径，已有 MySQL 运维体系需评估引入 PostgreSQL 的成本；
- PHP 生态依赖：需 PHP 8.3+、Composer、phpredis 扩展（composer.json 未包含 predis，缺 php8.3-redis 会导致运行时报错）；
- AGPL-3.0 附加条款：对外提供托管售票服务（SaaS 化）或移除品牌署名需商业授权，普通企业内部使用不受影响；
- v2 处于候选阶段：v2.0.0 仍在 rc 迭代，个人 API Key、SSO 等新能力以 v2 线为主，生产环境建议锁定 v1.11.2 稳定线；
- 支付生态相对收敛：v1 线支付渠道以 Stripe 为主，相比 Pretix 的数十种支付插件生态明显收敛，国内支付渠道均需自行开发。
七、同类选型对比
本章对自托管开源活动票务类系统中社区活跃度较高的同类项（Pretix、Alf.io、Cal.com、Odoo Events）与 Hi.Events 做量化对比，另附 SaaS 代表（Eventbrite）作参照系。星数取证自 shields.io 徽章（2026-10-23 实查：HiEventsDev/Hi.Events=4.1k、pretix/pretix=2.5k、alfio-event/alf.io=1.6k、calcom/cal.com=49k、odoo/odoo=55k 整仓），版本节奏取证自各项目 GitHub Releases（2026-10-23 实查），许可证取证自各仓库页面。
| 维度 | Hi.Events v1.11.2 | Pretix | Alf.io 2.0-M5-2609 | Cal.com v6.2.0 | Odoo Events（社区版） | Eventbrite（SaaS，参照） |
|---|---|---|---|---|---|---|
| GitHub 星数（2026-10-23） | 4.1k | 2.5k | 1.6k | 49k | 55k（整仓，Events 仅其模块） | 不开源 |
| 许可证 | AGPL-3.0+附加条款（禁 SaaS 转售/去署名） | AGPLv3+附加条款 | GPL-3.0 | MIT（API v2 部分能力有商业限制） | LGPLv3 | 商业 |
| 技术栈 | PHP 8.3 / Laravel 12 | Python / Django | Java 17 / Spring Boot 3.5 | TypeScript / Next.js + Prisma | Python / Odoo 框架 | — |
| 数据库 | 仅 PostgreSQL 13+（pg_trgm） | PostgreSQL（部分测试场景 SQLite） | 仅 PostgreSQL | PostgreSQL / MySQL 等（Prisma） | PostgreSQL | — |
| 最新版本节奏（2026-10-23 实查） | v1.11.2-beta 与 v2.0.0-rc.3（2026-10-21）双线发布 | 持续发布（2026 年活跃） | 2.0-M5-2609（2026-09-18） | v6.x 月度小版本 | 18.0 年度版 | — |
| 缓存/队列依赖 | Redis 必装 | 可选（数据库队列兜底） | 内置（Java 内存/DB） | Redis 可选 | 依赖 Odoo 部署形态 | — |
| 部署形态 | all-in-one / 分离镜像 / 源码部署 / 一键云 | Docker / pip / 官方 SaaS | JAR 直装 / Docker | Docker / Vercel / Node 直装 | Odoo 整体部署 | 免部署 |
| 票务模型 | 票券+普通商品双类型，价格类型 5 种（含捐赠/阶梯/报名） | 场次座席、订阅式票、复杂折扣规则、插件市场 | 分组票、座位图、等待名单 | 活动预约/会议调度（ booking 型，非售票型） | 活动模块（依赖 Odoo 销售/网站模块） | 平台统一 |
| 支付集成 | Stripe（v1 主渠道） | Stripe/PayPal/银行转账等数十种插件 | Stripe/Mollie/PayPal/转账等 | Stripe 等 | 随 Odoo 生态 | 平台统一 |
| 开放 API | REST + JWT 全域覆盖，Webhook | REST API + 插件钩子 | REST API | REST API v1/v2 | XML-RPC/JSON-RPC | 封闭 |
| 现场签到 | 后台在线 check-in | 官方移动 App check-in | 移动 App + 树莓派离线签到站（端到端加密） | 不适用（预约型） | 依赖 Odoo 生态 | 官方 App |
| 按票抽成 | 无（自托管） | 无（自托管）；官方 SaaS 收费 | 无 | 无（自托管） | 无 | 按票抽成+服务费 |
| 运维复杂度 | 中（PHP-FPM + Node SSR + PG + Redis + 双常驻进程） | 中低（Python 单体 + 可选 Redis） | 低（Java 单 JAR + PG） | 中高（Node 生态 + 多服务） | 高（整套 ERP） | — |
关键差异与选型解读：
- 售票业务完整度 vs 预约业务：Cal.com 是「预约/日程调度」平台（MIT、49k 星），不做售票订单模型；若核心诉求是卖票收款，Cal.com 不构成同类候选，仅当业务是「约课/约会议」时选它。
- 功能广度首选 Pretix：座席、场次、复杂折扣、插件市场是开源票务里最全的，代价是 Django 技术栈与 AGPLv3 附加条款；功能深度需求突出的选 Pretix。
- Hi.Events 的差异化是现代售票页与快速迭代：React 前端购票体验、双版本线（v1 稳定 + v2 候选）高频率发布、星数增长快（4.1k）；运维链路（PHP + Node + PG + Redis + 队列 + 调度器）比 Alf.io 重，比 Odoo 轻。
- 极简与现场签到选 Alf.io：单 JAR 部署、512MB 内存可跑、树莓派离线签到是独门能力；但 UI 与售票页观感偏传统。
- 选型建议（如果…则…）：
- 如果你追求现代购票页、组织者多活动管理、REST API 集成且接受 PHP 技术栈 → 选 Hi.Events；
- 如果你要最全票务玩法（座席/折扣/插件） → 选 Pretix；
- 如果你要最轻部署与离线签到 → 选 Alf.io；
- 如果业务本质是预约而非售票 → 选 Cal.com；
- 如果本来就要上 Odoo ERP → 直接用 Odoo Events 模块；
- 如果完全不想运维 → Eventbrite 等商业 SaaS（接受按票抽成）。
八、参考链接
- 官网与在线服务：https://hi.events
- 官方部署文档：https://hi.events/docs/getting-started/deploying
- GitHub 仓库：https://github.com/HiEventsDev/Hi.Events
- GitHub Releases（v1.11.2-beta / v2.0.0-rc.3，2026-10-21 发布）：https://github.com/HiEventsDev/Hi.Events/releases
- Docker Hub 镜像（all-in-one）：https://hub.docker.com/r/daveearley/hi.events-all-in-one
- 站内同类项目：《Alf.io 2.0-M5-2609 介绍与选型指南》
- 本专栏后续篇章：《Hi.Events v1.11.2 Docker Compose 部署指南》《Ubuntu 22.04 安装 Hi.Events v1.11.2 指南》《Hi.Events v1.11.2 配置参数详解》《Hi.Events v1.11.2 API 使用详解》