去年年底团队做内部工具选型时我无意中翻到了 Ever Gauzy 这个开源项目。老实说第一眼看到这个名字我以为是某个做硬件或者物联网的仓库点进去才发现是一套相当完整的开源 ERP/CRM 系统。它的定位很有意思——不是那种给几百人上千人大厂用的重型 SaaS而是专门面向中小团队、创业公司、自由职业者的一套经营管理全家桶。试用了几周、甚至把它接入到我们自己的一个副业项目里跑了一段时间后我对它的评价是这可能是我见过的把“销售、采购、会计、库存、CRM”全部塞进一个开源项目里还能维持工程整洁度最好的几个项目之一。如果你正在为内部管理系统发愁或者想找一个能二次开发的 ERP 底座Ever Gauzy 绝对值得花一个下午认真看一下。这篇文章不打算给你贴官方文档的翻译我想从“一个真正想把 Ever Gauzy 用起来的人”的角度聊聊它的架构逻辑、几个核心模块的实际体验、部署和二次开发里我踩过的坑以及一些文档里不会写的判断。1. 整体设计与技术栈拆解1.1 项目定位给谁用、解决什么问题Ever Gauzy 的全称其实是 Ever Gauzy Platform它解决的问题非常具体一个还在成长中的团队通常买不起也不该去买 Oracle NetSuite 或者 SAP Business One 这种大型 ERP但 Excel 微信群里对订单又已经撑不住了。它恰好切在了这个空档上。它的使用对象大概是这三类初创公司和小型贸易团队需要管理销售订单、采购订单、库存月底还想简单算算账。自由职业者和远程组织按项目管工时、按里程碑算成本时不时需要给客户生成一张像样的报价单。想要做行业定制方案的开发者拿 Ever Gauzy 当底座给特定行业比如餐饮供应链、跨境电商小卖家做二次开发。它解决的核心痛点是“数据孤岛”。销售部门下单、仓库发货、财务开票在很多小公司里是三个完全脱节的流程甚至三套独立的表格。Ever Gauzy 做的事情是把这三套东西打通成一套有完整审计追溯的数据流。这意味着从你创建一个销售订单开始后续的库存扣减、发票生成、应收账款记录全都是自动串起来的而不是各个部门各记各的账。1.2 技术栈选型为什么是 NestJS Angular PostgreSQL这个项目的技术栈非常鲜明后端用 NestJSTypeScript前端用 Angular数据库用 PostgreSQL图表统计用 Charts.js主要靠 Docker 部署。先说 NestJS。它本质上是对 Express 的一层结构化封装强行把模块化、依赖注入、装饰器这些概念引入 Node.js 世界。选择 NestJS 而不是直接用 Express 或者 Koa意味着项目从一开始就在向读者传达一个态度我们想要的是“企业级代码组织方式”而不是“快速写个接口完事”。这对 ERP 这种业务规则复杂、实体关系繁多、多人协作的项目来说是非常重要的基础。再说 Angular 而不是 Vue 或 React。Angular 的模板语法、依赖注入、RxJS 状态管理跟 NestJS 的装饰器和依赖注入风格一脉相承。如果你前后端都自己写你会感觉像在同一个世界观里编程这种“全栈同构”的开发体验确实是 React 项目里很难感受得到的。PostgreSQL 的选择则没什么悬念。ERP 类系统的核心是事务一致性——订单创建、库存扣减、财务记录这三件事必须同时成功或同时失败绝对不能出现“订单创建了但库存没扣”的中间状态。PostgreSQL 在 ACID 事务、复杂查询、JSON 支持上都相当稳定配合 TypeORM 做 ORM 映射开发效率和安全性能兼顾。整个项目的前后端分层逻辑也值得说说apps/api是后端服务apps/web是前端应用packages/contracts存放前后端共享的 DTO 类型定义packages/common放公共工具。这种 monorepo 结构的好处是前端调用后端接口时请求和响应的类型是写死的改了一个字段编译期就能发现哪里没同步省去了前后端反复对齐的时间。2. 核心功能模块解析与实操逻辑2.1 销售与 CRM从线索到回款的一体化流转Ever Gauzy 的销售模块给我的第一感觉是“务实”。它没有堆砌一堆你根本用不上的概念核心链路很清晰客户Customer→ 线索Lead→ 报价Proposal→ 销售订单Sale Order→ 发票Invoice→ 支付Payment。实际操作中我最喜欢的是它的 Proposal 转订单机制。你可以给客户做一份报价里面包含商品、数量、单价、税率、交付日期。当客户确认后这份报价可以直接一键转换为销售订单系统会自动生成待交付的库存任务不需要重新录一遍数据。很多人会忽视这种“状态流转”带来的效率提升但对于每天处理几十个订单的团队来说省掉重复录入就是省掉一大半的出错概率。在客户管理上Ever Gauzy 的做法也比较轻量。它不会像 Salesforce 那样把客户分成五六种层级而是通过标签和自定义字段来适应不同团队的习惯。你完全可以把“客户类型”设置为标签重点客户、一般客户、待开发客户然后按标签筛选看板这个思路对小型团队非常友好。2.2 会计模块没有审计基础也能看懂的管账逻辑说实话一开始我对开源 ERP 的会计模块是没什么期待的大部分开源项目的记账功能都粗糙得没法看。直到我打开了 Ever Gauzy 的会计页面才意识到这个项目比我想象的正规得多。它内置了完整的**复式记账double-entry bookkeeping**逻辑。什么意思呢每一笔经济业务发生后资金或者资产的变动必须同时记录在两个账户中借方和贷方金额相等保证账目始终平衡。这一点对小企业尤其重要因为哪怕你只是从一个银行账户转到另一个账户在账面上都需要有完整的借贷记录月底做资产负债表的时候才说得清楚钱到底去哪了。Ever Gauzy 的会计模块还有一个对非财务专业用户特别友好的点系统会自动生成对应凭证。比如你创建了一张销售发票系统会自动生成“应收账款增加”和“销售收入增加”两张凭证完全不需要手动借贷。这比很多小公司用的 Excel 台账模式要严谨得多也比请代账会计一笔一笔录凭证要快得多。当然它的会计模块相比金蝶、用友这种国内专业财务软件在发票格式、地方税制细节、年报汇算清缴这些方面还是有差距的。我的建议是你可以把它当作内部管理账来用日常开票、记录收入支出、看利润这些都够了如果要报税再让财务根据系统里导出的流水在国内专业财务软件里做调整。这种“双轨”思路对小型团队来说性价比最高。2.3 库存管理不够花哨但够精准的一套逻辑库存模块 Ever Gauzy 采用了一个比较传统的模型仓库Warehouse→ 货架Shelf→ 商品变体Product Variant→ 库存数量Stock Quantity。它支持多仓库每个仓库里可以设定多个货架位置每个商品可以配置多个变体颜色、尺寸、规格每个变体可以单独跟踪库存数量。我试过给一个商品创建 3 种颜色、2 种尺寸共 6 个变体再分别给两个仓库设置不同库存整个过程操作路径非常清晰没有让人摸不着头脑的设计。最值得一提的是库存变动追溯。任意一笔库存调整不管是采购入库、销售出库、库存盘点还是报损系统都会生成一条带有操作人、时间、调节原因的记录。如果你曾经在“账面库存”和“实际库存”对不上的时候疯狂翻聊天记录就会理解这个功能的含金量。3. 快速跑通 Ever Gauzy本地部署与体验3.1 准备工作与环境要求在你动手之前先跟你交个底Ever Gauzy 的本地部署不算一键式体验但也没有到劝退的程度。如果你只是想快速看看界面长什么样选 Docker 方案如果你打算二次开发建议老老实实用源码模式跑起来。准备工作清单如下Node.js 18.x 或更高版本建议用 nvm 管理PostgreSQL 13 及以上需要建好一个空的数据库Redis用于缓存和任务队列某些功能会依赖它Docker可选但强烈建议装因为项目官方提供了完整的 Docker Compose 编排Git以及能够流畅访问 GitHub 的网络环境这里要注意一个细节项目对 Node 版本是有要求的。我最初在 Node 20 下跑遇到了一些兼容性警告切到 Node 18 LTS 后整个构建过程就顺畅多了。如果你在安装依赖时遇到 node-gyp 相关的报错多数情况下就是 Node 版本或者 Python 环境的问题先解决这两个再去折腾别的。3.2 源码方式启动 API 服务和前端我推荐有兴趣做二次开发的朋友走源码路线。整个过程分三步安装依赖、配置环境变量、分别启动后端和前端。第一步克隆仓库并安装依赖git clone https://github.com/ever-co/ever-gauzy.git cd ever-gauzy npm install如果npm install在某个原生模块比如 bcrypt、argon2上报错多半是缺少编译工具链。在 Ubuntu/Debian 上需要build-essential和python3在 macOS 上通常装一下 Xcode Command Line Tools 就能解决。第二步在apps/api/.env里配置数据库连接。核心配置项如下DB_HOSTlocalhost DB_PORT5432 DB_NAMEever_gauzy DB_USERpostgres DB_PASSWORD你的数据库密码 DB_LOGGINGfalse接着执行数据库迁移和初始化npm run migration:run npm run seed:allseed:all会插入一组演示数据包含商品、客户、供应商、订单示例等。我强烈建议你跑一遍这个命令不然登录进去面对空荡荡的后台你是很难理解每个功能是干什么用的。第三步分别启动后端和前端npm run start:api npm run start:web等两个终端都出现“服务已启动”的日志后浏览器访问http://localhost:4200默认超级管理员账号一般为adminever.co/admin以项目 README 中的说明为准登录后就能看到一个完整的 ERP 后台了。源码模式跑起来后前端访问的是 4200 端口后端 API 在 3000 端口。前后端通过环境变量API_BASE_URL通信如果改了端口记得同步修改这个配置。3.3 Docker 方式快速体验如果你只是先试试水不想在自己电脑里装一堆数据库和 RedisDocker Compose 是最省事的方案。docker compose up -d它会自动拉起 PostgreSQL、Redis、API 服务、Web 前端四个容器。过几分钟浏览器访问http://localhost:8080具体端口以项目的 Docker Compose 文件为准就能看到登录页。但有两点提醒你Docker 方式下代码热更新比较麻烦每次改代码都需要重新构建镜像不适合日常开发。如果你在国内网络环境下拉取 Docker 镜像建议配置好镜像加速器否则几个大的镜像可能拉不动。我的习惯是日常二次开发用源码模式给同事或客户演示用 Docker 模式两套互不干扰。4. 二次开发关键点如何让 Ever Gauzy 真正适合你的业务4.1 理解实体关系为什么说它的数据模型是核心资产Ever Gauzy 的实体Entity设计是理解整个系统的钥匙。它的核心关系可以简化成这么几条线客户/供应商是所有业务单据的起点订单、发票、收款、付款都要挂在这些主数据上。订单是业务流转的中枢一头连着客户另一头连着商品和库存。发票和支付是资金流的载体所有财务数据都来源于此。我在看了它的源码后发现几乎所有实体都继承了一个基础类里面包含了createdAt、updatedAt、tenantId等通用字段。这意味着每一张单据都有完整的时间审计和租户隔离对多公司、多团队的场景支持非常友好。如果你要加自己的业务字段比如给订单加一个“快递单号”较规范的做法是在对应实体里增加一个ExpressNumber字段然后同步更新packages/contracts里的 DTO 定义。要注意的是前端 Angular 组件也依赖这些类型所以改了后端后前端如果报类型错误说明前端也需要同步更新。4.2 扩展业务模块从“有”到“好用”的三个常见改造方向根据我这段时间的实际体验Ever Gauzy 最常被二次开发改造的方向大概有三类第一类改造报表逻辑。系统自带的统计报表以图表为主数据口径相对固定。很多团队会希望导出更细粒度的 Excel 报表。这时候你可以在apps/api/src/reports下新增一个 controller 和 service用 QueryBuilder 自己写聚合查询然后通过 exceljs 等库生成报表文件。所有报表数据都从同一个 PostgreSQL 库读取不会出现不同报表数据对不上的问题。第二类打通外部系统。比如你已经有了企业微信、钉钉或自建 OA希望把订单审批结果同步回 Ever Gauzy。这种场景下你可以用 Ever Gauzy 提供的 REST API 写个中间服务监听 webhook 或者定时轮询外部系统然后把状态回写到对应订单。Ever Gauzy 的多租户隔离设计让这种集成非常安全——不同租户的数据空间完全分离就算外部系统配置出错也不至于把数据串到别的客户头上。第三类做一些行业定制。比如你是做设备租赁的订单里需要记录“租期开始时间”和“租期结束时间”并据此自动计算租赁费用。这时候你可以在产品实体上扩展计费单位类型结合订单的自定义字段用一个定时任务或者触发器来实现自动计费。这类深度定制需要的不是修改系统底层逻辑而是理解 Ever Gauzy 的“报价单-订单-发票”流转机制然后在你需要的位置插入自定义逻辑。有一点经验很重要尽量不要直接改动项目的基础实体和核心服务层而是通过新增字段、新增模块的方式去扩展。否则以后项目升级你的代码和上游代码会产生大量冲突merge 起来非常痛苦。5. 常见问题与排查技巧实录5.1 部署和运行阶段的高频报错这段时间我整理了一下自己体验群里大家常遇到的问题几乎都是前几个星期会反复踩的坑这里直接给大家一份速查表现象可能原因处理方法npm install卡住或报 node-gyp 错误缺编译工具链、Python 环境不对安装 build-essential / Xcode CLT确认 Python 可用必要时先npm cache clean --forceAPI 启动后提示数据库连接失败环境变量DB_HOST配置错误或数据库没建好先确认psql能连上数据库再检查.env里的配置项注意端口默认是 5432前端页面能打开但列表接口一直转圈前端 API 地址配置不对或后端没启动检查API_BASE_URL配置确认http://localhost:3000/api在浏览器里能直接访问登录成功但部分菜单空白演示数据没初始化完整重新执行npm run seed:all确认所有种子脚本都已跑完Docker 方式启动后端口冲突本机已有服务占用 8080/3000修改 Docker Compose 中的端口映射尽量避开常见端口5.2 开发调试阶段的独门经验在二次开发过程中有两个调试技巧我特别想分享给你。技巧一打开 TypeORM 的 SQL 日志理解系统行为。TypeORM 支持在运行时打印 SQL 语句你只要把环境变量的DB_LOGGING从false改为true重启 API 服务就能在终端看到每一个 SQL 查询。这在排查“为什么我创建订单后库存数量没变”这种问题时特别有效——你能直接看到系统执行了哪些 UPDATE 语句到底在哪里断掉了。排查看完后记得关掉否则生产环境日志会爆炸。技巧二善用 NestJS 的模块系统改哪里只动哪里。Ever Gauzy 是个非常标准的 NestJS 项目所有功能都拆成了一个个模块。你如果想调整“新建销售订单”这个行为只需要找到apps/api/src/sales目录下的 service 文件在对应方法上加点日志或者调试代码就行完全不涉及全局逻辑。同时NestJS 的依赖注入体系使得你可以很方便地将原有 service 替换成自己实现的版本只要通过模块的providers配置覆盖即可这样也不用破坏原有代码。5.3 性能与数据规模什么时候需要担心很多人在体验 Ever Gauzy 时会担心“开源项目会不会卡”。根据我自己的压力测试体验在单机上跑几千个订单、几百个商品完全不成问题。它的性能瓶颈一般不在代码本身而在数据库索引和前端数渲染方面。如果后续你的订单量到了几十万量级你可以做三件事第一把 API 服务和 PostgreSQL 分开部署各自有独立的硬件资源第二给常用的查询字段加上数据库索引比如invoiceNumber、orderDate第三开启 PostgreSQL 的查询缓存减轻重复查询的压力。实际上对大多数中小团队来说Ever Gauzy 的性能余量远比你担心的充足。真正需要你操心的是业务流程是否理顺了数据录入是否规范。工具永远解决的是流程问题而不是流程本身。6. 对 Ever Gauzy 的总体评价与适用场景6.1 优点与不足的实话实说先说优点。Ever Gauzy 最大的价值在于它提供了一套完整、且数据逻辑自洽的开源 ERP 底座。你在上面做二次开发和你在一个“只有订单表和用户表”的半成品上从零开始完全是两个层级的事情。它已经把多租户、权限体系、审计追溯、财务记账这些非常难做对的事情做好了你只需要把注意力放在自己的业务逻辑上。其次它的技术选型和质量控制比较靠谱。NestJS Angular PostgreSQL 的组合对于 TypeScript 团队来说几乎没有学习成本代码结构清晰命名规范类型定义完整。在开源 ERP 这个领域能把代码写成这个水平的项目其实不多。但也得说说不足。Ever Gauzy 的界面设计属于“能用、但不算出彩”的水平。它更像一套生产力工具而不是一件艺术品。你能明显感觉到开发团队把大部分精力花在了后台的流程和数据模型上前端的视觉设计相对保守。另外它的中文支持有限官方文档和界面默认语言以英文为主虽然能改但需要你自己去补充语言包。还有一点就是它的功能实在太全了。对只想用“进销存”一个模块的团队来说你可能需要花点时间忽略其他模块的存在。这种“全家桶”式的设计带来了使用上的一定学习成本。但换一个角度看这也意味着你不用担心未来某个新需求突然就把系统撑爆了——该有的模块系统里早就有了。6.2 项目活跃度与社区生态开源项目社区活跃度是绕不开的话题。Ever Gauzy 的 GitHub 仓库保持着很高的更新频率这个问题不大。它的 issue 区也非常活跃你遇到的很多问题大概率有人在里面提过搜索一下就能找到解决方案。在扩展生态方面Ever Gauzy 还配套了几个独立项目比如 Ever Demand需求侧管理和 Ever Supply供给侧采购这部分集成也是它未来演进的方向之一。如果你有长期使用的打算关注这几个子项目的动态会对你有帮助。我在实际使用中还有一个体会不要把它当黑盒直接上生产一定要先在测试环境里模拟一遍完整的业务流转。因为 Ever Gauzy 的能力范围远超普通进销存它的很多边界条件是你自己在配置时定义的比如税率的计算方式、订单取消时库存的回补方式等。花一个下午把“开单-发货-开票-收款-退货”整个流程走一遍你对这个系统的理解会跃升一个台阶。最后再分享一个小技巧如果你决定在团队里推广 Ever Gauzy别第一次就给所有人开全部权限。先用管理员账号把角色权限收一收只给销售开订单相关权限让财务的开销、审批能够分区管理这才是 ERP 系统发挥价值的前提。工具本身不会自动让流程变规范但一个规范使用的好工具真的能帮你省下很多月底对账的功夫。