企业官网建设流程全解析

先说个题外话，很多人看到“No.5 信息应用系统”这种标题，第一反应是“又一个内部管理系统”，容易直接划走。但如果你真的在一个组织里待过几年，接触过零散的表格、聊天记录里的数据、割裂的审批流程，就会明白这种“信息应用系统”其实是很多单位信息化进程里绕不开的一步。我前后参与过几个类似项目，最近完成的一套“No.5 信息应用系统”就是典型的第五代迭代版本，从需求梳理到部署上线大部分环节都踩了一遍，今天把这些经验完整记录下来，希望能给正在做同类系统的朋友一些实质参考。

这套系统的核心定位很明确：把散落在不同人手里、不同表格里的信息，统一收口到一个应用里进行管理、查询、流转和统计。它解决的问题并不高大上，但非常实际——信息找不到、数据对不上、流程靠人催、报表靠手工拼。适合正在规划自建管理系统、或者想做“轻量级中台”的朋友参考，哪怕你不是专职开发，看完也能对整个系统怎么搭、哪些地方容易翻车有一个完整认识。

1. 需求拆解与整体设计：先想清楚到底做什么再动手

1.1 “No.5” 背后的版本含义

这套系统名字里有“No.5”，不是随便取的编号。前四个版本分别对应了不同的演进阶段：第一版是简单的信息登记表，第二版加了分类查询，第三版引入了账户权限，第四版打通了审批流。到了第五版，目标很明确：把前四个版本的能力整合成一个稳定、可扩展、操作路径清晰的一体化应用系统。

换句话说，“No.5” 不给用户添乱，不搞十八个模块让使用者自己拼装逻辑，而是要“开箱即用”。这种整合难度其实比从零做一个新系统更大，因为你要兼容历史数据、迁移老逻辑、统一操作习惯。如果团队没有充分理解历史版本的痛点，只是机械地把功能堆在一起，大概率会做成一个四不像。

1.2 核心需求清单：不要拍脑袋列功能

我接触过很多需求文档，最常见的问题是一上来就写“要有搜索功能”“要有报表”，但完全没定义清楚搜索什么、报表给谁看、更新频率多少。第五版启动前，我专门组织了几轮访谈，把业务方口中的需求翻译成可落地的功能点，最终整理成四条主线：

• 信息资产化管理：所有关键信息必须有唯一编号、明确归属部门、完整生命周期记录，不可随意删除，只能变更状态。
• 高效检索与调阅：支持按关键词、编号、时间范围、责任人等多维度组合查询，查询结果能以列表、详情、导出三种形态呈现。
• 流程协同闭环：涉及变更、审批、分发等操作，必须有标准化的流程引擎支撑，每一步都有迹可循。
• 统计报表自动化：业务方关心的核心指标，如新增数量、完成率、平均耗时、部门分布等，要能按日、周、月自动汇总，不需要人工二次加工。

你会发现这四条没有一条是“实现某种炫酷功能”，全是解决“信息流通顺畅”的基础问题。这恰恰是信息应用系统最容易出错的地方——很多人喜欢加功能，但忘记了系统的本质是让信息有序流动，而不是堆更多按钮。

1.3 模块划分与数据模型设计

基于上述需求，系统拆分为用户权限、信息台账、检索中心、流程管理、报表中心、系统配置六大模块。模块划分的逻辑遵循“高内聚、低耦合”：权限和配置是底座，台账和流程是核心业务，检索和报表是价值出口。

数据模型设计花的时间最长，也是最需要提前想清楚的地方。第五版的主数据表采用“一主多从”结构：主表保存基本信息（编号、标题、状态、归属部门、创建时间等），扩展表保存业务自定义字段，附件表单独存储文件信息。这样设计的优点是通用性极强，业务字段怎么调整都不需要改表结构，缺点是查询时需要联表，对索引设计提出了更高要求。

我在设计时还做了一件事：给每个核心表增加deleted逻辑删除标识，禁止物理删除。这是从第三版踩坑学来的教训——当时有人直接 DELETE 了一批脏数据，结果关联的审批记录全部悬空，复盘花费了整整一周。逻辑删除虽然会占用一点存储空间，但能保证数据链条的完整性，这个代价完全值得。

2. 技术选型与架构设计的关键取舍

2.1 为什么坚持前后端分离

如果你只是做一个几十人用的内部系统，有人可能会觉得前后端分离“过度设计”，用传统模板引擎一把梭更快。我的看法是：第五版的信息应用系统大概率会继续迭代，未来免不了要接移动端、对外开放接口，如果一开始就前后端耦合，改造代价会非常大。

所以第五版坚定选择前后端分离：前端负责交互渲染，后端专注数据服务和业务逻辑，通过标准 REST API 通信。这样做的好处很直接——前端和后端团队可以并行开发，后端接口写单元测试不依赖页面，前端联调时也能快速定位是接口问题还是渲染问题。

2.2 后端与前端框架的取舍

后端我选的是 Spring Boot 3.x 配合 MyBatis Plus，原因不复杂：Java 生态成熟，招人容易，出现问题能找到的解决方案最多。Spring Boot 自带的生产级特性（健康检查、配置管理、内嵌容器）可以让部署变得非常省事。MyBatis Plus 则简化了单表 CRUD，让我可以把更多精力放在业务逻辑上。

前端选 Vue 3 + Element Plus，没选 React 是因为团队里大部分人更熟悉 Vue 的写法，Element Plus 的中后台组件库非常契合“信息管理”这类系统，表格、表单、弹窗、树形控件开箱即用。UI 风格上采用了极简策略：不做花哨的动效和图表，一切以信息密度和操作效率为优先。

下面是一段典型的前端查询表单代码，可以看到整个设计思路就是“把筛选条件塞进一个地方，后端统一接收处理”：

<template> <el-form :model="queryParams" inline> <el-form-item label="关键词"> <el-input v-model="queryParams.keyword" placeholder="编号/标题/责任人" clearable /> </el-form-item> <el-form-item label="状态"> <el-select v-model="queryParams.status" clearable> <el-option label="草稿" value="draft" /> <el-option label="生效中" value="active" /> <el-option label="已归档" value="archived" /> </el-select> </el-form-item> <el-form-item label="所属部门"> <el-tree-select v-model="queryParams.deptId" :data="deptTree" check-strictly /> </el-form-item> <el-form-item> <el-button type="primary" @click="handleSearch">查询</el-button> <el-button @click="handleReset">重置</el-button> </el-form-item> </el-form> </template>

2.3 数据库选型与核心表设计

数据库用的 MySQL 8.0，选它没有悬念：稳定、免费、团队熟。但真正考验设计能力的是表结构和索引。

核心表info_main的简化结构如下：

CREATE TABLE `info_main` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键', `info_code` VARCHAR(64) NOT NULL COMMENT '信息编号', `title` VARCHAR(255) NOT NULL COMMENT '标题', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '状态: 0草稿 1生效 2归档', `owner_dept_id` BIGINT NOT NULL COMMENT '归属部门ID', `owner_user_id` BIGINT NOT NULL COMMENT '责任人ID', `summary` TEXT COMMENT '内容摘要', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `deleted` TINYINT NOT NULL DEFAULT 0 COMMENT '逻辑删除', PRIMARY KEY (`id`), UNIQUE KEY `uk_info_code` (`info_code`), KEY `idx_owner_dept` (`owner_dept_id`, `status`), KEY `idx_create_time` (`create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='信息主表';

这里有个关键点：owner_dept_id和status建了联合索引，因为业务上最常见的查询就是“某部门下所有生效中的信息”。如果只给owner_dept_id建单列索引，排序和过滤时会比较吃力。

信息编号info_code采用业务规则自动生成：字母前缀 + 年月 + 四位流水号，例如INF202506001。生成逻辑用数据库锁表防止并发重复，虽然有人觉得这样性能不行，但对于内部系统的写入频率来说完全够用，而且保证编号唯一性比单纯追求并发更有价值。

2.4 权限模型：RBAC 与数据权限的配合

很多系统做到最后失控，不是代码问题，而是权限模型没设计好。第五版采用 RBAC 为基础模型：用户关联角色，角色关联权限点，菜单按钮级别控制。

但光有 RBAC 不够，因为“能看到哪些信息”和“能操作哪些功能”是两个维度。举例来说，人事专员和部门文员可能都有“查询信息”的功能权限，但前者应该能看到全公司信息，后者只能看到自己部门的信息——这就是数据权限。

数据权限的实现有两种常见方案：一种是前端根据部门过滤，简单但不安全；另一种是在后端 SQL 层面强制拼接权限条件。第五版选了后者，在每个查询接口的 Mapper 层自动追加数据权限片段。具体实现通过自定义 MyBatis 拦截器完成，根据当前登录用户的角色解析允许访问的部门范围，再拼入查询条件，这样即使前端被绕过，数据也拿不走。

3. 核心功能模块的落地实现

3.1 用户与权限模块：认证、鉴权、会话管理

认证采用 JWT + Redis 方案：用户登录成功后签发 token，token 里只放用户 ID 和过期时间，不塞业务信息，避免 token 体积过大；用户详细信息每次从 Redis 缓存读取，缓存过期后回源数据库。

这里想特别强调一个点：JWT 是“无状态”的，但有状态的信息（比如用户的角色变了）需要额外机制处理。第五版的做法是在 Redis 里维护一个session:user:{id}的数据结构，存用户当前的权限版本号。每次请求拦截器维护并对比版本号，一旦角色变更，版本号递增，旧 token 立即失效。这样既保留了 JWT 的扩容优势，又解决了权限即时回收的问题。

单表设计上，用户、角色、菜单是三张基础表，用户-角色、角色-菜单是两张关联表。没有把菜单直接挂在用户头上，是因为多人共用一个角色时，调整权限只需要改角色。

3.2 信息台账模块：业务字段的灵活处理

台账模块是系统的心脏，但最复杂的不是“增删改查”本身，而是业务字段的灵活性。各个部门填的信息差异很大：资产类的要填型号和购入日期，制度类的要填文号和生效日期，项目类的要填预算和负责人。

为了不每加一种类型就改一次表，第五版设计了“通用字段 + 扩展 JSON 字段”的组合方案。通用字段如标题、编号、状态、部门、时间等进主表；业务特殊的字段统一存入一个 JSON 字段里。查询时如果需要按扩展字段过滤，使用 MySQL 的 JSON 函数处理，数据量超过十万以后考虑引入搜索引擎，现阶段完全够用。

这种方案的最大的好处是“改业务不动表”，但代价是团队约定必须很清晰：JSON 里能存哪些 key、每个 key 的类型是什么、哪些 key 必须填写，都要在文档里写死，并且在代码里做校验。我在这个项目里专门写了一个字段配置模块，允许管理员在界面上配置扩展字段，然后代码按配置动态渲染表单和校验规则，才算真正把灵活性落地。

3.3 全文检索与查询优化：让信息真正“找得到”

“信息找得到”是信息应用系统最基础也最难做好的环节。如果用户搜半天搜不到东西，系统口碑立刻崩塌。第五版采用了三种检索策略叠加：

• 精确匹配：主表编号、责任人、状态等结构化字段，走普通 SQL 查索引，适合“已知编号”的确定性搜索。
• 模糊匹配：标题和摘要通过LIKE '%keyword%'查询，但因为使用前模糊不命中索引，数据量上来后会越来越慢。
• 分词检索：正文内容通过分词索引方案处理，先维护一张分词字典，把内容切成有意义的关键词再建索引，能支持相关性排序。

实际开发中，如果数据量在几万条级别，方案二加一个覆盖索引已经足够；超过十万条，建议直接引入成熟的搜索引擎组件。不要一开始就上重型中间件，系统的复杂度和运维成本会成倍增加。

更重要的经验是“搜索结果页的设计”——用户真正关心的往往不是匹配了多少条，而是第一条是否命中。因此排序规则里，生效中的信息权重必须高于草稿，最近更新的必须高于陈旧信息，这样用户搜出来的内容相关度才会符合直觉。

3.4 审批流与状态机：把“人催人”变成“系统催人”

信息应用系统里最容易让人吐槽的就是审批流程跑不通。第五版没有用通用流程引擎，因为业务场景相对固定：信息提交、部门审核、领导审批、归档，最多再加上退回和撤回。用状态机可以表达得很清楚，没必要引入重量级工作流中间件。

状态机的核心是一个“状态 + 事件”的二维矩阵：当前状态决定下一步能触发什么动作，触发动作后跳到哪个新状态。例如草稿状态可以被提交，但不可被归档；审核中可以被通过或退回，但不可被编辑。

实现上，我把状态流转规则放在一张配置表里，后台管理员可以调整状态流向，不用改代码。每次状态变更记录一张操作日志，内容包括操作人、操作时间、原状态、目标状态、意见说明，形成完整审计轨迹。

这里有个第五版重点解决的问题：审批流里的超时提醒。以前没有提醒，流程卡在某个节点好几天没人管，业务人员只能打电话催。第五版加了一个定时任务，扫描超过设定时间未处理的节点，自动推送站内信和邮件提醒。上线后流程平均处理时长从原来的 3.2 天降到了 1.1 天，这是整个系统最直观的价值体现。

3.5 报表与导出：不卡死、不跑偏

统计报表模块最开始我以为很简单，不就是 SQL 查一查、图表画一画。真正开发后才发现，难点在于大数据量导出的内存控制和多维度汇总的查询效率。

第五版在导出功能上做了两个优化。第一，数据查询采用流式读取，边读边写 Excel，不把所有数据一次性装载到内存，否则数据量一大内存就爆。第二，导出任务异步化，用户点击导出后立即返回“文件生成中”，后台线程执行完成后推送下载链接，用户不需要一直盯着页面等待。

汇总报表的实现上，优先在 SQL 层面做GROUP BY聚合，而不是把明细取回来再用 Java 内存计算。一个是千万级数据也能轻松处理，另一个是十万级数据就可能 OOM。我见过太多人图省事，最后在生产环境被数据量教做人了。

4. 从零到上线的实操流程记录

4.1 环境搭建与项目初始化

开发环境建议统一版本号，团队内不要存在差异。第五版使用的关键版本如下：

• JDK 17
• Spring Boot 3.2.x
• MySQL 8.0.x
• Redis 7.x
• Node.js 18+
• Vue 3.4.x

初始化项目时我最推荐的做法是：后端用 Maven 多模块工程，按common、system、business、api分包；前端按views、api、store、router划分目录。后续开发时职责清楚，不会出现一个人改代码全项目都受影响的情况。

后端配置文件的敏感信息写入application-prod.yml，并使用占位符引用环境变量：

server: port: 8080 spring: datasource: url: jdbc:mysql://${DB_HOST}:${DB_PORT}/${DB_NAME}?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: ${DB_USER} password: ${DB_PASSWORD} redis: host: ${REDIS_HOST} port: ${REDIS_PORT}

4.2 数据库初始化与数据迁移

数据库初始化分三步：建库建表、初始化基础数据（角色、菜单、字典）、迁移历史数据。

第五版的数据迁移是最费劲的一环，因为前四个版本的数据散落在不同的 Excel、Access、甚至纸质台账里。我的经验是绝不要手动录数据，一定要写一次性迁移脚本，并且做幂等设计：重复执行不会产生重复数据。

迁移脚本的核心逻辑：

public void migrateOldData() { // 1. 读取旧数据源 List<LegacyInfo> legacyList = legacyInfoMapper.selectAll(); // 2. 逐条转换，写入新表 for (LegacyInfo legacy : legacyList) { InfoMain info = new InfoMain(); info.setInfoCode(generateInfoCode(legacy.getType(), legacy.getDate())); info.setTitle(legacy.getTitle()); info.setStatus(convertStatus(legacy.getStatus())); // 将旧表描述字段统一放入扩展JSON info.setExtJson(buildExtJson(legacy)); infoMainMapper.insert(info); } }

迁移后必须做数据校验，比如对比总条数、抽样比对字段值、检查编号是否有重复。我是用 SQL 写校验脚本操作的：统计新表数量、按部门统计分布情况、抽查当年数据核对明细，全过了才开放生产环境访问。

4.3 部署上线与服务器配置

第五版部署采用单机 Docker Compose 方案，一台 4核8G 的服务器足以应对几百人同时使用。容器编排包括 nginx（前端静态资源 + 反向代理）、后端服务、MySQL、Redis 四个角色。

这里给出关键的 nginx 配置片段，重点是前端路由的try_files处理和 API 的代理转发：

server { listen 80; server_name your-domain.com; # 前端静态资源 location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } # 后端 API 反向代理 location /api/ { proxy_pass http://backend:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_read_timeout 120s; } }

上线前我强烈建议做四件事：压测（哪怕用简单脚本也好）、备份演练、监控告警配置、回滚预案。第五版上线当天我特意实测了并发登录、大批量查询、报表导出三个高风险场景，确认没有明显性能瓶颈后才让业务方开始正式使用。

4.4 备份与运维：平时不觉得，出事才重要

信息应用系统最怕数据丢失，备份策略必须提前定好。第五版采用的是每日全量备份 + 每小时 Binlog 增量备份的组合方案，备份文件保留30天，异地再存一份。

备份脚本核心命令：

#!/bin/bash # 每日凌晨3点执行 mysqldump -u backup -p'password' \ --single-transaction --quick --routines \ infosys > /backup/mysql/infosys_$(date +%Y%m%d).sql # 同步到异地备份服务器 rsync -avz /backup/mysql/ backup-server:/backup/infosys/

运维监控上，至少要盯三个指标：CPU 使用率、内存使用率、数据库连接数。别等到用户反馈“系统卡顿”才去查，主动观察指标能提前发现很多隐患。

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

5.1 高频问题速查表

下面是这套系统上线半年内遇到的最典型的几类问题，我把现象、原因和解决方案整理成了一张速查表：

5.2 一个典型的“缓存穿透”排查案例

第五版上线后遇到过一个非常隐蔽的问题：某个查询接口平时很快，但偶尔会突然变慢到十几秒。查了半天发现是缓存穿透——某个不存在的编号被反复查询，每次查询都无法命中缓存，全部打到数据库上。

我们平时做缓存都是“先查缓存，查不到再查数据库”，但如果查询的 key 是一个不存在的值，数据库也不会把结果写入缓存，那么每次同样的查询都会穿透缓存。攻击者如果构造大量不存在的编号，很容易把数据库打垮。

解决方案很经典：对于查询结果为空的 key，也缓存一个空值占位，并设置较短的过期时间（比如3分钟）。这样同样的请求在第一分钟查完数据库后，后续三分钟内都会直接命中空值缓存，不再穿透到数据库。同时配合布隆过滤器做前置拦截，把绝大部分不存在的 key 挡在 Redis 之前，系统压力骤降。

5.3 权限“越权”问题：很隐蔽也很致命

系统上线后第三周，某管理员反馈说，他能看到不属于自己部门的一条敏感信息。排查后发现问题是 MyBatis 拦截器里的数据权限 SQL 拼接，在某种多表关联场景下丢失了权限条件。

具体原因是：MyBatis 拦截器默认只拦截以select开头的方法，但有一个统计查询方法叫summaryByDept，不满足匹配规则，权限条件就没拼进去。也就是说，我们预想中的“所有查询都强制加数据权限”并没有覆盖全部查询入口。

这个教训非常深刻。修复时我在拦截器规则里加入了更具体的匹配逻辑，把统计类的查询方法名纳入拦截范围，同时做了一轮全量代码审查：所有 Mapper 方法逐个核查，确认没有遗漏权限约束的路径。我建议你在做同类系统时，不要依赖拦截器的“约定”，一定要有权限自测用例覆盖到每个查询接口。

5.4 一个容易被忽视的时区与编码问题

第五版开发时，有几个同事反馈说导出的 Excel 时间比数据库时间晚了8个小时。问题出在 JDBC 连接的serverTimezone=UTC，MySQL 服务器时区是亚洲标准时间，两边标准不一致，结果就出现了偏移。

这种问题排查起来并不难，但特别容易被忽视。我的建议是：

• 数据库连接串里的serverTimezone必须明确写Asia/Shanghai，不要用 UTC。
• Java 应用启动时统一指定时区，命令行加上-Duser.timezone=Asia/Shanghai。
• 前端展示时间时用统一的格式化工具，不要每个组件单独格式化。

另外一个隐藏的坑是字符集。建表时必须设定utf8mb4，而不是utf8，因为前者才能正确保存生僻字和表情符号。信息应用系统迟早会遇到特殊字符，提前规避总比事后清洗数据轻松。

6. 一些想单独说说的实操心得

6.1 配置管理远比想象中重要

第五版做到一半时，我把系统配置从数据库表里拆分成“配置中心 + 配置表 + 本地配置”三层。原因是初期图省事，把一些业务开关直接写在配置文件里，结果改一个开关要重新发版，效率极低。后来把所有运行期可以调整的参数（比如审批超时天数、报表统计口径、导出单次上限）全部纳入后台配置模块，运营同学自己就能改，不再依赖开发。

但配置多了也有问题，有些配置存在冲突。比如报表统计口径里，有人设了“按创建日期统计”，另一个人设了“按生效日期统计”，两种口径导出的数字对不上，业务方会吵。最终我想了个笨办法——每个统计配置绑定一个版本号，导出报表时会同时输出统计口径说明，让看报表的人知道这个数字是怎么算出来的，争论自然就少了。

6.2 日志规范的价值在关键时刻才体现

系统上线后总会遇到问题，最怕的是问题重现时查不到日志。第五版从第一天就强制约定了日志规范：

• 每次请求生成一个traceId，从头到尾贯穿网关、服务、DAO 层。
• 业务关键操作（提交、审批、导出、修改权限）记录操作日志，包含操作人、时间、参数摘要、结果状态。
• 异常日志必须包含上下文信息，例如“用户ID + 操作类型 + 具体参数”，不能只打一个NullPointerException。

曾经有一次用户反馈“某个审批通过了但状态没更新”，我靠 traceId 一路查到 SQL 执行记录，发现事务没有正确提交，十分钟就定位了根因。如果没有日志规范，这类问题可能得排查好几个小时。

6.3 别忽视“人”的因素

最后说一个和技术无关但决定系统成败的点：内网系统最大的阻力往往不是技术，而是用户习惯。功能再完善，如果用户不愿意用、不按预期用，系统就白做了。

第五版上线前，我特意做了三件事：给关键用户做一对一的演示培训，编写简单明了的操作手册，建立问题反馈群并承诺2小时内响应。上线第一个月，每天都会收到大量咨询和反馈，我坚持逐条回复，并挑出高频需求快速迭代。一个月后，反馈量明显下降，系统使用率稳定在预期水平。

6.4 这个项目之后，我最大的感悟

做完这套 No.5 信息应用系统之后我最大的感悟是：信息系统的复杂度永远不在技术，而在对业务细节的理解和对变化的管理。技术选型、代码架构都相对好解决，真正考验功夫的是你能否把每个模糊的表述翻译成清晰的功能，把每个意外的情况兜住，把每个用户的抱怨转化为迭代的输入。

如果你正在规划自己的信息应用系统，我的建议很简单：先定义清楚“哪些信息必须被管理”“谁有权限看哪一层数据”“哪些操作必须有记录”，把这三件事想透了，系统的骨架自然就清楚。技术细节都可以边做边补，但这三条主线在一开始定偏了，后面返工的代价非常大。

最后分享一个小技巧：状态机定义和权限矩阵，一定要画成图并贴到项目文档最前面。每次讨论需求有分歧时，回到这两张图上对齐认知，能省去大量无效沟通。祝大家在自研系统的路上，少踩一些我已经踩过的坑。