企业官网建设流程全解析

Ever Gauzy这个项目，我关注的时间不算短了。最早是因为找开源ERP解决方案时翻到的，后来在给一个做贸易的小团队搭内部管理系统时，直接就拿它当了主力。如果你也正在为“公司缺一套能管钱、管项目、管客户、还管工资的软件”而发愁，又不想被商业ERP的授权费绑定，那这篇内容大概率能帮上你。

先说一个整体印象：Ever Gauzy不是那种“只能看看页面”的半成品，而是一个能真正跑业务的完整平台。它把会计、发票、销售、项目、库存、员工这些都揉进了一个系统里，而且是开源的——这意味着你可以免费拿到全部源码，自己部署、自己改，彻底摆脱SaaS订阅模式的束缚。我以前被某商业软件一年几万块的授权费折腾过，所以对这种“源码在手、随便折腾”的项目天然有好感。

这篇文章我会从项目能干什么开始，一路拆到技术选型、部署流程、业务模块的实际操作，最后再把我踩过的几个坑和排查思路全部交代出来。希望你看完可以直接动手，不用再走我当初那些弯路。

1. 项目概述：ever-gauzy背后到底是一套什么系统

1.1 它解决的核心问题

很多小公司在管理上有个特别尴尬的阶段：客户资料记在Excel里，发票用另一个软件开，发工资靠财务手工算，项目进度又在聊天群里散着。数据各管各的，月底对账就像搞侦探工作。

Ever Gauzy要解决的问题，就是把这一堆“各管各的”集中成一个统一的运营平台。它本质上是一个面向中小企业的ERP（企业资源计划）兼CRM（客户关系管理）系统，但比传统ERP轻，又比单纯记账软件重，正好卡在“什么都缺”和“什么都要”之间的位置。

我实际用下来的感受是，它最核心的价值在于打通。一个客户从询价变成销售订单，订单再转成项目任务，项目做完后生成工时记录，工时又自动汇总进工资表，最后开发票、记账、收款——整条链条在系统内部是连贯的，不需要人来回搬运数据。

1.2 核心功能模块拆解

从功能布局上看，Ever Gauzy可以大致分成下面几个大块：

• 会计与财务：总账、日记账、应收应付、预算、财务报表，基础的复式记账逻辑它是齐全的。
• 销售与CRM：线索管理、客户信息、报价单、销售订单、发票和收款记录，形成一个从获客到回款的全过程。
• 项目管理：任务看板、工时跟踪、里程碑设置、项目预算与收益分析，适合以项目制运作的团队。
• 员工与薪资：员工档案、考勤休假、工资条设置、薪资计算，支持按小时工和固定工资两种核算方式。
• 库存与采购：产品目录、仓库管理、采购订单，虽然不如专业WMS系统那么深，但应对一般贸易和产品型公司足够。
• 报表与分析：各类仪表盘和图表，能看销售趋势、项目盈利情况、员工成本等关键指标。

这六个模块之间不是孤立的。我举一个实际场景：客户A发来一个需求，你先在CRM里建线索，转为客户档案后创建报价单，客户确认后生成销售订单。接下来在项目管理里建立项目并把任务分配给团队，大家每天记录工时。项目完成后，系统根据订单金额和实际工时自动算出项目毛利。与此同时，每个人的工时数据由薪资模块汇总，生成对应的工资记录。这个闭环跑通之后，管理者对整体经营情况会清晰非常多。

1.3 适合谁用、什么场景最合适

从我接触过的实际案例来看，Ever Gauzy最合适的是这几类场景：

• 小型咨询公司或项目制工作室：核心需求是“项目工期 + 人力成本 + 客户回款”三件事的联动，它天然契合。
• 做实物贸易的小团队：产品目录、库存、采购订单、发票这一条线能覆盖日常运营的大部分环节。
• 有技术团队且不想被SaaS绑定的公司：因为可以自部署、改代码，数据完全在自己手里。
• 自由职业者和会计师外包团队：多客户、多账套的管理模式让代账场景变得很方便。

当然，如果你是一个几千人规模的大型制造企业，需要复杂的MRP排产、多级BOM管理，那Ever Gauzy目前还不适合你。它更适合业务逻辑相对标准化、规模在几个人到一两百人之间的团队。

注意：Ever Gauzy的开源版是免费自托管的，但项目也有商业版“Ever Gauzy Platform”，在功能边界上商业版会更完整。我们日常用开源版做核心业务已经比较稳，但涉及生产环境时还是建议先做小范围试用，再决定是否需要商业支持。

2. 技术架构与设计思路拆解

2.1 技术栈选型：为什么是NestJS + Angular + PostgreSQL

Ever Gauzy的整个技术体系属于“现代且稳重”的那一类。后端用的是NestJS + TypeScript，前端是Angular，数据库默认采用PostgreSQL，ORM层使用TypeORM。这套选型组合在开源ERP领域其实不多见，大多同类项目还在用PHP或者Java那一套。

我之前用Java搞过一阵子开源ERP二次开发，对比下来，Ever Gauzy的TypeScript全栈方案对前端开发者非常友好——如果你本身是搞前端出身的，想要转全栈，那这个项目的代码读起来几乎没有任何门槛，全栈语言统一，类型定义互相复用，开发效率高很多。

NestJS的模块化依赖注入机制，让代码组织非常清晰。每个业务域一个Module，各自管自己的Controller、Service、Entity，互不纠缠。我刚接触这个项目时，光看目录结构就能快速定位到某个功能对应的代码位置，这对二次开发来说特别重要——好代码应当是“看一眼就知道去哪改”的。

数据库层面选择PostgreSQL而不是MySQL，我觉得是深思熟虑的结果。ERP类的系统要跑大量复杂联表查询和财务数据统计，PG的窗口函数、CTE表达式、JSON字段支持都比MySQL成熟，而且在数据一致性方面有更好的保障。配合TypeORM的迁移机制，团队协作升级数据库结构也相对安全。

2.2 前后端分离与桌面端支持

Ever Gauzy的前端是一个标准的Angular单页应用（SPA），通过REST API与后端通信。除此之外，它还提供了基于Electron的桌面客户端，可以跑在Windows、macOS和Linux上。对很多非技术背景的员工来说，桌面端比打开浏览器更像一个“正经的办公系统”，心理上的接受度会高一些。

我自己的实践体会是：日常管理操作直接用Web端就够了，但如果是让会计小姐姐每天做账、录凭证，桌面端确实更好用一些，因为操作路径更集中，不会被其他浏览器标签页打扰。而且Electron客户端可以直接加载本地部署的API地址，数据安全性也更好控制。

前后端分离架构还带来一个好处：API层可以被独立测试和调用。我后来做二次开发时，很多自动化脚本就是直接对着REST API写的，不需要采样页面定位元素，省了非常多的力气。

2.3 多租户与国际化设计

Ever Gauzy在架构层面设计了多租户支持。所谓的租户（Tenant）可以简单理解为“一个独立的组织空间”，每个租户下面可以建多个员工账号，数据天然隔离。这个设计对做代账、代运营服务的人特别有价值——一套系统装好，可以同时服务好几个客户，每个客户的数据互不可见。

国际化（i18n）方面，它本身带了多语言资源包，中文社区的贡献也一直在增加。我用的时候，中文界面虽然有个别位置翻译不完整，但整体不影响操作理解。如果你有精力，完全可以自己在语言文件里把剩余部分补齐，反过来提交给社区。

3. 部署安装与实操配置

3.1 环境准备与依赖清单

如果你之前没有部署过Node.js类项目，建议先把基础环境准备好。Ever Gauzy的常见运行环境包括：

我自己第一次部署时是手动装的依赖，后来发现这个项目的依赖数量不少，安装过程比较耗时。如果你的服务器配置一般，建议有点耐心，npm install这一步可能跑个十几分钟。另外，网络环境对npm源影响很大，国内服务器建议直接把registry切换成淘宝源，能快不少。

3.2 Docker Compose快速起服务

如果不想在各种依赖里挣扎，Ever Gauzy的官方仓库里提供了Docker Compose编排文件，这是我个人觉得最省心的部署方式。大致步骤如下：

1. 克隆代码仓库：
2. 进入项目根目录，找到docker-compose.yml文件。
3. 按照需要修改环境变量，主要是数据库密码、API端口等信息。
4. 执行docker-compose up -d启动所有服务。
5. 查看容器日志，确认API和前端都正常启动后，通过浏览器访问配置好的前端端口。

这段流程里最容易出问题的有三个地方：一是端口冲突，二是容器里PostgreSQL初始化时间不够导致API启动时报数据库连接失败，三是没有配置正确的API地址导致前端页面打不开数据。特别是第三个问题，我见过很多人在Docker方式部署时栽到这里——前端容器里默认的API地址是localhost，浏览器访问时其实是从你自己的电脑找服务，结果当然找不到。

3.3 核心环境变量与配置项解析

Ever Gauzy的配置集中在环境变量里。我从实际使用角度挑几个最重要的说明一下：

• DB_HOST、DB_PORT、DB_NAME、DB_USER、DB_PASS：数据库连接参数。Docker方式下，DB_HOST要写成数据库服务的容器名，而不能是localhost。
• API_PORT：后端API的监听端口。默认是3000，如果想改到别的端口，要注意防火墙和安全组策略。
• GAUZY_API_BASE_URL：前端用来访问后端API的基础地址。手动部署时这里最容易出错，要填一个浏览器实际能访问到的地址。比如你在服务器上部署，这里就应该填服务器IP或者域名加上API端口，而不是127.0.0.1。
• JWT_SECRET：JWT签名的密钥。默认值在生产环境必须改掉，否则任何人都可以伪造登录令牌。
• REDIS_URL：Redis连接地址。如果启用了任务队列和缓存，这里必须正确配置，不然部分后台任务会静默失败。

这里的思路其实和大多数开源系统一致：默认配置让你能跑起来，生产环境一定要逐一审查并改成安全的值。我见过不少人在内网部署后图省事不改密钥，这其实风险很高，一旦系统暴露到内网恶意扫描下，后果会很严重。

3.4 手动部署的注意事项

如果你不想用Docker，手动部署的典型流程是：启动PostgreSQL并建库，安装Redis，克隆代码，分别在目录下执行依赖安装，配置环境变量文件，构建前端静态文件，再用Node.js启动后端服务，最后用Nginx把前端静态文件和API反向代理到同一个域下。

手动部署的好处是资源占用相对小一些，问题排查也直观，但对操作者要求高。我在第一次手动部署时就遇到了Node版本不匹配导致的构建失败，换了版本后问题才解决。因此，我的建议是：如果你只是验证功能或小规模使用，优先Docker；如果你要在生产环境运维并且对Linux命令有一定经验，再考虑手动部署。

4. 核心业务模块的使用实践

4.1 会计与发票模块的完整闭环

ERP系统里最不能出错的模块就是财务。Ever Gauzy的会计模块做得比我预期扎实，它支持完整的复式记账逻辑——每一笔交易都会同时记录借方和贷方，生成凭证，并汇总到总账和明细账里。这个逻辑传统但可靠，审计的时候也容易追溯。

实际运营中，最常见的一条路径是这样的：

1. 在CRM模块中录入客户并创建发票，发票上标记税率、币种、付款期限。
2. 当客户付款后，在发票上登记收款记录，系统自动生成应收账款的核销。
3. 会计人员可以在会计模块中查看这张发票对应的凭证，确认科目是否正确。
4. 月末跑一遍财务报表，查看利润表和资产负债表。

如果你没有专业财务背景，我建议启用模块之前，先和会计沟通一下科目的设置方式。Ever Gauzy默认的会计科目表是通用的，但不同国家、不同行业对科目的分类可能有差异。提前把科目调整好，后面记账会顺很多。

4.2 项目与销售管理如何整合

项目模块是我用得最多的部分。Ever Gauzy的菜单里提供了任务看板、日程安排、工时记录这些基本能力，但真正压轴的是它能把项目和销售、财务串起来。

我实际的工作流是这样的：

1. 销售代表拿到客户合同后，在系统中创建销售订单，金额和付款方式都填清楚。
2. 项目管理员根据订单创建一个关联项目，设定预算金额和计划工时。
3. 团队成员每天在系统上录工时，项目看板上更新任务状态。
4. 项目完结后，系统把实际工时成本汇总出来，和订单金额对比，项目毛利一目了然。

看板功能对团队协作的提升我是很认可的。之前我们用共享表格管理项目，经常出现任务状态同步慢的问题，有人改了一张表另一人还在旧版本上工作。切到Ever Gauzy之后，任务状态实时共享，减少了很多不必要的沟通成本。当然，如果你需要非常复杂的甘特图、关键路径法等功能，它相比专业的项目管理工具还是简单了一些，建议和Jira之类的工具配合使用，把Ever Gauzy作为业务数据的中枢。

4.3 员工管理与薪资计算

员工模块的逻辑非常贴近欧美和国内部分公司的实际需求。系统里可以维护每位员工的档案，包括入职日期、岗位、薪资标准、联系方式和合同附件。和项目模块联动后，每个员工的工时记录会被自动汇总，方便管理人员了解资源利用情况。

薪资计算这一点我要单独说一下。Ever Gauzy支持按固定月薪和按小时计费两种方式，并允许设置不同的计薪周期。比如有的外包团队需要按客户项目结算人力成本，这时候按小时计费就能直接算出每个项目的人力成本。系统还支持请假和休假管理，这些数据会影响到每月的实际计薪天数。

不过，国内企业的薪资结构通常比较复杂——五险一金、个税专项附加扣除、绩效奖金、餐补交补之类。Ever Gauzy开源版对这类复杂薪资规则的支持比较有限，我建议把它作为“基础薪资的计算和记录工具”，具体的个税和社保计算可以继续用财务软件，或者做二次开发来扩展。

5. 常见问题与排查技巧实录

5.1 常见问题速查表

我在部署和使用Ever Gauzy的过程中，遇到过不少问题，也帮朋友排查过类似的问题。下面这张表是我整理的“踩坑高频榜”：

这张表里的很多问题，根子其实不在项目代码，而是在部署配置上。所以不管遇到什么现象，优先检查环境变量和依赖服务，往往比去翻源码更高效。

5.2 我在实际使用中踩过的坑

第一个让我印象深刻的坑是数据库版本的兼容问题。最初我图省事，在默认的PostgreSQL配置上直接建库，结果跑数据迁移时报了字段类型不兼容的错误。后来查文档发现，这个项目对PostgreSQL版本有建议值，版本太老会造成部分函数不可用。解决方式是重新初始化数据库，并调整到建议版本，之后再跑迁移脚本，整个流程就顺了。

第二个坑是用Docker时，Redis容器没有启动，导致部分定时任务和队列任务一直不执行。一开始我根本没往Redis那边想，因为页面功能看起来都正常。后来看了后台日志才发现有一堆任务重试错误。这个教训是：部署完以后一定要把整个服务链路都验证一遍，不要只看前端界面。

第三个坑比较偏：Electron桌面端登录时，如果还是用默认的自签名HTTPS证书或者纯HTTP，很可能被安全策略拦下来。当时为了省事没有在Nginx层配置HTTPS，结果桌面端直接拒绝连接。后来我配了反向代理并在客户端信任了证书，才算彻底解决。

5.3 二次开发建议与扩展思路

如果说部署是入门，那二次开发才是Ever Gauzy真正值钱的地方。因为它源码完整、模块清晰，扩展新功能可以沿着已有模式走：

1. 在数据库层新增数据表或对已有表加字段，通过TypeORM迁移来同步。
2. 在后端新增Module、Controller、Service，对应新的REST API接口。
3. 在前端Angular项目中新增页面、路由和服务对接API。
4. 注册菜单和权限点，让新功能出现在用户界面中。

我自己在实际扩展中就给它加过一套客户合同到期提醒的机制：在数据库里加一个合同到期时间字段，后端加一个定时任务，每天扫描即将过期合同，然后通过企业微信机器人推送提醒。整个过程大约两小时就完成了，能明显感觉到框架设计的边界清晰，改起来不费劲。

如果你打算长期用它，我建议提前规划好版本的升级策略。尽量不要在官方代码上直接做大量修改，尽量通过新增模块的方式扩展，这样将来官方发布新版本时，你的代码仍然有合并回去的可能。如果实在需要修改核心文件，务必用Git管理好，记录每一次改动的原因。

最后再分享一个小技巧：Ever Gauzy的API自带Swagger文档，启动后端服务后访问文档地址就能看到所有接口的定义和在线调试入口。这个文档在对接外部系统或者排查接口问题时极为好用，但很多人部署完根本不知道它的存在，实在太浪费了。类似这样的细节还有很多，等你在源码里挖到的时候，估计也会有和我一样的感受——这个项目的开发者在认真做事，而且真的希望后来者能把它用起来。