1. Ever Gauzy 是什么一个被很多人低估的开源 ERP 方案第一次看到 ever-gauzy 这个项目名很多人的第一反应是搜索一下然后发现它其实是一个功能完整的企业资源计划ERP系统。我最初是在 GitHub 上刷 TypeScript 相关的高星项目时注意到它的当时随手点进去发现这个项目的模块完整度远超我的预期——销售、采购、库存、财务、人力资源、项目管理、客户关系管理甚至还有桌面端应用几乎把一个小型公司需要的数字化管理工具全部涵盖了一遍。很多初次接触的朋友会把它理解成又一个开源的进销存系统但实际上 Ever Gauzy 的定位要高不少。它由 Ever 团队开发和维护这个团队在开源商业软件领域深耕多年旗下还有 Ever Demand需求预测、Ever Bid招投标管理等一系列产品。Ever Gauzy 更像是这些业务模块的底座它本身就是一个可独立部署、可二次开发、可接入第三方服务的完整企业管理平台。从项目本身的活跃度来看Ever Gauzy 在 GitHub 上的维护节奏相当稳定文档、示例、社区讨论都比较完善。对于正在选型的中小企业 IT 负责人、准备学习 ERP 系统架构的后端开发者、或者想找一个真实业务场景来做毕业设计的在校学生这个项目都值得花时间研究。它不是一个玩具项目而是一个真正能在生产环境里跑起来的开源系统。我后来在本地完整部署过一遍也看了它的核心源码结构这篇文章就把我对 Ever Gauzy 的理解、部署过程中的实操经验、以及它在技术选型上的关键逻辑整理出来。提示这篇文章基于我在实际部署和使用 Ever Gauzy 过程中的经验总结。不同时期版本的依赖、配置方式可能有细微差异建议以官方文档和当前 Release 版本为准。2. 核心业务模块逐项拆解它到底能帮企业管什么Ever Gauzy 的模块边界非常清晰这也是我推荐大家在深入代码之前先理清的部分。它不是一个大杂烩式的管理系统每个模块都有自己明确的数据模型和业务流程。2.1 财务管理模块财务模块是整个系统的核心底座。它不只是简单的记账而是把发票、收款、账单、付款、税务、多币种汇率都串联在一条完整链路上。销售订单审核通过后可以自动生成发票发票核销后自动关联到收入确认采购订单走得是另一条逻辑链最终汇入应付账款。比较实用的是它内置了多币种支持。对于有跨境业务的企业不同订单以不同币种结算时系统会按照配置的汇率表自动折算财务报表里也能按本位币统一查看。税务方面支持常见的税种配置比如美国的销售税、欧洲的增值税不同国家和地区的税率规则可以通过配置中心灵活设置。2.2 销售与采购管理销售端的核心对象是报价单和销售订单。我比较欣赏的一点是Ever Gauzy 保留了先报价、再转订单的完整流程而不是把两者混为一谈。业务人员先基于产品目录和客户历史价格生成报价单客户确认后再一键转化为销售订单。价格表可以按客户等级设置多个版本系统自动匹配适用价格这在实际业务里非常实用。采购端则提供了供应商管理和采购订单管理采购入库后会自动联动库存模块库存数量实时更新。同时系统还支持对采购订单进行收货验证避免供应商发货数量与订单不一致时数据错乱。2.3 库存与制造管理库存模块支持多仓库、多货位管理每个仓库和货位都有独立的库存数量。系统提供了库存调拨、盘点、库存预警等功能对于库存周转比较敏感的电商和贸易企业来说这些功能基本覆盖了日常需求。制造管理模块则有点超出进销存的范畴了。它支持简单和装配型的 Bill of MaterialsBOM物料清单管理生产任务下达后系统根据 BOM 自动计算原材料需求量生产完成后自动入库成品并扣除原材料库存。如果你只是想管理简单的组装工序这个模块完全够用但如果是复杂的多工序生产执行还是需要专业的 MES 系统来配合毕竟 ERP 里的制造模块核心是物料核算而不是工位级执行。2.4 人力资源与薪资管理这个模块对中小企业来说非常加分。员工档案、考勤排班、请假审批、工资项配置、工资单生成这些功能都内置在系统里。工资项支持自定义公式比如按计件工资、加班工时、固定补贴等不同方式组合计算系统最终生成工资单后可以导出。虽然不能替代专业的人力资源系统比如复杂的绩效管理和培训管理但日常的薪资核算和考勤管理已经够用。2.5 项目管理与客户关系管理项目管理和 CRM 模块的存在让 Ever Gauzy 更接近一个全链路管理平台。销售阶段可以跟踪潜在客户、商机、合同签单后的交付过程挂到项目管理模块下项目任务、工时、里程碑、费用报销、项目计费都有对应功能。工时数据还能回写财务模块用于按工时计算项目成本和应收费用。这种从销售线索到项目交付到财务核算的全链路打通是很多单体进销存产品做不到的。3. 技术栈与架构设计为什么值得仔细看我最初关注 Ever Gauzy 的一个重要原因是它的技术选型。它几乎把当前 TypeScript 生态的主流框架和工具都用上了而且用得相当规范对于想学习大型项目架构的开发者来说这就是一份现成的优秀范例。3.1 后端NestJS TypeScript PostgreSQL后端基于 NestJS 框架构建这是目前 Node.js 生态里最接近企业级工程规范的框架之一。依赖注入、模块化开发、装饰器驱动的路由定义这些特性让整个后端的代码结构非常清晰。数据库使用 PostgreSQL同时配合 TypeORM 做对象关系映射。PostgreSQL 的事务能力、外键约束和 JSONB 字段为复杂业务数据提供了可靠支撑。3.2 前端Angular NgRx 管理后台管理后台的前端用的是 Angular状态管理采用 NgRx。选择 Angular 而不是 React 或 Vue说实话在社区里争议不小。Angular 的学习曲线相对陡峭模板语法、依赖注入、模块体系都需要时间消化但它的工程化程度非常高大型后台管理系统里组件之间的状态管理、路由懒加载、表单校验这些通用需求Angular 都提供了统一的官方方案。NgRx 的状态管理严格遵循单向数据流action、reducer、selector、effect 层层解耦。在实际开发中这种架构带来的好处是状态变化可追踪、可回放排查问题时能精确定位是哪个 action 触发了数据变更。3.3 桌面端Electron 封装与本地优先Ever Gauzy 还提供基于 Electron 的桌面端应用。桌面端的价值在于它可以充分利用本地计算资源做数据聚合和处理某些报表渲染、数据导入导出、甚至离线模式操作在桌面端会比纯浏览器体验好一些。3.4 双版本分支Gauzy Platform 与 Gauzy Desktop项目实际上分为两个主要仓库。Ever Gauzy Platform是核心后端和 Web 前端主体Ever Gauzy Desktop是桌面应用壳子。两者通过本地端口通信桌面端内部封装了完整的后端服务。部署时如果你只需要 Web 端拉取 Platform 仓库就够了如果需要桌面应用则需要同时处理 Desktop 仓库的依赖和构建。3.5 技术选型背后的逻辑这套技术栈放在一起体现了几个核心决策思路。统一的 TypeScript 语言栈意味着前端、后端、桌面端可以共享类型定义接口字段变更时前后端能够同步感知NestJS 的模块化和 Angular 的依赖注入一脉相承降低了上下文切换成本PostgreSQL 的强一致性和事务能力保证了财务、库存这类数据的准确性。如果你的团队本身就是 TypeScript 技术栈想引入一套 ERPEver Gauzy 的学习和二次开发成本会比 Java 系或 Python 系的 ERP 低很多。4. 从零跑通本地部署完整步骤与避坑要点如果你打算把 Ever Gauzy 部署起来实际体验下面的流程是我踩了不少坑之后整理出来的可以直接照着操作。4.1 环境准备部署前需要确认本机安装以下软件依赖版本要求说明Node.js18.x 或 20.x LTS建议用 nvm 管理版本避免全局版本冲突PostgreSQL12.0 及以上需要支持 pgcrypto 扩展Yarn1.22.x项目使用 classic 版本Yarn 2 可能遇到 workspace 兼容问题Redis可选生产环境建议安装本地调试可绕过Docker可选官方提供 docker-compose 配置适合快速启动基础设施版本这块特别提醒一下Node.js 版本一定不要超过 20.x 的范围。我有一次在 Node 22 环境下安装依赖遇到 node-gyp 编译原生模块直接报错降回 20 LTS 后一切正常。4.2 获取代码并安装依赖git clone https://github.com/ever-co/ever-gauzy.git cd ever-gauzy yarn install这一步耗时较长依赖体积比较大建议确保网络稳定。如果你的网络环境访问 GitHub 或者 npm registry 比较慢可以配置相关镜像源否则很容易在中途出现超时或者包下载不完整的问题。安装完成后需要配置环境变量。项目根目录下有.env.example文件复制一份为.envcp .env.example .env然后编辑.env重点修改数据库连接信息DB_HOSTlocalhost DB_PORT5432 DB_USERpostgres DB_PASSyour_password DB_NAMEevergauzy4.3 创建数据库并初始化进入 PostgreSQL 命令行创建数据库CREATE DATABASE evergauzy;然后回到项目目录执行数据库迁移和种子数据填充yarn build yarn seed这个步骤是整个部署过程中最容易出问题的环节。yarn seed需要执行数据库迁移、写入基础配置数据、创建演示账号、导入示例业务数据整个过程耗时较长有时看起来像是卡住了但实际上还在运行。我第一次执行时以为进程挂掉了直接 CtrlC 中断结果第二次运行时遇到了重复数据冲突。正确做法是耐心等待命令执行完毕同时观察终端输出日志。如果中途真的报错可以清理数据库后重新执行yarn seed:reinitialize该命令会重置数据库状态并重新初始化种子数据比手动删表省事很多。4.4 启动服务各模块构建好之后可以分端口启动yarn start:api yarn start:webAPI 服务默认运行在http://localhost:3000Web 管理后台默认运行在http://localhost:4200。浏览器打开后台地址使用种子数据中的管理员账号登录默认账号密码通常在项目文档或.env配置文件中有标注。4.5 配置第三方服务如果只是体验功能不需要配置支付和邮件服务。但如果要模拟真实的业务闭环比如生成发票后发送邮件给客户、或者接入 Stripe 收款就需要在.env里配置对应的 API Key。建议第一次部署时不配置这些先把核心模块跑通之后再逐步接入。5. 与主流开源 ERP 横向对比什么场景下选 Ever Gauzy很多人看到 Ever Gauzy 的第一反应是拿它和 Odoo、ERPNext 这些老牌开源 ERP 对比。我在部署之前也做了比较详细的调研这里直接说结论。对比维度Ever GauzyOdooERPNext技术栈TypeScript / NestJS / AngularPython / Django / PostgreSQLPython / Frappe / MariaDB二次开发门槛中TypeScript 生态友好较高Python 框架体系复杂中低Frappe 框架高层封装多界面体验现代化组件化程度高传统功能强大但界面略旧简洁但定制深度有限社区规模中等增长中庞大商业生态成熟较大社区活跃本土化适配需自行开发有本地化模块需商业版支持社区有中文语言包制造模块支持简单装配和 BOM强大支持完整 MRP基础制造管理从上面这个对比能看出各自的定位。Odoo 更像一个庞大的操作系统它从官网到应用商店、从社区到认证合作伙伴已经形成了非常完整的商业闭环适合预算充裕、需要持续定制和生态支持的企业。ERPNext 胜在轻量、开箱即用对于没有专职 IT 团队的小微企业来说它的学习成本最低。Ever Gauzy 的核心竞争力在于两点。第一TypeScript 全栈技术栈的统一性。如果你的开发团队以 JavaScript/TypeScript 为主维护和二次开发 Ever Gauzy 的体验远好于去啃 Python 或 Java 的代码。第二业务模块的紧凑整合。它不像 Odoo 那样把每一个业务子模块都拆成独立的应用而是更聚合这对于业务复杂度和定制需求都适中的企业来说反而更容易理解和维护。6. 实操经验手记扩容、排障、定制这几个关键点实际使用 Ever Gauzy 的过程中有一些比较隐蔽的坑和相对冷门的操作技巧值得单独拿出来说。6.1 API 产能验证可选项有一个细节值得单独说Ever Gauzy 的 API 一般跑在 3000 端口接口响应数据结构和前端组件的字段映射非常紧密。如果你计划对前端做深度定制最好基于官方 API 文档来调整数据结构不要直接改前端组件里的字段名去适配接口否则升级版本时会非常痛苦。6.2 前端构建内存溢出的处理前端项目体积较大执行 Angular 生产环境构建时默认 Node.js 内存限制经常不够用会报JavaScript heap out of memory错误。解决办法是临时提高 Node.js 的堆内存上限NODE_OPTIONS--max_old_space_size4096 yarn build:web另外开发环境的热更新有时候会失效特别是修改了 NgRx store 相关的文件后页面可能没有自动刷新。这时手动刷新浏览器基本能解决如果还不行大概率是开发服务器本身出问题了重启yarn start:web即可。6.3 新需求扩展的常规套路如果需要给系统增加新的业务字段或者模块官方推荐的方式是尽量不动核心代码而是利用它提供的插件机制。具体做法是在apps/api/src/app/下按照现有模块结构添加自定义模块定义独立的实体类并注册到 TypeORM 的数据源配置中。如果只是给已有表增加字段优先考虑利用前端界面里的自定义字段功能比如针对客户、合同、产品等对象添加自定义属性这样既不需要改表结构也不需要改后端代码。不过要注意一点自定义字段功能目前只覆盖了部分核心实体比如联系人、商机、项目等如果要在订单明细行级别加字段还是得走代码层面去改。6.4 性能层面容易忽略的一个点数据量大了之后多表联查的复杂报表可能会变慢。这时候优先检查是否有合适的数据库索引。Ever Gauzy 的迁移文件里给核心外键字段都建了索引但如果你通过插件机制引入了新的查询字段建议在建表时同步建立索引否则查询性能会随着数据量增长迅速劣化。7. 一次性理清二次开发的核心路径最后聊一下二次开发的整体路径。这一步对于真正准备基于 Ever Gauzy 做项目的团队来说比单独任何一个模块都重要。拿到完整代码仓库后建议按以下顺序走通从需求到上线的过程。先在后端新增或调整实体定义并编写数据库迁移文件然后创建对应的 Service 和 Controller把 API 接口提供出来前端如果是新增页面则在对应的路由模块和菜单配置里注册新页面关联后端的 API 数据源如果只是增强已有页面则聚焦 NgRx store 的状态变更和数据流即可。开发调试时要利用好种子数据。在修改了后端实体关系的情况下直接跑yarn seed可能会因数据不一致而报错这时可以执行yarn seed:reinitialize重新初始化。部署到服务器时常见的做法是使用yarn build构建全部产物然后借助 PM2 或 Docker 将 API 和 Web 服务分别启动PostgreSQL 摆在独立的数据库服务器里并通过 Nginx 做反向代理和 HTTPS 终止。这套部署架构在中小企业里非常典型也足够稳定。我个人的总结是Ever Gauzy 比较适合三类人一类是想在真实项目里应用 TypeScript 全栈技术的中高级开发者你可以通过阅读源码学到大型业务系统的架构组织方式一类是正在挑选 ERP 系统、希望拿到源码自己掌控数据的公司这类公司往往不想被商业软件绑定还有一类是院校或培训机构的教学案例它的模块完整度和工程规范程度都远高于大多数 Demo 项目。部署过程中踩过坑、把模块结构理清楚之后我对这个项目的整体评价是它在开箱即用和可深度定制之间找到了一个比较合理的平衡点。没有哪个 ERP 是万能的但 Ever Gauzy 至少给了你一个透明度足够高、技术栈足够现代、扩展路径足够清晰的起点。如果你正准备启动一个企业管理系统的项目不妨先把它跑起来体验一下全链路业务闭环到底是什么感觉。