企业官网建设流程全解析

1. 业务场景与系统边界

1.1 风险报告管理到底管什么

很多人看到“数字科技风险报告管理系统”这个题目，第一反应是“这不就是个CRUD嘛”。其实如果只是做增删改查，随便找个脚手架两三天就能交差，但这恰恰是这类课题最容易翻车的地方——评委或者导师真正想看的，不是界面多炫、代码多花哨，而是你对业务场景有没有理解，对流程闭环、权限控制、状态流转这些细节有没有想清楚。

先把这个系统拆开看。“数字科技”是业务背景，“风险报告”是核心对象，“管理系统”才是载体。放在真实业务里，它解决的是这样一个问题：一个组织每天会收到大量来自业务线、技术团队、外部合作方的风险信号，比如某个服务存在安全隐患、某个合作方出现经营波动、某条业务链路有合规隐患。这些信息需要被记录、被分级、被指派处理人、被跟踪闭环，最终形成可供管理层决策的统计数据和归档报告。如果没有系统，这些工作全部依赖邮件、Excel、聊天记录，信息散落、状态模糊、追责困难。

所以这个系统的核心不是“增删改查”，而是围绕“风险报告”这个对象建立起一条完整的生命周期管理链路。从报告的填报录入开始，经过审核、指派、处理、复核、归档，每一环都要有明确的操作人、状态标记和时间记录。这就是业务核心，也是设计重点。

1.2 角色体系与流程闭环

一个合格的风险报告管理系统，必须回答清楚“谁能做什么”。我见过很多学生项目在权限上只做了简单的管理员和普通用户区分，结果报告流转起来之后，谁都能改状态、谁都能删记录，整个流程形同虚设。实际上，哪怕是最小可用的版本，也至少要划分四类角色。

普通填报人负责提交风险报告、补充材料、查看自己提交的报告进度。部门审核人负责对进入本部门的报告做初审，判断风险是否真实、等级是否合理，给出审核意见。风险处理人负责对被指派的报告进行处置，记录处理过程和处理结果。系统管理员负责用户维护、基础数据配置、全局数据查看，但管理员不应该有权限去随意修改业务报告的内容和状态，否则审计链路就断了。

围绕这四类角色，一条完整的业务闭环是：填报人提交报告，系统自动生成待审核任务；审核人通过或者驳回，驳回的报告回到填报人手里修改再提交；审核通过的报告进入待指派池，由部门负责人或管理员指派给处理人；处理人开始处理后更新处理进度，完成后提交复核；复核通过后报告进入归档状态，后续只能查看和统计分析。

别小看这个流程设计。它决定了你的数据库表结构、状态枚举设计、接口权限校验方式，甚至前端按钮的显隐逻辑。如果一开始不把流程图想清楚，写到一半再补状态，基本就是推倒重来的节奏。

1.3 功能模块拆分与优先级

把业务闭环落到功能模块上，按照重要程度排个序，大概是这样的：用户认证与权限管理、风险报告的全生命周期管理（包括增删改查、提交、审核、指派、处理、复核、归档）、附件上传与预览、数据统计看板、消息待办提醒、操作日志审计。

很多人喜欢一上来就堆功能，把轮播图、地图、聊天室这种和业务无关的东西塞进去凑数量。这是做课题的大忌。作为从业者，我的建议是先把主链路打通，再考虑辅助功能。主链路就是“报告发起-审核-处理-归档-统计”，辅助功能里优先级最高的是消息待办提醒，因为它能体现你对“用户会忘记处理”这个真实痛点的理解；其次是操作日志，因为在风险场景下，审计追溯是硬需求。

2. 技术选型与架构设计

2.1 为什么是Spring Boot，而不是其他框架

题目已经限定用Spring Boot，但限定不代表不用思考。很多人在写文档的时候只会写“Spring Boot简化了配置、提供了自动装配”，这太表面了。说白了，在这个场景下用Spring Boot是最稳妥的选择，柔性切换、生态成熟、资料好找、部署方便，大量的业务系统都是基于它构建的。对于课题类项目，团队协作成本低，遇到问题随手百度就有答案，这本身就是巨大的效率优势。

更重要的是，Spring Boot对快速构建RESTful API非常友好。风险报告管理系统的核心交互模式，就是前端页面调后端接口传JSON数据。Spring Boot配合Spring MVC，Controller层写起来非常直接，参数校验、统一异常处理、拦截器配置都有标准答案。这些能力在真实项目里就是效率和稳定的保障。

与之相对，有人可能会提SSH（Spring + Struts + Hibernate）或者Spring MVC + JSP，这些技术老归老，但用它们实现前后端分离非常别扭。还有人说用Spring Cloud全家桶，那对课题类项目来说明显过度设计，引入注册中心、网关、配置中心之后，光排查环境问题就够写一篇论文了。记住一个原则：技术选型的核心是“够用、可控、能说清楚”，而不是“越多越高级”。

2.2 关键组件搭配方案

Spring Boot 本身解决的是“骨架”问题，一个完整的系统还需要配套组件。下面是我在实际搭建过程中验证过的一套组合，可以直接参考。

• 持久层框架：MyBatis-Plus。选它不是因为它的性能比原版MyBatis好，而是因为它内置了BaseMapper和分页插件，能让CRUD代码量骤减。风险报告系统的列表页通常有多个筛选条件（风险等级、状态、报告类型、时间范围），直接用MyBatis-Plus的LambdaQueryWrapper封装条件，比手写大量XML要快得多，也少踩很多SQL拼接的坑。

• 数据库：MySQL 8.x。隔离级别选默认的RR（可重复读）即可，配合事务管理保证审核、指派这类写操作不会出现半成功状态。数据库连接池用HikariCP，Spring Boot 2.x以后是默认集成，配置几个核心参数就够了。

• 缓存与登录态：Redis。用Redis存用户的Token，设置过期时间，实现登录态统一管理。顺便还可以把风险等级的字典数据、整体统计结果写入缓存，减轻数据库压力。如果不想引入Redis，用JWT + 本地存储也能跑，但缺点是退出登录和强制下线很难实现。我在后面第4节会详细说。

• 文件存储：本地存储 + 访问路径映射，或者OSS。课题项目一般没有独立文件服务器，本地磁盘存储配合配置映射路径是最实际的方案。附件上传在风险报告场景里很常见，比如截图、扫描件、处理记录文档，把文件路径存进数据库，文件本体放服务器目录，用完即走。

• 前端框架：Vue 3 + Element Plus + Vite。Element Plus的表格、表单、弹窗组件非常契合后台管理系统的界面需求，不需要自己重造轮子。用Axios做接口请求，用Pinia管理用户状态，用vue-router做菜单路由和权限控制。

2.3 工程结构到底怎么分

我见过把Controller、Service、Mapper三层分完就觉得自己“结构清晰”的项目，然后ServiceImpl里面塞了上千行业务代码。这种代码前期写着爽，后期改需求的时候心态直接爆炸。对于风险报告这种业务流程复杂、状态多的系统，我建议在经典三层基础上增加一层“Manager”或者“策略层”，专门处理状态流转和复杂业务编排。

按功能模块分包也是一种做法，但容易被各个模块的互相引用把依赖搞乱。我更推荐按“层 + 业务模块”两者结合的思路。controller里面只做参数接收和结果包装，service里面做具体业务逻辑，mapper里面只是数据访问。涉及状态机判断、多人协作流程的判断，单独抽出一个WorkflowService来处理，这样代码的定位才清晰。

工程命名上建议用统一的风格，比如com.xxx.risk，下面再拆controller、service、mapper、entity、dto、vo、config、common。写课题项目的时候这种分法特别好解释，答辩时也容易讲清楚“我为什么这么分层”。

3. 数据库设计与关键表结构

3.1 用户与权限模型

数据表是系统的地基。风险报告系统涉及多角色、多机构、多层级的业务场景，用户和权限必须设计得扎实。最常用的方案是RBAC模型，也就是“用户-角色-权限”三层结构。对应到数据表上就是sys_user、sys_role、sys_user_role、sys_role_menu四张表。

sys_user里面除了用户名、密码，建议加上真实姓名、所属部门、联系电话、状态字段。所属部门这个字段在风险报告按部门统计时是重要的维度，没有这张表后面做统计就很尴尬。密码字段统一用BCrypt加密存储，这几乎是Spring Security生态里的标配，加密后的字符串长度是60，设计字段时别只留32位。

sys_role和sys_user_role表负责把角色和用户关联起来。这里有同学可能会问，是不是直接在sys_user表里加一个role字段，取个1、2、3标识管理。能跑但是不推荐。一旦后续要求“一个人既是填报人又是处理人”，单字段设计就崩了。多对多设计看着麻烦，实际上一张关联表解决所有问题，扩展性和表达能力完全不同。

3.2 风险报告主表设计

风险报告主表是整个系统的核心，命名为risk_report就够直白。关键字段我用一张表列出来，方便直接对着做。

有几个点需要特别注意。第一是report_no生成规则，建议用“RP + 年月日 + 当天自增序号”的方式，比如RP20260612001。这个编号要在定时任务或者插入时生成，重复必须避免。第二是状态相关的外键字段，很多同学会用“当前状态 + 点击按钮”这种方式控制流程，但状态字段只记录当前值还不够，你必须同时记录是谁做了这个动作。这就是为什么表里既有handler_id又handle_time，细节之处才是答辩的加分点。

第三是del_flag，逻辑删除而不是物理删除。风险报告是具备审计性质的业务数据，物理删除了就再见不到任何痕迹，这在真实场景里是不可能被接受的。所有查询默认带上del_flag = 0条件。

3.3 状态字段与流转记录拆分

状态字段current_status只是当前的一个快照，它解决的是“现在是什么状态”的问题，但“怎么走到这个状态的”就必须靠流程记录表来回答。我建议单独建一张risk_report_flow表，字段包括id、report_id、from_status、to_status、operator_id、operator_name、operation_type、comment、create_time。

这张表的作用有三个。第一是可追溯，任何一个报告都能查出来经历过哪些环节、谁在什么时候操作了、当时的意见是什么，这在答辩时直接展示给评委看，效果比任何功能截图都好。第二是支撑统计，比如统计“各环节平均消耗时长”，直接对这张表做时间差计算就行。第三是提高写代码的容错度，状态机出问题时可以通过flow表复盘修复，而不是对着主表猜来猜去。

3.4 附件表和统计辅助设计

附件表risk_report_file相对简单，核心字段是report_id、file_name、file_path、file_size、upload_user_id、upload_time。文件路径统一保存相对路径，避免把服务器绝对路径写进数据库，这样换环境部署的时候不会出乱子。

统计功能方面，不建议在业务主表上直接做复杂聚合分析，会增加主表的查询压力。稳妥的做法是给风险类型、风险等级、状态、部门这些维度建必要索引，统计查询直接走单表GROUP BY。如果要做多类型的趋势分析，比如近12个月各类型风险数量变化，可以额外建一张risk_report_stat_daily的统计表，每天定时任务把前一天的数据按日、类型、等级聚合一次，页面查这张表效率极高。

4. 核心后端模块落地实操

4.1 登录认证与接口权限拦截

用户认证这块，我推荐“Spring Security + JWT + Redis”的组合。Spring Security负责认证框架，JWT负责生成无状态Token，Redis负责记录Token有效期和实现注销。

登录流程是：用户提交用户名密码，后端用BCryptPasswordEncoder校验密码，通过后生成一个Token，Token里建议只放userId和用户名这样非敏感信息，不要一股脑把角色权限全塞进去。然后把Token以userId为key存入Redis，设置过期时间，同时把这个userId返回给前端。前端后续每次请求在Authorization请求头里带上Token，后端通过拦截器解析Token、取出userId、再校验Redis里是否存在且未过期。

接口权限用拦截器或者Spring Security的注解都行。为了简单，可以在HandlerInterceptor里判断每个请求的路径前缀，比如/api/report/create要求登录状态，/api/report/audit要求审核人角色，/api/report/delete要求管理员角色。这里的关键不是做了多少校验，而是你明确区分了“未登录不能访问”“登录但角色不符不能操作”两种校验粒度。真实的演示过程里，很多同学只会测“不登录就弹回登录页”，完全没有验证越权访问，结果现场被评委用一个低权限账号直接调用审核接口，场面很难看。

登录逻辑的核心代码大致这样：

public String login(LoginDTO dto) { // 1.查询用户是否存在、状态是否正常 User user = userMapper.selectByUsername(dto.getUsername()); if (user == null || !BCryptPasswordEncoder().matches(dto.getPassword(), user.getPassword())) { throw new BizException("用户名或密码错误"); } // 2.生成JWT Token，payload只存userId和username String token = JwtUtil.generateToken(user.getId(), user.getUsername()); // 3.存入Redis，设置过期时间（比如8小时） redisTemplate.opsForValue().set(Constants.TOKEN_PREFIX + user.getId(), token, 8, TimeUnit.HOURS); return token; }

拦截器里面校验的逻辑是，从请求头拿到Token，解析出userId，然后在Redis里查一下有没有这个Key，如果key不存在说明Token过期或者被注销了，直接返回401。这里有个小坑要提醒：Redis的Key别设计成只有token，因为用户换端登录或者多端登录很难管理。我在项目里用userId作为Key，value是token，这样强制下线的时候直接删Key就行。

4.2 风险报告状态机与流程控制

状态机是这个系统里分量最重的部分。我强烈建议不要在Service里面随便写几个if else就改状态，而是先把所有状态和允许的流转关系写成一个枚举或者独立的常量类。

状态设计如下：待审核 -> 审核通过 / 已驳回 -> 待指派 -> 处理中 -> 待复核 -> 已归档，另外加一个已关闭用于处理无效风险。

每个状态能做的操作是明确限定的。比如“待审核”状态下只能做“审核通过”和“驳回”，“已驳回”状态下只能做“重新提交”，“处理中”状态下只能做“提交处理结果”，“待复核”状态下只能做“复核通过”或者“退回处理”。做这个限制的核心目的，是防止用户通过伪造请求跳过环节。很多系统出问题就是状态不受控，随便一个接口都能把状态改了，流程彻底失去意义。

实现上，最简单的方案是写一个StateMachine类，内部维护一个Map，key是当前状态，value是允许的操作列表和操作后的目标状态。每次更新前先校验当前状态是否允许该操作，再把主表状态更新为目标值，同时往flow表里插入一条流转记录。这套东西写起来不复杂，但能给你带来两个好处：代码结构清楚、答辩时能讲出“如何保证流程不被绕过”这种有深度的问题。

一个比较典型的状态变更方法示意：

public void audit(Long reportId, Long auditorId, boolean approved, String comment) { RiskReport report = reportMapper.selectById(reportId); // 核心校验：当前状态必须是待审核 if (!Objects.equals(report.getCurrentStatus(), RiskStatus.WAIT_AUDIT)) { throw new BizException("当前状态不允许审核操作"); } String targetStatus = approved ? RiskStatus.APPROVED : RiskStatus.REJECTED; // 更新主表状态和审核字段 report.setCurrentStatus(targetStatus); report.setAuditUserId(auditorId); report.setAuditComment(comment); report.setAuditTime(new Date()); reportMapper.updateById(report); // 写入流转记录 flowMapper.insert(FlowRecord.build(reportId, RiskStatus.WAIT_AUDIT, targetStatus, auditorId, comment)); }

4.3 报告提交与附件上传实现细节

新建报告时，前端会同时提交业务字段和附件。附件上传建议先走单独的文件上传接口，文件先落盘、拿到文件ID或者路径，然后再提交表单时把文件ID列表随表单一起提交。这样做的好处是，用户即使填表填了一半想关掉浏览器重新打开，已上传的文件不会被丢失，体验比表单和文件一起提交要好很多。

文件上传的接口处理要注意几个点。一是文件名统一用UUID重命名，避免中文乱码和重名覆盖。二是限制单个文件大小，建议在Spring配置里设置max-file-size为10MB，同时限制允许的扩展名类型，比如jpg、png、pdf、docx，防止被上传可执行脚本。三是文件保存的目录结构按月份分目录存放，比如upload/2026/06/这种结构，后续整理归档的时候很方便。

上传后把文件相对路径、文件名、大小、上传人、所属报告ID保存到risk_report_file表。如果报告还没有创建，可以先传一个临时reportId，等待表单真正提交后再更新关联。

4.4 统计看板与组合筛选

统计看板是这个系统比较出彩的功能，我建议做三个维度的统计：整体概览（报告总数、待处理数、已归档数、本周新增数）、按风险等级分布、按风险类型分布。这些统计数据可以在Controller里直接用Mapper写聚合查询。

一个典型的统计方法是写一个VO类，里面放name和value两个字段，返回给前端之后前端用饼图或柱状图直接渲染。比如按等级统计：

SELECT risk_level as name, COUNT(*) as value FROM risk_report WHERE del_flag = 0 GROUP BY risk_level

列表页的组合筛选是另一个高频需求。建议查询条件包括：报告编号、标题关键字、风险类型、风险等级、状态、填报日期范围、填报人。MyBatis-Plus的LambdaQueryWrapper写起来最顺手，所有条件用optional去判断是否拼入查询，避免空条件导致的SQL异常。分页的话直接用内置的Page对象，记得开启分页插件配置。

5. 常见问题排查与避坑实录

5.1 前端联调阶段的跨域问题

后端和前端分开启动的时候，浏览器会拦截跨域请求，这是联调阶段遇到最多的bug。解决方案是在后端加一个全局CORS配置类，放行前端地址。配置时要特别注意allowedOriginPatterns不要写成allowedOrigins通配符加cookie的模式，否则浏览器会直接报错。

需要同时注意一个隐性坑：如果登录用的是JWT并在请求头传Token，那么在后端CORS配置里必须allowHeader里加上Authorization。否则前端带着Token发起请求，后端在处理预检OPTIONS请求时照样返回不允许，前端就看着接口一直报跨域。这个问题的排查思路很简单，浏览器F12看到报错信息里出现CORS字样，优先去检查是不是预检请求被拦截了。

5.2 状态并发更新与重复提交

风险报告系统是多用户同时在线的场景，很容易出现两个审核人同时审核同一份报告的情况。比如A审核通过了，B紧接着也提交了驳回，这样后提交的会把前一个人的审核结果覆盖掉。这就是并发更新的典型问题。

解决办法有两个层面。代码层面，在更新SQL里带上状态条件，比如UPDATE risk_report SET current_status = '审核通过' WHERE id = ? AND current_status = '待审核'，如果受影响行数为0，说明状态已被别人改过，直接提示“该报告已被处理”。这样能在数据库层面兜住并发。前端层面，提交审核或驳回按钮点击后立刻置为loading并禁用，防止连点造成两次重复请求。

5.3 附件访问404和乱码问题

文件上传成功了，但预览图片或下载文件的时候却404，十个项目里能遇到八个。排查路径很简单：先看文件是否真的传到了服务器目录，再看前端拼的访问路径和后端映射路径是否一致。比较稳妥的办法是在后端配置一个资源映射，把upload目录映射成虚拟路径。比如访问/upload/**时，实际到本地目录去取文件。配置这一层映射之后，前端只需要按相对路径拼接请求地址。

还有一个细节容易被忽略：下载文件的接口要正确设置Content-Type和Content-Disposition，否则浏览器下载下来的文件名全是乱码。建议对文件名做一次URL编码，用URLEncoder.encode处理后再拼接到响应头里。

5.4 时间处理与跨日统计问题

后端返回时间给前端，默认可能会是UTC格式或者带时区偏差。我的建议是统一用一个Jackson配置类，把时间序列化格式固定成"yyyy-MM-dd HH:mm:ss"，同时在后端服务器设置时区为Asia/Shanghai。在做按日统计的时候，SQL里用DATE函数对时间字段截断到日即可。注意不要在Java层到处用SimpleDateFormat处理时间，线程安全问题不说，代码也会凌乱。

5.5 数据库连接池与初始化数据

还有一个低概率但很烦的问题：项目跑了一段时间后，页面偶发报数据库连接失败。多数情况下是连接池的空闲连接被数据库主动断开，而连接池没有及时回收。解决方案是在HikariCP配置里加上connection-test-query: SELECT 1，并且设置合适的max-lifetime值（一般建议小于数据库的wait_timeout）。这些参数看着不起眼，但真实用户访问的时候稳定性和体验差很多。

初始化数据方面，记得在启动时给sys_user表插入几笔测试账号，分别对应填报人、审核人、处理人和管理员，密码统一用BCrypt加密值。答辩演示的时候每次从登录开始就是浪费时间的表现，直接用预置账号进入系统，把时间留给核心流程演示，这是很实际的经验。

写在最后的几点实话

这类基于Spring Boot的管理系统，每年都有大量的人在写，真正拉开差距的往往不是某个炫技功能的实现，而是对业务细节的思考深度。你能不能在答辩时清晰回答“为什么状态不能随意修改”“为什么要有流转记录表”“为什么权限要拆成三张表”，比放多少页面截图都有说服力。我个人的经验是，写完主链路之后一定要站在一个用户的视角把流程从头到尾走一遍，特别是异常分支，比如被驳回之后重新提交、指派之后又换人处理，这些场景能走通，系统的完整性才算真正达标。另外，课题项目的代码可以不复杂，但命名必须规范、注释必须到位、异常处理必须统一，这些“工程素养”的细节在评分时占比往往超出很多人的预期。