企业官网建设流程全解析

去年年底团队做内部工具选型时，我无意中翻到了 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

这个项目的技术栈非常鲜明：后端用 NestJS（TypeScript），前端用 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_HOST=localhost DB_PORT=5432 DB_NAME=ever_gauzy DB_USER=postgres DB_PASSWORD=你的数据库密码 DB_LOGGING=false

接着执行数据库迁移和初始化：

npm run migration:run npm run seed:all

seed:all会插入一组演示数据，包含商品、客户、供应商、订单示例等。我强烈建议你跑一遍这个命令，不然登录进去面对空荡荡的后台，你是很难理解每个功能是干什么用的。

第三步，分别启动后端和前端：

npm run start:api npm run start:web

等两个终端都出现“服务已启动”的日志后，浏览器访问http://localhost:4200，默认超级管理员账号一般为admin@ever.co/admin（以项目 README 中的说明为准），登录后就能看到一个完整的 ERP 后台了。

源码模式跑起来后，前端访问的是 4200 端口，后端 API 在 3000 端口。前后端通过环境变量API_BASE_URL通信，如果改了端口，记得同步修改这个配置。

3.3 Docker 方式快速体验

如果你只是先试试水，不想在自己电脑里装一堆数据库和 Redis，Docker Compose 是最省事的方案。

docker compose up -d

它会自动拉起 PostgreSQL、Redis、API 服务、Web 前端四个容器。过几分钟，浏览器访问http://localhost:8080（具体端口以项目的 Docker Compose 文件为准），就能看到登录页。

但有两点提醒你：

1. Docker 方式下，代码热更新比较麻烦，每次改代码都需要重新构建镜像，不适合日常开发。
2. 如果你在国内网络环境下拉取 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 部署和运行阶段的高频报错

这段时间我整理了一下自己体验群里大家常遇到的问题，几乎都是前几个星期会反复踩的坑，这里直接给大家一份速查表：

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 系统发挥价值的前提。工具本身不会自动让流程变规范，但一个规范使用的好工具，真的能帮你省下很多月底对账的功夫。