如果你偶尔逛开源社区，应该见过 ever-gauzy 这个仓库。我第一次翻它，说实话有点被吓到——会计、发票、CRM、项目、库存、HR，一个开源项目全都想管。但真把它部署起来，慢慢拆开代码之后，我反而觉得这是目前少有的、能直接在中小公司落地的开源企业管理平台。它既不是玩具项目，也不是给大厂用的重型套装，解决的恰恰是“从几张 Excel 表格升级到正经业务系统”这个最难跨越的阶段。后来我又接触了不少同类项目，回头再看 ever-gauzy，更清楚它在做哪块拼图了。如果你正在做项目选型、需要二次开发，或者纯想学习全栈业务系统怎么组织，这篇内容值得你花几分钟看完。
我最早接触这个项目，是想找一个能统一管理“客户、项目、发票、员工考勤”的底座。市面上的方案要么太重，部署一套要用专门的实施团队；要么太轻，只有简单的库存或发票功能。ever-gauzy 给我最大的感受是模块足够完整，而且代码结构并不像传统 ERP 那样一团乱麻，它是用现代全栈技术重写的。所以这篇文章我不想只停留在功能介绍层面，我会尽量讲清楚它背后的设计思路、部署时容易踩的坑、二次开发怎么切入，以及什么样的团队适合真的把它用起来。
1. 项目定位与整体设计思路
1.1 它到底想解决什么问题
ever-gauzy 的全称叫 Gauzy ERP/CRM，定位很明确：面向中小型企业的开源业务管理平台。传统的 ERP 系统通常从财务和制造出发，逻辑庞大、配置复杂，实施周期按年算；而 ever-gauzy 走的是一条更轻、更现代化的路线，它把公司日常经营里最高频的几个核心场景都放进同一个系统里：
- 财务侧：总账、发票、应收账款、应付账款、费用报销、银行对账。
- 业务侧：CRM、销售管道、报价单、合同、订单。
- 执行侧：项目管理、任务分配、时间跟踪、团队成员日程。
- 支撑侧：库存管理、采购、销售点收银、差旅报销、员工档案、工资核算。
这意味着你不需要为了管发票装一套工具，为了看销售装另一套工具，为了统计员工工时再装第三套。ever-gauzy 试图在一个平台里把这些数据打通：销售员的报价单被接受后，可以关联成订单，订单影响库存，交付产生项目工时，最后统一汇总到财务发票。这四五个环节的数据不靠人工搬运，系统内部就能互相引用。
1.2 为什么选择这套技术栈
说实话，第一次看到 ever-gauzy 的技术栈，我就知道它的目标用户不是传统 ERP 厂商，而是熟悉现代 Web 开发的团队。项目后端用 NestJS，前端用 Angular，桌面端用 Electron，数据库用的是 PostgreSQL + Redis，整个仓库由 Nx 做 monorepo 管理，开发语言统一为 TypeScript。
选 NestJS 的原因其实很务实：它底层的运行时还是 Node.js，程序员好招；同时 NestJS 的模块化、依赖注入、装饰器设计借鉴了 Angular 和 Spring 的长处，写业务模块的时候结构感特别强。Angular 在大型后台系统的开发效率上很突出，强类型模板、依赖注入、内置的 HttpClient 和表单校验，配合 TypeScript，能让几十个业务页面保持统一风格。Electron 桌面端也不是摆设，时间追踪这类功能需要员工在本地电脑上常驻一个客户端，桌面应用比浏览器 Tab 更适合。
这套技术栈最明显的好处是语言统一。后端、前端、桌面端、共享类型定义全部是 TypeScript，一个业务对象的结构可以在 contracts 库里定义一次，后端实体、前端展示、桌面端同步逻辑都能引用同一份类型，天然避免接口字段不一致。对于需要长期迭代的开源项目，这个优势会越滚越大。
1.3 仓库组成与模块划分
ever-gauzy 不是一个“一会就能看完”的小仓库，它是一个结构清晰的 monorepo。粗略看下来，主要分为几大块：
apps/api：NestJS 后端服务，REST API 的主要实现。apps/web：Angular 前端 Web 应用，也是日常使用的主界面。apps/desktop：Electron 桌面端，带有时间追踪、活动监控等本地功能。apps/server：一个辅助服务，常用于桌面端与后端之间的同步。libs/：共享代码库，包括contracts，也就是前后端共享的 TypeScript 接口和 DTO。database/：数据库迁移文件、种子数据、建表脚本。
这种结构对开发者非常友好。第一次见这个仓库的人不用东翻西找，按业务模块去libs和apps/api/src/app里找对应目录就行。例如财务相关的代码大多收在accounting和invoicing目录里，CRM 相关代码收在crm目录下，项目和时间管理在tasks、time-tracking目录里。命名规范统一，模块边界明确，这对统一的 ERP 系统很重要，因为一旦模块之间互相乱引用，后面改一处功能就可能牵动全部代码。
2. 核心功能模块拆解
模块多并不代表好用，关键是每个模块到底做到什么深度。我把 ever-gauzy 里值得关注的几个模块单独挑出来讲一讲，这样你评估它够不够用的时候，心里更有数。
2.1 财务与会计模块
财务模块是 ever-gauzy 最有分量的部分。它不是简单的“记录收入支出”，而是做了一套相对完整的会计账户体系。系统里可以配置总账科目、辅助核算项、支出类别、收入类别、税种税率、银行账户。每笔业务单据在创建时就能被归类到指定科目，月末对账、导出财务报表就有了基础数据。
发票模块也很实用，支持按项目、按客户、按周期性账期生成发票，可以自定义发票模板，设置税率和折扣，生成之后能一键标记为已发送、已支付、逾期，并记录付款历史。前端页面展示发票的列表、状态筛选和金额统计，财务人员可以直接在里面核对回款。
实际使用下来，财务模块的上手难度中等。如果你们公司目前只有流水账，没正经做过科目映射，那刚开始配置总账科目会花一些时间。但一旦科目体系建立好，后面的月度统计、税务导出、财务分析会高效很多。对大多数中小公司来说，这套会计模型已经比 Excel 强出一个数量级。
2.2 项目与时间管理模块
项目和时间管理是 ever-gauzy 里最贴近“日常执行”的部分。项目可以作为独立的业务对象被 CRM 的商机关联，也可以被财务管理的人员成本引用。项目下面可以拆分任务、设置负责人、截止日期、工时估算；每个员工可以通过时间表（Timesheet）提交自己某一天做了哪个项目、哪个任务、花了多少小时。
时间跟踪功能内置了两种方式：一种是手动添加工时条目，一种是使用桌面端应用自动记录活跃时间。桌面端会记录你打开的应用、访问的页面、鼠标键盘活跃状态，再自动生成一份时间日志。项目管理者看到的不再是员工自己写的“大概 8 小时”，而是按任务聚合的工时明细。
这个模块让我印象最深的是它的数据流转。时间日志提交后，可以关联到对应任务，任务关联到项目，项目关联到客户或合同，最终工时成本可以汇总到财务模块。也就是说，销售人员谈的单子，最后到底赚不赚钱，从“人天成本”的维度是能算出来的。这在很多大牌项目管理工具里都做不到这么彻底。
2.3 CRM 与销售运营
CRM 模块包括潜在客户管理、客户联系人、商机管道、销售活动记录等。你可以把客户按阶段放进管道，例如“初次接触、需求确认、报价、谈判、成交”。每个阶段可以设置赢单率，系统自动计算出加权后的预计营收。销售人员的日常跟进记录会形成历史时间线，管理者很容易看到某个商机卡在哪一个环节。
CRM 不是 ever-gauzy 的独门绝技，但它的优势在于和业务后端深度绑定。销售在 CRM 里建一个商机，可以直接生成报价单；报价单被客户确认后，又能一键转化销售订单；订单执行过程中还能关联项目和时间跟踪。这种“从线索到现金”的完整链路，是很多开源 CRM 不具备的。
有一点要注意，ever-gauzy 的 CRM 更偏向“内勤销售”而不是“营销自动化”。如果你的需求是复杂的邮件营销、广告线索评分、PaaS 级自动化，那它不擅长；但如果只是把客户和商机管起来，跟后续业务环节打通，它很合适。
2.4 HRM 与协同办公
人力资源模块覆盖员工档案、部门、职位、考勤、请假、报销、工资项等。员工信息可以和系统账号打通，从入职、合同、工资到离职都能在系统里留痕。考勤模块支持设置排班规则、休假类型、剩余假期天数，员工请假的审批流也能跑起来。
工资模块比较灵活，不是自动计算社保个税的全功能薪酬系统，而是偏向“工资项配置 + 发薪记录”。你可以定义基本工资、岗位津贴、绩效奖金、扣款等工资项，然后按月生成工资单，并关联到财务管理。
协同办公方面，ever-gauzy 提供了消息通知、日程、公开活动、团队页面等功能，但说实话，它不会替代 IM 或文档协作工具。它更擅长的是把业务数据中需要知会相关人的事件推送出来，比如任务被分配了、发票被支付了、报销被审批了。这类通知适合所有与系统打交道的人。
2.5 库存、采购与销售点模块
很多 ERP 会单独做一套复杂的进销存，ever-gauzy 的库存模块则更偏向“够用”。你可以维护商品/服务目录，管理 SKU、单位、成本价和零售价，处理库存入库、出库和盘点。采购订单和供应商管理也包含在内，拿到货后会更新库存数量。
销售点（POS）模块有点像线下门店收银台。它可以直接在前端 Web 界面里选择商品、计算总额、收款并生成收据，也能把销售记录同步到财务。这个模块对做零售、餐饮、服务门店的团队挺实用，不用额外购买收银软件。
不过，如果你身处制造业，需要复杂的 BOM 物料清单、生产排程、工序流转，那 ever-gauzy 的库存模块可能就不够用了。它的重点还是围绕“服务型公司”和“轻量商品销售”场景，而不是重型制造现场。
3. 部署实践：从零开始把 ever-gauzy 跑起来
这部分是如果你想把 ever-gauzy 真正用起来的关键。参考资料里的步骤看起来很简单，但实际部署时有不少坑，我按自己踩过的路径整理了一遍。
3.1 环境准备与依赖安装
部署 ever-gauzy 之前，需要准备一台至少 4GB 内存的服务器或开发机，操作系统用 Linux 或 macOS 比较省心。必装的依赖包括 Node.js 18+、Yarn、Docker 和 Docker Compose。前端构建过程比较吃内存，如果机器太老旧，建议在构建命令前设置 Node 的堆内存上限，避免进程中途崩溃。
克隆仓库、进入目录后，第一件事不是急着安装依赖，而是先看环境变量。
git clone https://github.com/ever-co/ever-gauzy.git cd ever-gauzy cp .env.example .env.env文件是整套系统的配置中心，数据库连接、Redis 地址、API 端口、JWT 密钥、支付网关密钥都在这里。默认配置一般能本地跑，但生产环境必须修改数据库密码和 JWT 密钥，否则会有安全隐患。
3.2 配置环境变量与数据库
ever-gauzy 的生产组件主要由 PostgreSQL 和 Redis 组成。PostgreSQL 存业务数据，Redis 负责缓存和部分限流、队列逻辑。在.env里需要重点关注这些变量：
| 环境变量 | 作用 | 常见值 |
|---|---|---|
| DATABASE_TYPE | 数据库类型 | postgres |
| DATABASE_HOST | 数据库地址 | localhost |
| DATABASE_PORT | 数据库端口 | 5432 |
| DATABASE_USER | 数据库用户名 | gauzy |
| DATABASE_PASS | 数据库密码 | 自己设置 |
| DATABASE_NAME | 数据库名 | gauzy |
| REDIS_URI | Redis 连接串 | redis://localhost:6379 |
| API_PORT | API 服务端口 | 3000 |
| WEB_PORT | Web 前端端口 | 8080 |
我自己的习惯是先用 Docker 把数据库和 Redis 拉起来，确认这两个依赖稳定了再启动应用服务。这样可以避免应用启动时反复报数据库连接失败，混淆问题所在。
docker-compose up -d postgres redis如果本机已经装了 PostgreSQL 或 Redis，需要确认端口没有冲突。特别是 PostgreSQL 的 5432 端口，很多本机开发环境里已经被其他项目占用了，冲突时要么改掉已有实例的端口，要么修改.env里的数据库端口配置。
3.3 初始化数据库结构与种子数据
依赖启动后，安装 Node 包，然后执行数据库迁移。ever-gauzy 使用 TypeORM 管理迁移，迁移文件里定义各表的结构。执行迁移前要确认数据库已经存在，并且用户名和密码与.env一致。
yarn install yarn run migration:run迁移成功后，接着灌入种子数据。种子数据包含默认管理员账号、基础角色、系统设置、示例客户和示例项目。这一步对新功能试用至关重要，没有种子数据，登录进去后界面会空荡荡的。
yarn run seed:all需要注意：种子脚本可能会执行一段时间，取决于机器性能。如果中途中断，不能直接重新跑，最好先确认上一次的导入是否产生了部分数据，否则容易造成重复数据。我的经验是种子脚本尽量保持原样执行完再离开，别开太多终端窗口抢数据库资源。
3.4 启动 API 与 Web 前端
数据准备就绪后，分别启动后端 API 和前端页面：
yarn run start:api这个命令会启动 NestJS 服务，默认监听 3000 端口。看到日志里出现类似 “API ready” 的输出，说明后端已经起来了。再开一个新终端：
yarn run start:web前端 Angular 开发服务器启动后，浏览器访问http://localhost:8080，用种子数据里的默认管理员账号登录即可。
如果不想在本地手动安装一堆依赖，也可以直接用 Docker Compose 构建并运行全套服务：
docker-compose up --build这条路耗时更长，第一次构建可能要 10 到 30 分钟，但好处是隔离性好，适合快速体验，不用担心污染本机 Node 环境。生产环境则不建议依赖开发服务器模式，应该分别构建好 API 和 Web 的镜像，再部署到服务器上。
3.5 生产部署必须补充的几点
生产环境和本地跑通是两码事。我后来把 ever-gauzy 部署到测试服务器时，踩了下面几个坑：
- 必须使用反向代理处理 HTTPS。Nginx 或 Caddy 都可以，把 API 的 3000 端口和 Web 的 8080 端口反代到 80/443，并把前端静态文件交给 Nginx 托管。
- 修改 JWT 相关密钥。默认值不能用于生产，该改的密钥全部通过环境变量重新生成。
- 数据库和服务分机器部署。如果公司体量不大，可以共用一台机器，但至少数据库要开启定时备份。
- 前端页面的接口地址要配置成生产 API 地址，不能写死
localhost，否则用户浏览器无法访问后端。
部署本身不算难，难的是把“本地能跑”变成“服务器上长期稳定”。ever-gauzy 的官方文档给了一些 Docker 部署建议，但我也建议根据你公司的实际机器配置，把资源限制写进 Docker Compose 里。比如内存不足时，Node 进程容易因为 OOM 被杀死，这时需要给容器配置mem_limit，再配合 Nginx 的请求超时设置，整体稳定性会好很多。
4. 代码结构与二次开发指南
如果你只是用默认功能，ever-gauzy 已经够重了；但大多数团队要用它，一定会有定制需求。定制从哪里下手？我先带你梳理一遍代码结构。
4.1 Monorepo 目录应该怎么看
很多人打开 ever-gauzy 仓库，第一反应是“目录怎么这么多”。关键是抓主干，不要试图一开始就理解每个文件。
- 后端功能代码统一在
apps/api/src/app下，每个业务模块是一个文件夹。 - 前端功能代码在
apps/web/src/app下，页面、组件、状态、路由都按业务域分开。 - 共享的数据结构在
libs/contracts下，比如IProduct、IInvoice、IOrganization这些接口。 - 后端实体类定义在各自模块的
entity文件夹里，与libs/contracts里的接口对应。
我建议第一次阅读的顺序是：先看libs/contracts里的几个核心接口，理解一个“订单/发票/项目”对象长什么样；再去后端模块里看对应的实体类和服务类；最后去前端找对应列表页面，就能把一个业务功能的闭环串起来。不用一上来就刨细节，先把骨架理顺。
4.2 数据模型与迁移机制
ever-gauzy 的数据模型是 TypeORM 实体。后端每个实体类都放在entities或entity子目录下，类名通常与数据库表名对应，例如Employee对应employee表，Invoice对应invoice表。
实体类的定义方式很简单，看一个简化示例就明白：
import { Entity, PrimaryGeneratedColumn, Column } from 'typeorm'; @Entity('employee') export class Employee { @PrimaryGeneratedColumn() id: number; @Column() name: string; @Column({ nullable: true }) department: string; }真实代码里还会加入多租户、软删除、审计字段等，但基础逻辑就是这样的。扩展字段时，最忌讳直接改实体类然后靠代码同步数据库，正确做法是改完实体类之后生成新的迁移文件。迁移文件记录的是数据库结构变更，能保证各个环境的表结构保持一致。ever-gauzy 里也有相应的迁移命令，团队规模很小时也可以直接用synchronize让 TypeORM 自动同步表结构，但这仅限开发测试环境，生产环境务必走迁移文件。
4.3 新增一个业务模块的步骤
假设你想加一个“车辆管理”模块，用来登记公司车辆的基本信息和借用记录，可以按照下面这套标准流程走：
- 在
libs/contracts下定义车辆的数据结构，比如IVehicle，包含车牌号、品牌、型号、购买日期等字段。 - 在后端
apps/api/src/app下新建vehicle模块目录，写Vehicle实体类、VehicleService业务逻辑、VehicleController路由控制器。 - 在服务模块里写好增删改查逻辑，并加上分页和权限校验。
- 在前端
apps/web/src/app/pages下新建页面组件，用 Angular 的服务去调用后端 API。 - 在路由配置里注册新页面，并在菜单配置里添加入口。
- 生成数据库迁移，部署后执行。
看起来步骤不少，但如果你熟悉 NestJS 和 Angular，整个流程是可以照着现有模块“抄作业”的。拿一个比较简单的模块当模板，复制它的目录结构，再改业务字段，效率最高。这个经验也适用于大多数模块化后端工程。
4.4 权限体系与多语言
ever-gauzy 的权限体系基于角色和权限点，登录用户被分配一个角色，角色又绑定一组权限，例如“查看发票”“创建订单”“管理员工”。在代码层面，路由可以用守卫装饰器来限制接口访问。做二次开发时，新增的接口如果不想被所有人调用，一定要加上权限校验，否则 sysadmin 登录后功能是放出来了，但接口可能暴露敏感数据。
多语言部分，ever-gauzy 前端用了 Angular 生态常见的国际化方案，语言资源文件放在指定目录，缺什么文案自己去补翻译。我实际开发时发现，新增一个页面的英文文案之后，中文翻译经常会忘记同步，所以建议每个功能合并前检查一下 i18n 文件是否完整。后端返回的错误消息也别都写死成英文，最好是错误码 + 多语言消息，前端统一处理，这套系统已经有一些基础，但自定义模块需要沿用同样的规范。
5. 常见问题与排查实录
开源系统自己动手部署、二次开发，肯定会碰到各种疑难杂症。我把踩过的坑和团队成员常遇到的问题整理成几大类，方便你照着排查。
5.1 启动阶段常见问题
最常遇到的是端口冲突。API 默认 3000 端口，Web 默认 8080 或 4200，如果你本地已经有其他项目占用了这些端口，启动时会直接报错。排查方法很简单：先看日志提示哪个端口被占用，然后去.env里修改对应端口，或者停掉占用进程。
其次是 Redis 连接失败。API 启动过程会去连接 Redis，如果 Redis 没启动，或连接串配置错误，API 可能进入反复重试甚至直接退出。解决办法是先单独验证 Redis 连通性：
redis-cli ping能返回PONG才说明 Redis 正常。如果用的是 Docker 里的 Redis，还要确认容器端口映射和.env里的REDIS_URI一致。
还有一个容易被忽略的坑：Node 版本太旧或太新。ever-gauzy 的依赖链很复杂，Node 18 是我测试下来比较稳妥的版本。某些新版本 Node 修改了内置模块行为，可能让依赖编译失败，建议先用项目文档要求的 Node 版本，别图新。
5.2 数据与迁移问题
数据库迁移失败是新手最常见的问题。执行yarn run migration:run时，报错信息通常能直接点出哪张表、哪个字段有问题。常见的几类原因：
- 数据库账号权限不足，创建不了表或修改表结构。
- 数据库字符集或排序规则不一致，导致字段校验失败。
- 之前手动改过表结构，和迁移文件里的预期不一致产生冲突。
处理办法说来也简单：不要直接手改生产库表，先回到一个干净的测试库，把迁移流程完整跑一遍。如果之前已经产生部分数据，建议备份后重置开发库，再从头执行迁移和种子脚本。切记，不要在迁移失败后盲目重复执行种子脚本，否则会出现重复员工、重复客户数据。
种子数据同样有版本顾虑。不同版本的 ever-gauzy 可能有不同结构，旧版本的种子数据不一定能直接灌进新版本。如果你从仓库拉的是最新代码，但数据库却是上一次旧版本的存量库，必须先把迁移执行到位，再考虑种子数据的兼容性。
5.3 前端构建与资源问题
前端构建是另一个容易出现问题的环节。Angular 项目构建时会占用大量内存，如果机器配置低，构建进程会被系统直接杀掉。我常用的一种做法是给 Node 设置更大的堆内存：
export NODE_OPTIONS=--max-old-space-size=4096然后再执行构建命令，基本能缓解大部分 OOM 问题。
还有一种情况是前端构建本身没报错，但页面访问后白屏，打开浏览器控制台看到接口 404。这种问题通常不是前端代码出错，而是 API 地址配置不对。ever-gauzy 的前端需要通过环境变量或配置文件知道后端 API 的地址，如果部署后前后端不在同一台机器，或者没用反向代理统一入口，前端请求就会找不到后端。
生产环境我最推荐的做法是让 Nginx 同时托管前端静态文件和代理/api路径到后端服务。这样前端请求走同域，不涉及跨域问题，也不用为 CORS 额外调整后端配置。
5.4 性能与稳定性的实战建议
ever-gauzy 默认配置在高并发场景下不一定表现出色，需要根据实际并发量做一些调整：
- 前端静态资源打开 Nginx 压缩和缓存，减少带宽开销。
- API 层加请求频率限制，避免某些接口被恶意刷。
- Redis 缓存注意过期策略和内存上限，尤其时间跟踪、仪表盘统计这类热数据。
- PostgreSQL 定期执行
VACUUM和索引重建，避免长时间运行后查询变慢。
我之前在测试环境跑一个月后，发现仪表盘统计接口越来越慢，后来定位到是历史数据太多且没有合适索引。给关键表的查询字段补上索引后，响应时间从四五秒降到了几百毫秒。如果你的业务表数据量增长很快，建议一开始就在设计阶段考虑索引，而不是等慢了再补。
6. 使用体会与后续扩展思路
6.1 最值得学习的地方
ever-gauzy 对我个人来说，最大的价值不是“能直接换成 B 端产品”，而是一个全栈业务系统的完整范本。你想知道一个包含财务、CRM、项目、人力的系统，模块边界怎么划，数据结构怎么设计，权限怎么控制，前后端类型怎么共享，看这个项目就够了。即使你不打算用它，也能从它的 monorepo 结构里学到很多组织代码的技巧。
尤其是“共享类型定义”这一点，值得所有做全栈项目的团队参考。后端实体、前端表单、接口返回数据，都拿同一套 TypeScript 接口约束，开发时基本不会出现“后端改了字段，前端还在用旧字段”的断链问题。它虽然不是独门绝技，但在一个大型开源项目里能坚持做到，已经非常不容易。
6.2 什么场景最适合用 ever-gauzy
经过一段时间的试跑，我认为它最适合三类团队：
- 服务型、项目制的中小公司，例如咨询团队、外包公司、互联网创业团队，既需要管项目工时，又需要按项目核算成本和收入。
- 需要把 CRM 和财务打通的团队，例如从线索到报价、订单、交付、开票、回款这条路走得很完整的企业。
- 有开发能力、愿意二次开源的团队，而不是完全不懂技术、只想买 SaaS 就能跑的用户。
反过来，如果你需要的只是一本简单账本、一个销售跟进表格，或很复杂的生产制造 ERP，那建议还是用更专门的工具。ever-gauzy 的能力范围不是无限大，但对准了中小公司的核心经营场景。
6.3 后续还能怎么扩展
最后说点扩展方向。ever-gauzy 是开源项目，自定制的可能性很高。如果你想让它更贴合自己的业务，可以从这几个方向入手：
- 接入自己的支付网关和银行流水导出格式，把财务闭环做完整。
- 增加更多项目模板和自动化规则，让新项目立项时自动生成任务清单和预算。
- 做更细粒度的报表，比如按客户、按项目、按销售人员的多维盈利分析。
- 集成企业微信、钉钉或飞书通知，把审批消息推到员工日常聊天工具里。
如果你不打算自己改代码，也可以关注官方社区的插件和更新，版本迭代后常常会补上不少新模块。从 GitHub 的活跃程度来看，这个项目还在快速发展，如果你看中了它但发现某些细节还不完善，保持关注是值得的。
我自己现在把 ever-gauzy 当做一个“业务系统底座”来研究，遇到新的客户需求，会先想想里面的数据模型能不能支撑，再决定是直接配置还是扩展开发。对开源项目来说，能稳定跑起来只是起点，真正好用不好用，还得看它能不能在你的业务里活下来。
