企业官网建设流程全解析

如果你在找一套能同时搞定客户管理、项目排期、发票报销、工资核算和库存出入库的管理系统，又不想被 SaaS 订阅费绑架，那 ever-gauzy 这个开源 ERP 项目值得你花点时间好好研究。它在 GitHub 上常年保持相当高的活跃度，定位于中小型企业的全流程管理，把常说的 "企业资源计划" 从重型本地部署拉到了现代 Web 技术栈上。更难得的是，项目从数据库设计到业务模块划分都足够完整，可以直接部署试用，你也可以把它当成一份高质量的全栈工程“教科书”来读。本文将从整体设计、核心模块、部署实操和常见坑位几个角度，带你完整拆解这个项目，并给出可直接上手的实操建议。

1. 项目定位与技术选型：先理解 ever-gauzy 在解决什么问题

1.1 不是“又一个进销存”：ever-gauzy 的完整业务闭环

很多人第一次打开 ever-gauzy 的界面，第一反应是“这不就是个带看板的 CRM 嘛”，实际用下去才发现事情没那么简单。它在设计上追求的是一条完整的企业管理闭环：销售端有客户关系和商机漏斗，项目端有任务排期与团队日历，财务端有发票、应收账款、费用报销和薪资核算，供应链端有采购、库存和供应商管理。换句话说，从销售拿到线索，到交付完成收款，再到给团队发工资、给供应商付款，整个过程的数据在系统里是打通的，业务单据能直接驱动账务这样才叫没有信息孤岛。

全栈工程师会看到，使用了 Angular 做桌面端前台，还能处处看到用 NestJS 构建的后端 API 服务。技术栈偏现代 TS 全栈方案。桌面端最终通过 Electron 打包，支持 Windows、macOS 和 Linux。数据库首选 PostgreSQL，也可以用 SQLite 轻量跑起来。这种架构带来的好处是：部署门槛低，个人电脑能跑，生产环境换套配置也能撑起几百人的团队日常操作。

它最打动人的地方在于“自动化账目”的设计理念。传统的进销存软件里，财务模块通常是独立的，单据归单据、账务归账务，到月底财务人肉对账是常态。ever-gauzy 里有条核心原则叫“永不丢失一笔交易”，每张发票、每笔报销、每次库存变动不仅仅是记录，还会根据预设规则转换成对应的记账分录，做到业务与账务同步。

1.2 为什么选择 Angular + NestJS 这套 TS 全栈方案

选型和团队背景有关系，对使用方来说，这个选择也带来了明显的实际收益。前后端共享 TypeScript 类型定义，可以大幅减少接口联调期 “字段名对不上” 的尴尬场景。NestJS 的模块化、依赖注入体系和 Angular 的依赖注入体系一脉相承，对于一个模块极多的 ERP 系统来说，这种一致的代码组织方式尤其重要。当你有几十个业务模块需要拆解、并行开发、逐步迭代时，它比传统的“前端纯 JS + 后端按目录堆文件”的老式写法要稳得多。

数据库层面默认走 TypeORM，配合 PostgreSQL 可以低摩擦地完成迁移、事务、软删除这些操作。ERP 这类应用对数据可靠性要求极高，PostgreSQL 在事务处理和约束完整性上的表现优于很多轻量关系型库。ever-gauzy 在 schema 层面也做了充分的预留，多租户字段、组织关联、审计字段（创建人、更新时间、软删除标记）几乎覆盖了每张表，后续做二次开发、权限细化、数据隔离的时候会轻松很多。

1.3 它适合谁用，不适合谁用

如果你属于以下情况，ever-gauzy 会特别合适：

• 有技术能力的中小团队，想摆脱高度绑定的 SaaS 订阅，拥有系统和数据的自主权；
• 开发团队需要一份模块完整、代码规范、有真实业务深度的开源项目参考，用来学习或在此基础上做产品二次开发；
• 咨询公司或外包团队需要给客户搭一套“看起来很像真正的 ERP、而且能跑起来”的管理系统，开源协议允许你商用并二次分发。

反过来也有需要慎重的情况：如果你完全不懂代码、没有运维人员、只想“双击安装即刻使用”，那么 ever-gauzy 的安装门槛可能会让你头大。尽管官方提供了安装包和部署脚本，但它本质上面对的是有基本技术背景的用户。此外，如果贵司的财务合规要求非常特殊，比如需要对接特定的税控设备或国内财务软件接口，需要二次开发，光靠内置功能是没法直接闭环的。

2. 核心业务模块与设计逻辑：拆解一套 ERP 的骨架

2.1 会计模块的“自动化”到底是怎么实现的

会计在 ever-gauzy 里不是孤立功能，而是整个系统的核心记账引擎。它的处理机制概括成一句话：业务动作触发记账模板。举例来说，你给客户创建了一张含税发票，确认的同时系统自动生成“借记应收账款、贷记销售收入、贷记销项税”的会计分录；当这张发票被标记为已收款，系统再自动生成“借记银行存款、贷记应收账款”的分录。这类记账规则无需人工干预，保证了财务报表可以实时反映业务数据。

具体实现上有个核心概念叫“自动化账目”（Automation），发生在“记账模板 + 关联单据”的交叉地带。模板定义了科目方向、金额取值字段和摘要摘要格式，例如取发票未税金额、税额、总金额；关联单据则限定了此模板适用的业务类型，如“销售发票”“采购账单”“费用报销单”。当你熟悉这套玩法后，可以把重复出现的月底调账、收入确认、成本结转做成模板，月末只需要点几下生成凭证，远比手动敲分录靠谱。

这里要特别提一下它的多币种、多组织支持。ever-gauzy 允许在一个系统内维护多个公司实体，各自拥有独立的账簿和币种，提供汇率维护和报表折算功能。做外贸或者集团型业务的人会用得上。实际数据表里，涉及金额的字段大多同时保存“原币金额”和“系统本位币金额”，这样可以避免汇率波动把历史数据搞乱。

2.2 从 CRM 到项目交付的完整链路

CRM（客户关系管理）模块不只是存名片和电话，它的核心价值是提供“从线索到现金”的可视化追踪。ever-gauzy 里可以从销售线索开始创建商机，设定预计成交金额和成交概率，系统自动把商机按阶段归类成看板视图，方便销售负责人判断哪些单子要重点跟进。商机一旦转化为客户与联系人，后续的报价、订单、项目交付就有了来源。

最让我觉得设计的有点东西的，是“项目”与“财务”的强关联。你可以在一个销售订单下创建项目，项目下设任务，任务指派给团队成员并记录工时。团队在任务上登记的时间，会自动汇总成项目成本；这些成本和费用最终关联给客户发票，形成“项目工时 + 费用 + 产品 = 对客户账单”的闭环。搞项目制交付的团队应该懂这个场景：以前项目毛利要在月底由财务拿 Excel 算，现在每周末打开系统就能看到实时毛利预估，这对经营决策的帮助非常大。

日历与排期模块也不是摆设。项目计划、任务截止日、团队成员请假会统一呈现在团队日历和资源视图中，管理者可以直观判断谁手上活儿多、谁有资源接新项目。对于远程办公团队，还有考勤打卡和在线状态，系统能按月生成出勤报表，直接进入工资核算流程。

2.3 发票、报销与采购的细节设计

发票模块支持常见类型：销售发票、采购账单、贷项通知单（红字发票）、预付款发票等。每条发票都能定义收款计划与截止日期，系统提供“逾期未收款”筛选，方便你盯着应收账款。发票可关联到客户、项目、销售订单，PDF 导出模板和邮件发送也是内置的，省了来回导数据做对账单的功夫。

报销模块的设计亮点在于“审批流 + 记账 + 还款联动”。员工提交费用明细，附上票据图片，部门主管审批通过后，系统自动生成应付员工的其他应付款分录；财务实际付款后核销。连同预支款、差旅标准设置都有对应实现，比起“报销单+线下转账+事后补录”的流程要规范得多。采购模块包含供应商管理、采购申请、采购订单、收货入库和供应商账单，库存数量能随收货自动增加，成本自动计入存货科目。这套链路虽然不是万能的，但对贸易型、制造型中小企业的日常运转已经完全够用。

2.4 工作台与权限：多人协作时的秩序保障

ERP 类系统如果权限做得稀烂，业务数据一旦被不该看到的人看了，麻烦特别大。ever-gauzy 的权限体系简单说是“角色 + 权限点”模式。系统内置了超级管理员、管理员、员工、经理、财务、审计等角色，每个角色可以勾选一系列细粒度权限点，比如“查看销售报告”“创建发票”“批准报销”“修改工资记录”。你也可以创建自定义角色，把权限点组合起来匹配你公司的岗位分工。

个人工作台的设计很务实，登录后看到的是今日待办、未读通知、待审批事项、本周我的任务、快捷创建入口。加上仪表盘对整个组织经营数据的可视化呈现，比如收入趋势、应收账款账龄、项目人力负荷、库存周转等。这些图表的功能密度和细节不比一些付费 BI 产品差，大部分数据指标都是实时查询实时计算，没有“报表夜间跑批”的等待感。

3. 部署与配置实操：快速在服务器上把 ever-gauzy 跑起来

3.1 前置准备与环境要求

部署之前先把硬件和系统准备到位。官方推荐的配置是 2 核 CPU、4G 内存、40G 可用磁盘，生产环境建议 4 核 8G 起步，数据库单独一台机器会更好。操作系统以 Ubuntu 22.04 LTS 为最推荐，CentOS 和 Debian 也能跑，但踩坑概率略高。域名不是必须的，但如果要走 HTTPS，建议提前把域名解析到服务器上。

依赖就四样：Docker 和 Docker Compose 插件、Node.js 18+、npm、Git。ever-gauzy 提供了一键安装脚本，装之前先把端口规划好。默认前端端口是 8080，后端 API 是 3000，数据库 PostgreSQL 是 5432。如果你服务器上已经有别的服务占用了这些端口，要么改环境变量，要么用防火墙做端口映射，别直接跑脚本然后发现端口冲突一头雾水。

3.2 两种最常用的安装方式对比

方式一：零配置的演示安装

适合先看效果、快速试玩。直接用 docker.compose.yml 跑起整套环境，包括前端、后端、PostgreSQL，一条命令搞定：

git clone https://github.com/ever-co/ever-gauzy.git cd ever-gauzy cp .env.compose .env docker-compose up -d

启动完成后打开http://localhost:8080，用默认管理员账号登录。这个方式的局限也很明显：用的是内置 SQLite 或一次性数据库，容器一旦删掉，数据就没了，只适合体验，不适合正经用。

方式二：手动配置的生产部署

先用一键脚本创建配置文件，然后手动调整这张.env里的核心项：

npm run setup:env nano .env

重点是这些变量：DB_HOST指向你的数据库地址，本地装 PostgreSQL 就是localhost；DB_PORT默认5432；DB_NAME、DB_USER、DB_PASS需提前创建好数据库和账号；JWT_SECRET手动改成一段足够随机的字符串，至少 32 位；ENCRYPTION_KEY也一样。这两把“钥匙”千万保管好，JWT 密钥泄漏等于系统身份验证失效，加密密钥遗失就等于所有历史敏感数据永远无法解密。配置完了先装依赖、跑数据库迁移，再分别启动 API 和前端：

npm install npm run build npm run migration:run npm run start:api npm run start:gauzy

生产环境推荐用进程守护工具（如 PM2）来托管这两个进程，不然 SSH 窗口一关服务就停了。用pm2 start就行，开机自启也方便。

3.3 第一个管理员的初始化与基础配置

安装完只是第一步，真正的事是从登录后的初始化开始的。首次登录会进入组织设置向导，需要填写公司名称、默认币种、所处时区、会计制度（一般选权责发生制）、财务年度起始月等。这些信息看似基础，但会影响后续所有财务报告的规则，别随手乱填。

组织创建完，下一步是建立员工档案并关联用户账号。ever-gauzy 里“用户”和“员工”是两个概念：用户是能登录系统的人，员工是拥有岗位和成本属性的人。一个用户可以同时是多个组织的员工，这在集团架构下特别常见。员工档案里能维护时薪、月薪、入职日期、部门、职位，这些字段最终服务于工资核算与项目成本计算。

再往下建议把“数据导入”做了。你可以用 CSV 模板批量导入客户、供应商、产品、期初库存和历史发票。先建好客户档案，再做销售发票，比进来直接创建单据要顺得多——因为发票创建时下拉框里得有客户可选，先有档案才有单据，这个顺序不对后面就会觉得系统“卡”。

3.4 常用环境变量与参数推荐

给新手列一份我实测下来比较稳妥的配置参考：

有人说首登默认管理员口令太弱，这个必须承认。ever-gauzy 默认账号密码是admin@ever.co/admin，启动后第一步就必须去用户中心改掉，同时关掉“允许注册”选项，不然公网部署后别人也能登录。虽然这里不展开细节，但安全意识一定要到位。

4. 常见问题与避坑实录：实测中容易踩的五个深坑

4.1 服务器根目录没有足够空闲磁盘空间

Docker 镜像加起来好几个 G，再加上数据库和数据卷，磁盘空间不够是安装失败的常见原因，而且报错还不直观。第一次装完发现启动到一半就挂，排查时docker ps能看到部分容器退出了，日志里写着和磁盘只读相关的东西。查了下磁盘才发现/只剩 1.8G，镜像都拉不完整，好家伙。

解决方法是部署前先把数据目录规划好。至少预留 30G 空间给 Docker 的数据目录，用df -h确认根目录空间足够。要是服务器上还跑了其他服务，建议给/var/lib/docker单独挂一块数据盘，这样日志、镜像、数据卷都清楚，不会把系统盘撑爆。此外，docker system prune -a这个命令能清掉所有不被使用的镜像和构建缓存，空间吃紧的时候能救急。

4.2 前后端能打开但接口 404 或网络错误

这类问题大多数人会先去查网络，其实是配置文件里的API_BASE_URL和CLIENT_BASE_URL没配对。前端启动时会拿着后端地址去请求 API，如果后端地址填的是localhost:3000，但 API 实际监听在0.0.0.0:3000或另一台机器上，那请求自然全部失败。

检查思路是：先从服务器上直接跑curl http://localhost:3000/api确认后端通不通，再用浏览器开发者工具看具体的接口请求报错是什么。最常见的是直接拉不起后端进程，运行npm run start:api看启动日志里有没有显眼的错误，比如ERROR [ExceptionHandler] connect ECONNREFUSED，这类信息能直接告诉你问题出在数据库还是应用层。总结一句话：先调到后端能通，再调前端，不要上来就怀疑代码。

4.3 数据库迁移失败导致页面白屏无法初始化

安装脚本会自动跑数据库迁移，但在手动部署或者数据库版本不一致时经常翻车。migration:run报错的典型原因包括：数据库账号没有建表权限、PostgreSQL 版本太老（建议 12+）、之前跑过一半的迁移留下了脏数据。

处理方法不复杂：进 PostgreSQL 把目标库先删掉重建，创建一个有全部权限的账号，重新执行迁移。如果迁移还是中断，改用npm run migration:revert回退一次，再把出错的迁移文件单独重跑。有一点要提醒：千万不要在生产环境数据库上反复折腾迁移，开发库随便试、生产库务必提前备份，这个红线守住了能省很多事。

4.4 桌面端白屏或闪退怎么办

Electron 打包的应用打开后是白屏，常见原因有几种：一是本机没装 Visual C++ Redistributable 或运行库缺失，二是系统代理拦截了本地请求，三是前端资源没打进包里（路径问题）。排查顺序是：先跑日志看有没有报错，再看开发者工具里的 Console 报什么错，最后检查本机网络环境。Windows 上安装最新版 VC++ 运行库可以解决一大批白屏问题；macOS 上如果从网上下载的包被 Gatekeeper 拦截，右键打开也比直接双击更靠谱。

如果其他系统都能打开、Linux 桌面版不稳定，多半是沙箱权限或者图形库依赖问题。把启动命令换成gauzy --no-sandbox试一下，能定位问题范围。总之桌面端踩坑的概率比 Web 端高不少，优先级没有特殊需求就优先用 Web 端口，更省心。

4.5 报表数据与手工账对不上怎么排查

有不少人遇到“系统里的利润表数字和银行实际余额对不上”的问题，多数是对账逻辑没理解透。ever-gauzy 的账务是基于业务单据自动生成的，如果你录入了一张发票但没做收款核销、或者报销单还没审批通过，那么报表里收入和应收会出现“在途”状态，和实时银行余额确实有时间差。

排查思路从凭证入手：打开“账本分录”或“总账”视图，筛选对应日期范围，把系统里的分录找出来。大部分对不上都是因为历史数据录入缺了单据，或录入到错误的组织/账簿里了。还有一条更常见的坑：发票录入了但没确认，确认与未确认在 ever-gauzy 里是两种状态，费用报销单审批通过前也不计入费用，只有状态流转到正确节点才进账。建议每月月底做一次系统数据与外部银行对账单的核销，养成这个习惯比事后翻旧账舒服得多。

5. 二次开发与扩展建议：把这套模板用出自定义价值

5.1 从哪几个切入点改代码最划算

ever-gauzy 靠着模块化结构，二次开发不用把所有代码啃完才能动手。第一个值得改的地方是页面 UI 的品牌化，把登录页、侧边栏、发票 PDF 模板里的 logo、公司名、主题色换成自己的，不需要动数据库；第二个是高价值的功能扩展点：自定义报表、审批流的个性化配置、第三方接口对接（比如钉钉、企业微信、电子签名）都可以在现有模块基础上加，很多项目就是在这个层面做出自己的竞争力。

代码层面，你会看到后端按业务模块拆分成子目录，每个模块有controller、service、entity、dto等文件夹。仿照现有模块写一个新的 “顾户积分模块” 完全可行。数据库表字段通常不建议删，现有表字段尽量只加不改，原因很简单：加字段是向后兼容的，删改字段会导致已有数据不可用。

5.2 给外包/商用项目的四项实操建议

如果是给客户交付二次开发，我的建议是：

• 把代码仓库和数据库初始化脚本做成自动化发布流程，不要每次手工导出数据库再导入，很容易漏表或漏数据；
• 从第一天就引入数据版本控制，迁移脚本全部入库，上线前用 git tag 对应数据库版本，回滚才有着落；
• 把日志采集和监控做起来，至少要有全局错误日志，不然生产环境出问题连日志都找不到；
• 交付时和客户明确哪些是因为二次开发产生的定制项，哪些是开源社区的标准功能，将来升级维护时能划清边界，不至于每次社区升级代码冲突到怀疑人生。

说到底，ever-gauzy 的真正魅力和价值在于：它给你演示了“一套完整企业管理软件应该怎样设计代码、组织数据、串联业务环节”，而不是一个只能点按钮的玩具。这个东西在今天开源生态里并不多见，花一周时间把它跑通、读懂、改造出你自己的业务，怎么算都值回票价。

最后再分享一个实操中的心得：给这个项目做二次开发或者部署测试，强烈建议先在一台干净的虚拟机里把“从零到能登录”完整走一遍，把每一步命令、每一个环境变量都记录下来形成自己的检查单。等你在干净环境能跑通了，再到生产环境按部就班执行，能少掉一半头发。遇到奇怪的 bug 先去官方仓库的 Issues 里搜关键字，八成有人和你一样踩过坑——这是开源项目最慷慨的地方。