1. Ever Gauzy 到底是什么一个开源平台为什么敢把所有业务模块都塞进去第一次看到 ever-gauzy 这个仓库时我的第一反应是“又一个把自己包装成全能选手的开源项目”。ERP、CRM、HR、会计、库存、项目、时间追踪全都放一起听起来就很像那种什么都能做、什么都做不精的巨无霸。但我认真翻完文档、在本地跑起来之后想法变了它确实不是玩具而是一个能支撑真实业务运转的开源管理系统尤其适合那种已经受够了多个 SaaS 来回切换、想数据打通的中小团队。如果你正在找一套能替代零散工具的开源业务系统Ever Gauzy 值得你花一个周末去了解。它解决的核心问题是把一家成长型公司的销售、采购、库存、财务、员工管理和项目执行放在同一个平台里避免“客户数据在 CRM、账目在 Excel、工时在另一个软件”这种割裂状态。对独立开发者、十到两百人左右的小企业、远程团队来说它的价值会非常明显。不过它也不是没有门槛。想跑起来容易想用好用透需要对业务建模、权限体系、数据流转都有一些理解。这篇文章我会从项目背景、功能模块、技术架构、部署实操到选型建议把我实际试用中的经验和踩过的坑完整记录一遍。1.1 从 Gauzy 到 Ever Gauzy名字背后的项目脉络Ever Gauzy 不是凭空冒出来的项目。它最早是 Ever 团队为自家电商操作系统“Ever Demand”配套的企业资源管理底座后来拆出来独立开源托管在 GitHub 的 ever-co/ever-gauzy。Gauzy 这个词在英语里有“薄纱、轻雾”的意思放在 ERP 语境下多少暗示这套系统希望做的是“让企业运转更轻盈透明”。项目经历了从早期的 Angular 单页应用 NestJS 后端到后来逐步演进成包含后端 API、前端工作台、桌面应用、移动端能力在内的多应用仓库。核心代码以 TypeScript 为主后端基于 Node.js 生态前端主要用 Angular。整体风格偏向传统企业级应用而不是那种追求极简交互的轻量工具所以刚登录进去会感觉信息密度很大需要一点适应时间。另一个值得注意的点是它的授权方式。主开源仓库走的是 AGPL 类许可证同时 Ever 团队提供云托管版本和企业定制授权。简单说你可以在自己的服务器上免费部署使用也可以付费买托管和商业支持。对中小企业来说自托管版本已经能覆盖绝大多数场景对需要定制开发的公司双轨模式也留出了商业合作的余地。1.2 它不是“开源版 Odoo”这么简单很多人会把 Ever Gauzy 和 Odoo、ERPNext 放到一起比较这个方向是对的但它和这两者有明显差异。Odoo 的长处在模块化市场你可以像装 App 一样按需启用功能ERPNext 则更强调全套流程的完整性和数据一致性。Ever Gauzy 的位置更像是一个“业务中台”它把组织、用户、权限、租户这些基础能力做得非常扎实然后在这个底座上叠加财务、人力、库存、项目等模块。这意味着如果你只是想找一个“开箱即用”的轻量进销存Ever Gauzy 可能会显得重但如果你需要一套可编程、可定制、数据边界清晰的企业管理系统它的架构优势就体现出来了。整个系统围绕“组织”和“员工”两个核心实体展开几乎所有业务单据都会关联到这两个对象这样后续做财务分析、绩效统计时数据天然是贯通的。我第一次跑通后创建了一个测试组织加了几个假员工录入一笔库存采购再生成一张发票全程没有离开系统这个连贯性是很多单一功能工具给不了的。1.3 它到底适合谁用先把结论放在这里后面章节再展开细节。我觉得它最适合三类团队第一类是远程团队或自由职业者联盟需要把工时、项目、客户账单串起来第二类是跨境电商和对账要求高的小型贸易公司因为它的多币种、多仓库和税务处理能力很实用第三类是想要“自己掌控数据、未来可能需要定制”的技术型创业团队因为它的 API 完整度较高二次开发成本可控。相反如果你的业务非常简单只卖几种固定商品一个月开不了几次发票那用一张表格加上一个收银工具可能更快没必要上 ERP。选型这件事适合自己的才最好。2. 功能模块拆解从会计到考勤哪些模块真正值得用Ever Gauzy 的功能覆盖面相当广。官方把它称为“开源的业务管理套件”但我更愿意把它拆成几个彼此独立又可协作的模块来理解。这样评估的时候才不会迷路也能更清楚地判断哪些模块对你的业务真正有价值。2.1 财务会计不只是记账而是把业务单据变成财务数据Ever Gauzy 的财务模块给我留下很深印象。它不是那种只能录入收入支出流水的基础记账工具而是带上了复式记账特征的业务型财务系统。系统支持发票、账单、付款记录、税务报告、试算平衡表等能力并且能直接从销售订单、项目工时表、采购订单生成对应的财务单据。举个例子你给客户做项目报价报价审批通过后生成发票发票关联到项目上的实际工时和材料成本结款后系统自动形成一笔收款记录。整个过程从业务流程自然流到账务不需要像传统做法那样业务系统一套数据、财务软件再重新录一遍。在税务处理上它支持多税率设置可以按产品、服务或客户类别配置税码。对于需要按季度报税的公司来说这种数据准备能力能省下大量体力活。多币种支持也做进去了应收账款、应付账款都能看到原始币种和本位币的对照。2.2 人力资源与考勤远程团队会很喜欢这一块如果你带过远程团队一定懂考勤和工时统计的痛。成员分布在多个时区用视频会议软件沟通到底谁今天看了多少小时代码月底怎么算工资很容易扯皮。Ever Gauzy 的 HR 模块正好覆盖这些场景。系统里可以维护员工档案、职位、合同类型、薪资信息还能设置请假类型和审批流。考勤方式支持手动打卡、地理围栏打卡以及后台自动记录虽然不能做到像专业打卡软件那样精细但足够支撑“员工今天是否上班、是不是在约定地点”这类日常管理需求。比考勤更重要的是工时追踪。Ever Gauzy 提供桌面应用和浏览器辅助工具能记录员工在不同网站和应用上花的时间并区分生产性和非生产性活动。很多聪明的团队把这个功能当“项目成本核算器”而不是“监控器”员工把时间记到具体项目上月底系统自动算出每个项目的人工成本利润率一目了然。我建议你把它定位成“成本数据来源”而不是“纪律监控工具”。一旦团队文化不匹配任何时间追踪功能都会引发抵触情绪。2.3 CRM 与销售流程该有的都有但不算最出彩Ever Gauzy 的 CRM 模块包含联系人管理、客户档案、商机管理、销售漏斗和活动历史。你可以把线索慢慢培养成商机再关联到报价单、销售订单最后变成发票。它和财务、库存、项目的联动是最大卖点这一点是很多独立 CRM 工具做不到的。如果你已经深度使用 HubSpot、Pipedrive 这类专业 CRM会明显感觉 Ever Gauzy 在销售自动化、邮件追踪、模板丰富度上还有差距。所以我的观点是销售流程相对简单的团队完全可以直接用它的 CRM省一个订阅费而销售周期复杂、重度依赖自动化触发的团队可能还是需要专业 CRM然后通过 API 和 Ever Gauzy 做数据同步。2.4 库存与采购商品、仓库、订单的闭环库存模块支持产品档案、多单位换算、商品变体、仓库/门店多地点、库存调整、盘点、采购订单和销售订单。比较实用的是库存变动有记录能看到每一笔出入库的来源和去向做审计时心里有底。最让我喜欢的是销售订单和库存的联动方式创建销售订单后可以基于订单生成出库单系统自动扣减对应仓库的可用库存采购到货后也可以通过入库单自动增加库存。如果你经营的是实物商品业务这个闭环能帮你免去每天手工核对“库存表到底准不准”的焦虑。多仓库支持也做得比较细每个仓库可以设置独立地址和负责人调拨单能追踪商品从一个仓库流转到另一个仓库的全过程。对在多个平台上开店、有线上仓和线下仓的卖家来说这是硬需求。2.5 项目与时间追踪很多人是冲着这个来的如果让我给 Ever Gauzy 的模块排个名项目管理和时间追踪一定排第一。它支持任务看板、甘特图、里程碑、任务依赖关系还能把每个任务关联到项目和具体成员。配合时间追踪功能每个任务上都能看到实际工时、预估工时和超时偏差非常直观。这里有一个很有价值的场景给客户报固定价项目前先查一下同类历史任务的平均工时报价就不容易拍脑袋。项目执行中每周看一眼任务燃尽情况和人工成本累计能提前发现项目是不是要亏。这些能力在专业工具里往往是要单独付费的Ever Gauzy 把它们打包在一起确实有性价比。模块主要能力我眼里最亮眼的点财务发票、账单、税务、多币种、复式记账业务单据自动转财务凭证HR员工档案、合同、考勤、请假、报销工时和薪资数据可追溯CRM联系人、商机、销售漏斗、报价商机转报价再转发票的连贯流程库存产品、变体、仓库、调拨、盘点销售/采购订单自动增减库存项目看板、甘特图、里程碑、工单工时与项目成本实时统计3. 技术底座与部署方式NestJS、Angular 和 Docker 背后的设计逻辑聊完功能再看技术。Ever Gauzy 的技术选型决定了它的可二次开发程度和部署方式。如果你是开发人员或者团队里有技术负责人这一章值得细看。3.1 后端架构为什么选 NestJS 而不是其他框架Ever Gauzy 的后端基于 NestJS这是 Node.js 生态里一个相当成熟的企业级框架。它最大的特点是把模块化、依赖注入、装饰器和 TypeScript 的类型系统结合得很好写出来的代码结构非常清晰这对一个功能横跨财务、HR、库存的庞然大物来说至关重要。正因为是 NestJS所以项目里的业务模块都遵循类似的 CRUD 模式Controller 处理路由Service 处理业务逻辑Entity 映射数据库表Repository 负责数据访问。如果你接手的同事之前写过 NestJS上手这个仓库会快得多。数据库层使用了 TypeORM这在关系型数据管理、数据迁移、多数据库支持上非常方便。生产环境官方推荐 PostgreSQL开发环境也可以跑 SQLite。我强烈建议从一开始就用 PostgreSQL因为很多高级查询、事务处理和并发场景在 SQLite 下表现并不一样别等到数据量上来才换库。3.2 多组织与权限模型SaaS 化设计的内核我特别喜欢 Ever Gauzy 的“租户Tenant—组织Organization—用户User—员工Employee”这套数据模型。最外层是租户一个租户下可以创建多个组织组织之间数据隔离组织下管用户和员工员工可以归属于多个组织角色权限可以精细到功能级别。这种设计意味着哪怕你只给一家公司用也能方便地划分事业部、分子公司、项目组如果你未来想做成 SaaS 平台让多个客户共用一套部署那更是原生支持。我第一次看代码时许多实体上都有organizationId和tenantId字段这种从一开始就考虑数据隔离的做法确实能给后续扩展省很多事。权限方面系统提供了超管、管理员、员工等基础角色也支持在界面里自定义角色并勾选权限点。对大型团队你可以把权限设计到“谁看报表、谁审发票、谁改库存”这种粒度避免了“一人全权”的失控风险。3.3 部署方式Docker Compose、传统安装和云环境如果只是为了体验最直接的方式是用 Docker Compose 在本地把整套服务拉起来。仓库里提供了环境变量模板和容器编排文件后端 API、前端工作台、数据库以及 Redis 都可以一键启动。这么做的好处是不用在你本机装一堆 Node 和数据库环境干净省事。大致流程如下git clone https://github.com/ever-co/ever-gauzy.git cd ever-gauzy cp .env.example .env # 根据需要修改数据库、Redis、端口等配置 docker compose up -d等容器状态都变成 healthy浏览器打开前端地址再按照初始化引导创建管理员账号就能进入系统了。需要注意的是我遇到过容器之间端口没有在环境变量里对齐导致的连接问题所以启动前最好先看一眼.env里API_PORT、DB_PORT、REDIS_PORT等参数是不是和 docker-compose 文件里暴露的端口一致。生产环境部署其实也就是把同一套 Docker 镜像推到自己的服务器或云平台前端静态资源托管后端 API 服务化数据库用云数据库再加一层反向代理就能跑起来。如果团队规模很小也可以直接用官方云服务省去运维成本。3.4 开发模式启动开发者如果想改代码推荐用开发模式启动。项目用 npm 或 yarn 管理根目录下会有针对不同应用的脚本。通常需要先安装依赖再分别启动后端和前端服务yarn install cp .env.example .env # 启动后端 API yarn start:api # 另开终端启动前端工作台 yarn start:gauzy开发模式下前后端都会开启热更新改完代码浏览器自动刷新调试体验比较友好。但注意开发模式对内存要求不低Node 进程同时跑后端和 Angular 应用建议电脑内存至少 8G最好 16G。3.5 扩容思路异步任务与文件存储的取舍Ever Gauzy 用了 Redis 和队列来处理异步任务比如邮件发送、大量数据导入导出、定时任务等。这种设计在生产环境很实用可以把耗时操作从请求链路里剥离开避免用户点一个按钮就卡住。不过也意味着技术栈里又多了一个 Redis 依赖运维时需要一并考虑。文件存储方面系统默认支持本地文件方案也接入了 S3 这类对象存储的接口。如果以后要部署到云上建议从开始就配置对象存储否则将来迁移历史文件会非常痛苦。我个人的经验是ERP 这类系统里附件很碎片化发票 PDF、产品图片、员工合同、聊天文件混在一起存储方案一定要在一开始就定清楚。4. 本地跑通 Ever Gauzy完整上手指南与常见坑理论讲完进入实操。我想尽量把从零到一的过程写清楚特别是那些文档里没细说、但实际一定会遇到的坎。4.1 环境准备无论你用 Docker 还是源代码启动都需要先准备环境Git用来克隆仓库Docker 和 Docker Compose推荐省去手动装依赖如果走开发模式需要 Node.js 18 以上版本、包管理器npm 或 yarn浏览器建议用 Chrome 或 Edge对 Angular 应用的兼容性最好不需要预先装 PostgreSQL 和 Redis因为 Docker Compose 会帮你搞定。4.2 数据库连接和初始数据启动前最容易被忽略的是数据库配置。.env文件里涉及数据库、Redis、JWT 密钥、邮件服务等一堆变量。新手第一跑很多参数不需要改但至少要确保数据库连接信息能对上并且JWT_SECRET这种密钥不是留空的否则登录状态会出问题。Ever Gauzy 支持在启动过程中自动建表也会通过种子数据覆盖一些基础字典数据比如时区、语言、常用权限点。跑完初始化后你登录系统看到的并不算一个“空数据库”而是带了一套可参考的默认配置这反而比白板状态更容易上手。提示如果你多次删除数据库表重新初始化一定要把 Redis 里的旧缓存也清掉否则常看到数据已经改了前端界面却还是老样子。4.3 初始化配置先建组织再谈其他场景登录进系统后第一步不要急着录商品开发票而是先把“组织”建好。几乎所有业务数据都挂在组织下面组织信息建不清楚后面到处都会有连带问题。需要重点设置几类信息组织名称、所属国家/地区、默认货币、时区、工作周设置、是否启用多仓库、是否启用多币种。这些字段在创建后虽然也能改但影响历史单据的规范化程度所以第一次尽量想清楚。第二步是邀请或创建员工账号。只有把账号关联为员工才能分配工时、下达任务、走报销。这里容易疑惑的点是一个账号既是系统登录用户又要在某个组织里被“雇佣”不是建个用户就完事还要在组织里维护雇佣关系。第三步才是配置产品、仓库、客户、供应商这些基础档案。做完这三步系统才算真正可以用。4.4 跑一条完整业务流感受一下我建议第一次测试时完整走一条销售闭环而不是东点一下西点一下。比如这样新建一个客户档案录入一款产品设置好售价和税率创建销售订单把产品加进去订单中直接生成出库单系统扣减库存基于订单生成发票记录客户付款完成一张销售单的全生命周期接着再走一条采购闭环新建供应商、创建采购单、收到货后生成入库单、匹配供应商账单、完成付款。两条闭环跑完你会对整个系统的数据流转有非常直观的体感之后再去看报表就不会觉得数据是零散的了。4.5 我踩过的三个典型问题这个仓库值得给高评价但也不是完全没有脾气。我实际碰到的问题主要有三个。第一个是首次启动时前端一直显示“后端无法连接”。排查了半天根因是.env里的 API 地址写成了 localhost而在 Docker Compose 网络里应该用服务名进行互通。把前端使用的 API 地址改成容器网络内的服务名后问题立刻解决。第二个是导入数据时提示超时。这个问题在长列表、大量员工或产品数据导入时容易出现。后来发现是队列 worker 配置的是单线程数据库连接池偏小。适当加大异步 worker 数量和数据库连接数就能缓解但更务实的做法是数据量大时拆成多个批次每次不要超过几百条。第三个是权限配置太灵活带来的“误伤”。默认角色看似没问题但自定义角色时如果不小心把菜单权限关掉前端可能只隐藏菜单后端 API 却还允许访问反过来也可能出现界面能进、但接口 403。所以权限调整后最好用不同角色账号实测一遍不要凭感觉。5. 适用场景与选型建议什么时候选 Ever Gauzy什么时候该放手文章最后我想聊聊决策层面的事。不是每个团队都该选 Ever Gauzy搞清楚边界比盲目上手更重要。5.1 我建议选择它的三种情况第一种是远程团队或混合办公团队核心痛点是“工时看不见、成本算不清”。Ever Gauzy 把项目、任务、工时、发票和薪资数据打通你花在项目上的每一分钟都能转化为客户账单里的金额。我见过一个十人左右的开发团队用它的时间追踪功能做客户月结财务报表从原来的一周压缩到半天效率提升非常明显。第二种是已经开始多平台销售的贸易公司。多仓库、多币种、税务报告、采购与销售闭环这些能力正好能覆盖“线下仓 线上店”的日常操作。尤其是库存和订单自动联动避免了每天手工录库存的重复劳动。第三种是重视数据自主权的技术型公司。Ever Gauzy 开源、API 完整、数据结构清晰你可以把它当成一套业务中台来改造。哪怕只用了它的财务和项目模块未来接电商、接企业微信、接第三方 BI 工具都非常方便。5.2 我建议放弃它的两种情况第一种是超大型企业。集团级审批流、复杂合并报表、多级法人架构、精细化预算控制这些能力在 Ever Gauzy 里还不够成熟强行用会碰得头破血流。它更适合中小规模的单体或分散型组织而不是重型集团。第二种是完全没有任何技术人员的企业。虽然 Docker 部署已经很便利但日常使用中难免碰到性能调优、权限配置、数据异常排查的问题没有懂技术的人兜底一个小问题可能卡住整个业务流程。如果你不想请人维护买官方云服务可能是更稳妥的选择。5.3 平台生态与学习资源Ever Gauzy 的社区和生态正在成长中比起 Odoo 那种庞大的插件市场它目前的扩展更多依赖开发者直接写代码。好处是代码风格统一、核心架构一致坏处是拿来即用的第三方模块不多很多功能需要自己上手实现或等待官方迭代。好在它的代码仓库里有不少示例和测试用例GitHub Discussions 上也能找到问题解答。学习和讨论资料虽然不像成熟商业产品那样铺天盖地但官方文档几乎覆盖了从安装到权限、到 API 的每个环节。只要你愿意读文档大部分问题都能自己解决。5.4 一次有代表性的选型思考过程我有个朋友开了一家 30 人左右的跨境电商公司之前用的是“进销存 A 报销系统 B 项目管理 C 财务软件 D”每个月对账非常痛苦。他在我和推荐下试用 Ever Gauzy 两周最后做了一个很有意思的决定不把旧系统全换掉而是先用 Ever Gauzy 接管“员工工时 项目成本 客户发票”这三块库存和采购继续放在他熟悉的系统里通过 API 做同步。这个方案听起来不够“彻底”但非常务实。它说明 Ever Gauzy 的价值不一定来自“取代一切”也可以来自“把最难打通的数据缝隙补起来”。选型从来不是非黑即白的判断题而是基于成本和收益的连续决策。最后再说两句大实话东西好不好最终要落到自己的业务上。如果你已经受够了多个系统之间来回搬运数据不妨花一个下午把 ever-gauzy 在本地跑起来创建十个八个个测试数据走一遍订单、发票、工时的完整链路。只有亲手点过一遍你才会清楚它适不适合你而不是只看别人的评测。我个人的经验是这类系统的学习曲线不在操作而在“理解业务建模”。你把“组织、员工、角色、商品、订单”这些概念想清楚了Ever Gauzy 的每一块功能都会变得顺理成章想不清楚所有按钮都只是按钮。拿着这套思路去上手应该能少走很多弯路。 1. Ever Gauzy 到底是什么一个开源平台为什么敢把所有业务模块都塞进去第一次看到 ever-gauzy 这个仓库时我的第一反应是“又一个把自己包装成全能选手的开源项目”。ERP、CRM、HR、会计、库存、项目、时间追踪全都放一起听起来就很像那种什么都能做、什么都做不精的巨无霸。但我认真翻完文档、在本地跑起来之后想法变了它确实不是玩具而是一个能支撑真实业务运转的开源管理系统尤其适合那种已经受够了多个 SaaS 来回切换、想数据打通的中小团队。如果你正在找一套能替代零散工具的开源业务系统Ever Gauzy 值得你花一个周末去了解。它解决的核心问题是把一家成长型公司的销售、采购、库存、财务、员工管理和项目执行放在同一个平台里避免“客户数据在 CRM、账目在 Excel、工时在另一个软件”这种割裂状态。对独立开发者、十到两百人左右的小企业、远程团队来说它的价值会非常明显。不过它也不是没有门槛。想跑起来容易想用好用透需要对业务建模、权限体系、数据流转都有一些理解。这篇文章我会从项目背景、功能模块、技术架构、部署实操到选型建议把我实际试用中的经验和踩过的坑完整记录一遍。1.1 从 Gauzy 到 Ever Gauzy名字背后的项目脉络Ever Gauzy 不是凭空冒出来的项目。它最早是 Ever 团队为自家电商操作系统“Ever Demand”配套的企业资源管理底座后来拆出来独立开源托管在 GitHub 的 ever-co/ever-gauzy。Gauzy 这个词在英语里有“薄纱、轻雾”的意思放在 ERP 语境下多少暗示这套系统希望做的是“让企业运转更轻盈透明”。项目经历了从早期的 Angular 单页应用 NestJS 后端到后来逐步演进成包含后端 API、前端工作台、桌面应用、移动端能力在内的多应用仓库。核心代码以 TypeScript 为主后端基于 Node.js 生态前端主要用 Angular。整体风格偏向传统企业级应用而不是那种追求极简交互的轻量工具所以刚登录进去会感觉信息密度很大需要一点适应时间。另一个值得注意的点是它的授权方式。主开源仓库走的是 AGPL 类许可证同时 Ever 团队提供云托管版本和企业定制授权。简单说你可以在自己的服务器上免费部署使用也可以付费买托管和商业支持。对中小企业来说自托管版本已经能覆盖绝大多数场景对需要定制开发的公司双轨模式也留出了商业合作的余地。1.2 它不是“开源版 Odoo”这么简单很多人会把 Ever Gauzy 和 Odoo、ERPNext 放到一起比较这个方向是对的但它和这两者有明显差异。Odoo 的长处在模块化市场你可以像装 App 一样按需启用功能ERPNext 则更强调全套流程的完整性和数据一致性。Ever Gauzy 的位置更像是一个“业务中台”它把组织、用户、权限、租户这些基础能力做得非常扎实然后在这个底座上叠加财务、人力、库存、项目等模块。这意味着如果你只是想找一个“开箱即用”的轻量进销存Ever Gauzy 可能会显得重但如果你需要一套可编程、可定制、数据边界清晰的企业管理系统它的架构优势就体现出来了。整个系统围绕“组织”和“员工”两个核心实体展开几乎所有业务单据都会关联到这两个对象这样后续做财务分析、绩效统计时数据天然是贯通的。我第一次跑通后创建了一个测试组织加了几个假员工录入一笔库存采购再生成一张发票全程没有离开系统这个连贯性是很多单一功能工具给不了的。1.3 它到底适合谁用先把结论放在这里后面章节再展开细节。我觉得它最适合三类团队第一类是远程团队或自由职业者联盟需要把工时、项目、客户账单串起来第二类是跨境电商和对账要求高的小型贸易公司因为它的多币种、多仓库和税务处理能力很实用第三类是想要“自己掌控数据、未来可能需要定制”的技术型创业团队因为它的 API 完整度较高二次开发成本可控。相反如果你的业务非常简单只卖几种固定商品一个月开不了几次发票那用一张表格加上一个收银工具可能更快没必要上 ERP。选型这件事适合自己的才最好。2. 功能模块拆解从会计到考勤哪些模块真正值得用Ever Gauzy 的功能覆盖面相当广。官方把它称为“开源的业务管理套件”但我更愿意把它拆成几个彼此独立又可协作的模块来理解。这样评估的时候才不会迷路也能更清楚地判断哪些模块对你的业务真正有价值。2.1 财务会计不只是记账而是把业务单据变成财务数据Ever Gauzy 的财务模块给我留下很深印象。它不是那种只能录入收入支出流水的基础记账工具而是带上了复式记账特征的业务型财务系统。系统支持发票、账单、付款记录、税务报告、试算平衡表等能力并且能直接从销售订单、项目工时表、采购订单生成对应的财务单据。举个例子你给客户做项目报价报价审批通过后生成发票发票关联到项目上的实际工时和材料成本结款后系统自动形成一笔收款记录。整个过程从业务流程自然流到账务不需要像传统做法那样业务系统一套数据、财务软件再重新录一遍。在税务处理上它支持多税率设置可以按产品、服务或客户类别配置税码。对于需要按季度报税的公司来说这种数据准备能力能省下大量体力活。多币种支持也做进去了应收账款、应付账款都能看到原始币种和本位币的对照。2.2 人力资源与考勤远程团队会很喜欢这一块如果你带过远程团队一定懂考勤和工时统计的痛。成员分布在多个时区用视频会议软件沟通到底谁今天看了多少小时代码月底怎么算工资很容易扯皮。Ever Gauzy 的 HR 模块正好覆盖这些场景。系统里可以维护员工档案、职位、合同类型、薪资信息还能设置请假类型和审批流。考勤方式支持手动打卡、地理围栏打卡以及后台自动记录虽然不能做到像专业打卡软件那样精细但足够支撑“员工今天是否上班、是不是在约定地点”这类日常管理需求。比考勤更重要的是工时追踪。Ever Gauzy 提供桌面应用和浏览器辅助工具能记录员工在不同网站和应用上花的时间并区分生产性和非生产性活动。很多聪明的团队把这个功能当“项目成本核算器”而不是“监控器”员工把时间记到具体项目上月底系统自动算出每个项目的人工成本利润率一目了然。我建议你把它定位成“成本数据来源”而不是“纪律监控工具”。一旦团队文化不匹配任何时间追踪功能都会引发抵触情绪。2.3 CRM 与销售流程该有的都有但不算最出彩Ever Gauzy 的 CRM 模块包含联系人管理、客户档案、商机管理、销售漏斗和活动历史。你可以把线索慢慢培养成商机再关联到报价单、销售订单最后变成发票。它和财务、库存、项目的联动是最大卖点这一点是很多独立 CRM 工具做不到的。如果你已经深度使用 HubSpot、Pipedrive 这类专业 CRM会明显感觉 Ever Gauzy 在销售自动化、邮件追踪、模板丰富度上还有差距。所以我的观点是销售流程相对简单的团队完全可以直接用它的 CRM省一个订阅费而销售周期复杂、重度依赖自动化触发的团队可能还是需要专业 CRM然后通过 API 和 Ever Gauzy 做数据同步。2.4 库存与采购商品、仓库、订单的闭环库存模块支持产品档案、多单位换算、商品变体、仓库/门店多地点、库存调整、盘点、采购订单和销售订单。比较实用的是库存变动有记录能看到每一笔出入库的来源和去向做审计时心里有底。最让我喜欢的是销售订单和库存的联动方式创建销售订单后可以基于订单生成出库单系统自动扣减对应仓库的可用库存采购到货后也可以通过入库单自动增加库存。如果你经营的是实物商品业务这个闭环能帮你免去每天手工核对“库存表到底准不准”的焦虑。多仓库支持也做得比较细每个仓库可以设置独立地址和负责人调拨单能追踪商品从一个仓库流转到另一个仓库的全过程。对在多个平台上开店、有线上仓和线下仓的卖家来说这是硬需求。2.5 项目与时间追踪很多人是冲着这个来的如果让我给 Ever Gauzy 的模块排个名项目管理和时间追踪一定排第一。它支持任务看板、甘特图、里程碑、任务依赖关系还能把每个任务关联到项目和具体成员。配合时间追踪功能每个任务上都能看到实际工时、预估工时和超时偏差非常直观。这里有一个很有价值的场景给客户报固定价项目前先查一下同类历史任务的平均工时报价就不容易拍脑袋。项目执行中每周看一眼任务燃尽情况和人工成本累计能提前发现项目是不是要亏。这些能力在专业工具里往往是要单独付费的Ever Gauzy 把它们打包在一起确实有性价比。模块主要能力我眼里最亮眼的点财务发票、账单、税务、多币种、复式记账业务单据自动转财务凭证HR员工档案、合同、考勤、请假、报销工时和薪资数据可追溯CRM联系人、商机、销售漏斗、报价商机转报价再转发票的连贯流程库存产品、变体、仓库、调拨、盘点销售/采购订单自动增减库存项目看板、甘特图、里程碑、工单工时与项目成本实时统计3. 技术底座与部署方式NestJS、Angular 和 Docker 背后的设计逻辑聊完功能再看技术。Ever Gauzy 的技术选型决定了它的可二次开发程度和部署方式。如果你是开发人员或者团队里有技术负责人这一章值得细看。3.1 后端架构为什么选 NestJS 而不是其他框架Ever Gauzy 的后端基于 NestJS这是 Node.js 生态里一个相当成熟的企业级框架。它最大的特点是把模块化、依赖注入、装饰器和 TypeScript 的类型系统结合得很好写出来的代码结构非常清晰这对一个功能横跨财务、HR、库存的庞然大物来说至关重要。正因为是 NestJS所以项目里的业务模块都遵循类似的 CRUD 模式Controller 处理路由Service 处理业务逻辑Entity 映射数据库表Repository 负责数据访问。如果你接手的同事之前写过 NestJS上手这个仓库会快得多。数据库层使用了 TypeORM这在关系型数据管理、数据迁移、多数据库支持上非常方便。生产环境官方推荐 PostgreSQL开发环境也可以跑 SQLite。我强烈建议从一开始就用 PostgreSQL因为很多高级查询、事务处理和并发场景在 SQLite 下表现并不一样别等到数据量上来才换库。3.2 多组织与权限模型SaaS 化设计的内核我特别喜欢 Ever Gauzy 的“租户Tenant—组织Organization—用户User—员工Employee”这套数据模型。最外层是租户一个租户下可以创建多个组织组织之间数据隔离组织下管用户和员工员工可以归属于多个组织角色权限可以精细到功能级别。这种设计意味着哪怕你只给一家公司用也能方便地划分事业部、分子公司、项目组如果你未来想做成 SaaS 平台让多个客户共用一套部署那更是原生支持。我第一次看代码时许多实体上都有organizationId和tenantId字段这种从一开始就考虑数据隔离的做法确实能给后续扩展省很多事。权限方面系统提供了超管、管理员、员工等基础角色也支持在界面里自定义角色并勾选权限点。对大型团队你可以把权限设计到“谁看报表、谁审发票、谁改库存”这种粒度避免了“一人全权”的失控风险。3.3 部署方式Docker Compose、传统安装和云环境如果只是为了体验最直接的方式是用 Docker Compose 在本地把整套服务拉起来。仓库里提供了环境变量模板和容器编排文件后端 API、前端工作台、数据库以及 Redis 都可以一键启动。这么做的好处是不用在你本机装一堆 Node 和数据库环境干净省事。大致流程如下git clone https://github.com/ever-co/ever-gauzy.git cd ever-gauzy cp .env.example .env # 根据需要修改数据库、Redis、端口等配置 docker compose up -d等容器状态都变成 healthy浏览器打开前端地址再按照初始化引导创建管理员账号就能进入系统了。需要注意的是我遇到过容器之间端口没有在环境变量里对齐导致的连接问题所以启动前最好先看一眼.env里API_PORT、DB_PORT、REDIS_PORT等参数是不是和 docker-compose 文件里暴露的端口一致。生产环境部署其实也就是把同一套 Docker 镜像推到自己的服务器或云平台前端静态资源托管后端 API 服务化数据库用云数据库再加一层反向代理就能跑起来。如果团队规模很小也可以直接用官方云服务省去运维成本。3.4 开发模式启动开发者如果想改代码推荐用开发模式启动。项目用 npm 或 yarn 管理根目录下会有针对不同应用的脚本。通常需要先安装依赖再分别启动后端和前端服务yarn install cp .env.example .env # 启动后端 API yarn start:api # 另开终端启动前端工作台 yarn start:gauzy开发模式下前后端都会开启热更新改完代码浏览器自动刷新调试体验比较友好。但注意开发模式对内存要求不低Node 进程同时跑后端和 Angular 应用建议电脑内存至少 8G最好 16G。3.5 扩容思路异步任务与文件存储的取舍Ever Gauzy 用了 Redis 和队列来处理异步任务比如邮件发送、大量数据导入导出、定时任务等。这种设计在生产环境很实用可以把耗时操作从请求链路里剥离开避免用户点一个按钮就卡住。不过也意味着技术栈里又多了一个 Redis 依赖运维时需要一并考虑。文件存储方面系统默认支持本地文件方案也接入了 S3 这类对象存储的接口。如果以后要部署到云上建议从开始就配置对象存储否则将来迁移历史文件会非常痛苦。我个人的经验是ERP 这类系统里附件很碎片化发票 PDF、产品图片、员工合同、聊天文件混在一起存储方案一定要在一开始就定清楚。4. 本地跑通 Ever Gauzy完整上手指南与常见坑理论讲完进入实操。我想尽量把从零到一的过程写清楚特别是那些文档里没细说、但实际一定会遇到的坎。4.1 环境准备无论你用 Docker 还是源代码启动都需要先准备环境Git用来克隆仓库Docker 和 Docker Compose推荐省去手动装依赖如果走开发模式需要 Node.js 18 以上版本、包管理器npm 或 yarn浏览器建议用 Chrome 或 Edge对 Angular 应用的兼容性最好不需要预先装 PostgreSQL 和 Redis因为 Docker Compose 会帮你搞定。4.2 数据库连接和初始数据启动前最容易被忽略的是数据库配置。.env文件里涉及数据库、Redis、JWT 密钥、邮件服务等一堆变量。新手第一跑很多参数不需要改但至少要确保数据库连接信息能对上并且JWT_SECRET这种密钥不是留空的否则登录状态会出问题。Ever Gauzy 支持在启动过程中自动建表也会通过种子数据覆盖一些基础字典数据比如时区、语言、常用权限点。跑完初始化后你登录系统看到的并不算一个“空数据库”而是带了一套可参考的默认配置这反而比白板状态更容易上手。提示如果你多次删除数据库表重新初始化一定要把 Redis 里的旧缓存也清掉否则常看到数据已经改了前端界面却还是老样子。4.3 初始化配置先建组织再谈其他场景登录进系统后第一步不要急着录商品开发票而是先把“组织”建好。几乎所有业务数据都挂在组织下面组织信息建不清楚后面到处都会有连带问题。需要重点设置几类信息组织名称、所属国家/地区、默认货币、时区、工作周设置、是否启用多仓库、是否启用多币种。这些字段在创建后虽然也能改但影响历史单据的规范化程度所以第一次尽量想清楚。第二步是邀请或创建员工账号。只有把账号关联为员工才能分配工时、下达任务、走报销。这里容易疑惑的点是一个账号既是系统登录用户又要在某个组织里被“雇佣”不是建个用户就完事还要在组织里维护雇佣关系。第三步才是配置产品、仓库、客户、供应商这些基础档案。做完这三步系统才算真正可以用。4.4 跑一条完整业务流感受一下我建议第一次测试时完整走一条销售闭环而不是东点一下西点一下。比如这样新建一个客户档案录入一款产品设置好售价和税率创建销售订单把产品加进去订单中直接生成出库单系统扣减库存基于订单生成发票记录客户付款完成一张销售单的全生命周期接着再走一条采购闭环新建供应商、创建采购单、收到货后生成入库单、匹配供应商账单、完成付款。两条闭环跑完你会对整个系统的数据流转有非常直观的体感之后再去看报表就不会觉得数据是零散的了。4.5 我踩过的三个典型问题这个仓库值得给高评价但也不是完全没有脾气。我实际碰到的问题主要有三个。第一个是首次启动时前端一直显示“后端无法连接”。排查了半天根因是.env里的 API 地址写成了 localhost而在 Docker Compose 网络里应该用服务名进行互通。把前端使用的 API 地址改成容器网络内的服务名后问题立刻解决。第二个是导入数据时提示超时。这个问题在长列表、大量员工或产品数据导入时容易出现。后来发现是队列 worker 配置的是单线程数据库连接池偏小。适当加大异步 worker 数量和数据库连接数就能缓解但更务实的做法是数据量大时拆成多个批次每次不要超过几百条。第三个是权限配置太灵活带来的“误伤”。默认角色看似没问题但自定义角色时如果不小心把菜单权限关掉前端可能只隐藏菜单后端 API 却还允许访问反过来也可能出现界面能进、但接口 403。所以权限调整后最好用不同角色账号实测一遍不要凭感觉。5. 适用场景与选型建议什么时候选 Ever Gauzy什么时候该放手文章最后我想聊聊决策层面的事。不是每个团队都该选 Ever Gauzy搞清楚边界比盲目上手更重要。5.1 我建议选择它的三种情况第一种是远程团队或混合办公团队核心痛点是“工时看不见、成本算不清”。Ever Gauzy 把项目、任务、工时、发票和薪资数据打通你花在项目上的每一分钟都能转化为客户账单里的金额。我见过一个十人左右的开发团队用它的时间追踪功能做客户月结财务报表从原来的一周压缩到半天效率提升非常明显。第二种是已经开始多平台销售的贸易公司。多仓库、多币种、税务报告、采购与销售闭环这些能力正好能覆盖“线下仓 线上店”的日常操作。尤其是库存和订单自动联动避免了每天手工录库存的重复劳动。第三种是重视数据自主权的技术型公司。Ever Gauzy 开源、API 完整、数据结构清晰你可以把它当成一套业务中台来改造。哪怕只用了它的财务和项目模块未来接电商、接企业微信、接第三方 BI 工具都非常方便。5.2 我建议放弃它的两种情况第一种是超大型企业。集团级审批流、复杂合并报表、多级法人架构、精细化预算控制这些能力在 Ever Gauzy 里还不够成熟强行用会碰得头破血流。它更适合中小规模的单体或分散型组织而不是重型集团。第二种是完全没有任何技术人员的企业。虽然 Docker 部署已经很便利但日常使用中难免碰到性能调优、权限配置、数据异常排查的问题没有懂技术的人兜底一个小问题可能卡住整个业务流程。如果你不想请人维护买官方云服务可能是更稳妥的选择。5.3 平台生态与学习资源Ever Gauzy 的社区和生态正在成长中比起 Odoo 那种庞大的插件市场它目前的扩展更多依赖开发者直接写代码。好处是代码风格统一、核心架构一致坏处是拿来即用的第三方模块不多很多功能需要自己上手实现或等待官方迭代。好在它的代码仓库里有不少示例和测试用例GitHub Discussions 上也能找到问题解答。学习和讨论资料虽然不像成熟商业产品那样铺天盖地但官方文档几乎覆盖了从安装到权限、到 API 的每个环节。只要你愿意读文档大部分问题都能自己解决。5.4 一次有代表性的选型思考过程我有个朋友开了一家 30 人左右的跨境电商公司之前用的是“进销存 A 报销系统 B 项目管理 C 财务软件 D”每个月对账非常痛苦。他在我和推荐下试用 Ever Gauzy 两周最后做了一个很有意思的决定不把旧系统全换掉而是先用 Ever Gauzy 接管“员工工时 项目成本 客户发票”这三块库存和采购继续放在他熟悉的系统里通过 API 做同步。这个方案听起来不够“彻底”但非常务实。它说明 Ever Gauzy 的价值不一定来自“取代一切”也可以来自“把最难打通的数据缝隙补起来”。选型从来不是非黑即白的判断题而是基于成本和收益的连续决策。最后再说两句大实话东西好不好最终要落到自己的业务上。如果你已经受够了多个系统之间来回搬运数据不妨花一个下午把 ever-gauzy 在本地跑起来创建十个八个个测试数据走一遍订单、发票、工时的完整链路。只有亲手点过一遍你才会清楚它适不适合你而不是只看别人的评测。我个人的经验是这类系统的学习曲线不在操作而在“理解业务建模”。你把“组织、员工、角色、商品、订单”这些概念想清楚了Ever Gauzy 的每一块功能都会变得顺理成章想不清楚所有按钮都只是按钮。拿着这套思路去上手应该能少走很多弯路。