企业官网建设流程全解析

基于SpringCloud+Layui+AI的微服务人力资源管理系统，是计算机毕业设计里综合度很高的一个选题。它不是一个简单的增删改查项目，而是把微服务架构、Layui后台管理界面、AI大模型应用放进同一个业务场景里，对Java后端方向的同学来说，既能体现工程能力，又能在答辩和面试时讲出亮点。

这套系统解决的是企业人事管理中的常见问题：人员信息分散、招聘流程繁琐、员工制度咨询重复、模块之间耦合严重。通过把组织、员工、考勤、薪资、招聘等能力拆成微服务，用Layui搭建统一管理后台，再把大模型接入智能问答和简历处理流程，整体看起来就像一个完整的“智能企业人力系统”。

如果你正在做这个毕设，或者准备拿它作为SpringCloud项目去准备面试，下面按我实际做项目的思路，把技术选型、环境准备、前后端联调、AI接入、论文整理和答辩讲解完整拆一遍。

1. 这个毕设项目到底在做什么

1.1 技术路线和系统定位

这是一个面向企业人力资源场景的管理系统，使用SpringCloud搭建微服务后端，使用Layui搭建后台管理页面，再通过接入AI大模型提供智能服务能力。

系统定位很清晰：给HR、部门主管、普通员工三类用户提供统一入口。HR负责员工信息维护、招聘、考勤和薪资管理；部门主管可以跟进团队人员和审批流程；普通员工可以查看工资条、发起请假申请、通过AI助手咨询制度问题。

技术路线上，最核心的三条线是：

• SpringCloud微服务：解决模块拆分、服务注册发现、网关路由、配置管理、服务间调用。
• Layui前端框架：用原生JavaScript风格快速搭建后台管理界面，不需要复杂的Node构建流程。
• AI大模型：接入通用大模型或本地部署模型，为系统增加智能问答、简历摘要、文档草稿生成等能力。

很多同学看到“AI+微服务”会觉得复杂，其实它的核心还是业务系统。AI是加分项，微服务是架构展示点，Layui是快速落地界面。把这三条线分开理解，项目就不乱了。

1.2 典型功能模块清单

从HR业务出发，功能模块至少要覆盖完整的人事管理闭环。

这里有个建议：毕设功能不要贪多。很多同学一开始想把在线培训、绩效360、人才盘点全做进去，结果代码量失控，论文也写不透。把一条主线业务做完整，比堆十个半成品模块更有说服力。

1.3 看这套项目你能学到什么

做这个毕设的价值，不只是“完成一个系统”，而是借项目把几块知识串起来。

第一，微服务不再停留在概念。自己动手拆服务、注册到Nacos、走网关、用Feign调用，比只看SpringCloud面试题深刻得多。

第二，前端Layui能快速出效果。基于jQuery的Layui对Java后端同学很友好，表格、表单、弹层、树形菜单都有现成组件，半天时间就能搭出后台框架。

第三，AI能力不是只能聊天。通过把大模型接入业务，你会理解Prompt设计、接口封装、超时处理、结果降级这些工程问题。面试时可以讲“我用大模型做过简历摘要和制度问答”，这是很好的项目亮点。

第四，完整工程习惯。统一返回结果、全局异常、日志记录、配置分类，这些在实际工作中比某个具体API更重要。

2. 微服务拆分和组件选型：先把架构图画明白

2.1 单体HR系统为什么要改成微服务

普通的HR系统用SpringBoot单体项目就能写。那毕设为什么选微服务？不是因为“必须用微服务”，而是要展示你对系统边界和分布式场景的理解。

单体项目的问题在于：所有代码放在一个工程里，部门、考勤、薪资、招聘相互引用，改一个模块可能影响另一个模块。业务一旦复杂，团队协作、独立部署、独立扩容都很难做。

微服务的思路是把不同业务拆成独立服务，每个服务可以单独开发、单独部署、单独扩展，服务之间用HTTP或消息通信。

在答辩时，老师大概率会问“你这个系统一定要用微服务吗”。你要能回答：虽然功能量不大，但微服务方式能把模块边界强制分开，让团队协作和部署更灵活；同时通过注册中心、网关、配置中心等组件，能感受到真实企业中大规模系统的治理思路。

不过也要承认，微服务带来了更多复杂度。如果只是学习，建议从4到6个核心服务起步，不要一上来拆十几个。

2.2 服务拆分方案

根据这个项目的业务，可以参考下面的拆分方式：

如果时间紧，可以合并成三个服务：auth+system合并为系统服务，org+attendance+salary合并为人事服务，recruitment+ai独立。合并后仍然保留微服务的调用关系，但开发量和部署复杂度会明显降低。

2.3 核心组件怎么选

SpringCloud生态里的组件很多，毕设不需要全用，选一套能讲清楚的组合就行。

这里要提醒：组件不是越多越好。比如Eureka+Gateway经典，但很多新项目已经转向Spring Cloud Alibaba。你选哪套都可以，关键是能说明白为什么选、组件之间怎么配合。

如果你参考若依微服务版，会发现它的模块划分非常成熟，可以直接借鉴，但代码量偏大，建议挑核心逻辑改成自己的项目。

3. 环境准备与项目初始化顺序

3.1 基础环境清单

开始写代码前，先把环境整理清楚。

如果你打算本地部署大模型，还要额外准备Ollama和开源模型。以Ollama部署本地大模型为例，一个7B模型至少需要8GB内存，量化版本可以在16GB内存的机器上跑，但响应速度没有云接口快。

原始材料里没有给出这些版本的明确约束，所以你落地时一定要以自己安装的版本为准。网上教程版本不一致导致启动失败的案例非常多。

3.2 数据库设计与初始化思路

数据库是毕设里的重点，答辩时很容易被问题表结构。

建议的核心表有：

• 用户表、角色表、菜单表、用户角色关联表
• 部门表、岗位表、员工表
• 考勤表、请假表、审批记录表
• 工资项表、工资条表
• 招聘职位表、简历表、面试记录表
• AI对话记录表

设计时先画ER图，再建表。部门表通过parent_id字段形成树形结构，员工表通过dept_id和post_id关联部门和岗位，工资条通过emp_id关联员工。

员工表是核心表，字段一般包括：工号、姓名、性别、手机号、邮箱、入职日期、部门ID、岗位ID、状态。

AI对话记录表容易被忽略，但它很重要。没有这张表，答辩时无法证明你的AI功能是真的和业务结合，也说不清流式输出和历史记录怎么处理。

初始化数据建议写在SQL脚本里。准备一个默认管理员账号，角色定义为超级管理员，同时准备两个测试角色：HR专员、普通员工。登录演示时切换不同账号，功能区别一眼就能看出来。

3.3 创建父工程、公共模块和启动流程

微服务项目建议先建父工程，用pom统一管理依赖版本，避免每个服务各写一套版本号，造成冲突。

公共模块也建议单独创建。

• common-core：统一返回结果、统一异常、基础工具类、常量定义。
• common-api：Feign接口定义，服务间调用共用。
• common-security：JWT工具、登录用户上下文。

后端服务启动顺序要固定下来，否则容易出现“服务间连不上”的假报错。

建议顺序：

MySQL、Redis、Nacos Server 先启动系统服务，再启动依赖它的业务服务 最后启动网关服务

启动好之后，打开Nacos控制台，看到对应服务名称后面显示实例数量，说明注册成功。这一步非常关键，比在IDEA里看到“Started xxApplication”更能证明服务已经加入注册中心。

前端Layui页面如果是静态资源，可以直接用浏览器打开，也可以通过Nginx或SpringBoot静态目录访问。前端不用启动，只需要保证接口地址配置正确。

4. 用 Layui 搭建后台管理界面

4.1 Layui 在做后台管理系统时的实际优势

Layui是一套基于jQuery的前端UI框架，在国内后台管理系统里使用范围很广。它的特点是：不需要学习Vue的响应式思维，也不用安装Node依赖和打包工具。对Java后端同学来说，最快半小时就能把一个后台管理框架跑起来。

Layui自带表格、表单、弹层、日期、树形、上传、分页等组件。HR系统这种“列表+表单+弹窗”的后台，几乎都能用Layui原生组件覆盖。

与Vue+Element相比，Layui的学习成本更低，但组件扩展性弱一些。如果你对Vue已经很熟，也可以把前端换成Vue。但标题是Layui，说明原始方案希望前端尽量轻量、易维护。

4.2 页面布局和接口数据格式

Layui后台页面通常分为登录页和主框架页。主框架页左侧是菜单树，顶部是用户信息和退出按钮，右侧是内容区。

页面之间可以用iframe嵌入，也可以用Tab切换。简单方案是iframe方式：点击菜单，内容区加载对应HTML页面。

最重要的约定是接口返回格式。

Layui的table组件对数据格式有固定要求：

{ "code": 0, "msg": "", "count": 100, "data": [] }

code必须是0才表示成功，count是需要显示的总记录数，data是当前页列表数据。

这个点非常容易踩坑。后端如果返回类似{status:200, result:[]}，Layui表格是不会渲染的。所以后端公共模块里要专门设计统一返回对象，至少在Layui接口里要兼容这种格式。

非表格接口，比如登录、保存、删除，可以统一返回{code, msg, data}。

4.3 表格列操作和常见交互

很多人搜索过“Layui table 单个列能加点击事件吗”，答案是可以。

做法是两件事：列配置里加上事件名，然后用table.on('tool()')监听。

列配置示例：

table.render({ elem: '#employeeTable', url: '/hr/employee/list', cols: [[ { field: 'empName', title: '姓名' }, { field: 'deptName', title: '部门' }, { title: '操作', toolbar: '#barDemo' } ]] }); table.on('tool(employeeTable)', function (obj) { var data = obj.data; if (obj.event === 'edit') { // 打开编辑弹窗 } if (obj.event === 'delete') { // 删除确认 } });

toolbar可以指向一个模板，也可以直接在列里用templet拼HTML。事件名称要唯一，监听区域的id要和表格的elem对应。

除了表格事件，Layui里常用的还有表单监听、时间选择器、上传组件。建议把页面交互集中在少数几个文件里，不要每个页面都写一套重复代码。

4.4 联调时的常见显示问题

Layui界面调不出来，大部分不是组件问题，而是接口返回结构不匹配。

表格空白时，先在浏览器F12里看Network响应，确认返回JSON里有没有data字段。

弹层打不开，先看layui.use里是否引入了form、layer模块。

跨域导致请求失败时，最简单的处理是在网关里统一放开CORS。

菜单点击后内容区空白，先看URL路径和后端Controller是否一致，再看菜单权限是否过滤掉了这个地址。

这些排查点都不复杂，但如果没有经验，真的会怀疑是框架出问题。

5. AI 能力接入：从演示功能到能实际使用

5.1 HR 系统里 AI 到底能做什么

AI不能只是放一个聊天框。要让评审觉得“这个系统和AI结合得很好”，必须把AI放进具体业务流程里。

在HR系统里，比较实用的几个AI场景有：

• 制度问答：员工提问“年假怎么算”“报销流程是什么”，由AI根据知识库回答。
• 简历摘要：招聘模块上传简历文本，AI自动生成候选人关键信息、匹配优势。
• 职位描述生成：输入岗位职责关键词，AI生成完整JD。
• 公告文案、Offer邮件草稿：按模板生成初稿，HR再修改。
• 员工调研汇总：对问卷文本做简单分类和概括。

我建议优先做智能问答和简历摘要。因为制度问答可以直接对接HR模块，简历摘要能放到招聘流程里，演示效果好，也不难实现。

需要注意，AI返回的内容必须被定位为“参考建议”。系统前端要有人工复核提示，不能直接把模型输出当作最终决策。答辩时主动说这一点，反而会加分。

5.2 接入大模型的三种常见方式

建议先把云API跑通，把业务功能做出来，再判断要不要换成本地模型。很多大模型平台提供免费额度，申请一个普通模型Key，足够做毕设演示了。

如果想展示“本地部署大模型”的能力，可以额外做一个独立服务，后端走HTTP接口调用Ollama，这样不依赖外部平台，答辩时也能讲清楚模型从下载、启动到调用的完整流程。

5.3 一个简单问答功能的实现流程

AI功能不要一上来就接模型，先把业务流程定义清楚。

流程参考：

1. 前端在AI助手页面输入问题。
2. 前端把问题提交给后端ai-service。
3. ai-service组装Prompt，系统提示词加上用户问题。
4. ai-service调用大模型接口获取结果。
5. 后端将问题和回答保存到AI对话记录表。
6. 前端展示回答，同时保留历史记录。

后端伪代码示意：

public AiAnswer ask(AiQuestion question) { String prompt = "你是企业HR助手，请用简洁清晰的中文回答员工问题。" + "用户问题：" + question.getContent(); // 调用大模型。可能是云平台API，也可能是本地Ollama String answer = modelClient.chat(prompt); // 保存对话记录 aiRecordService.save(question.getContent(), answer); return new AiAnswer(answer); }

这里不用纠结具体用哪个SDK。你的项目里如果已经有HTTP工具，直接调用模型接口的chat/completions或对应接口即可。关键是把模型调用的部分封装成一个modelClient，后续切换模型只改一个实现类。

5.4 接入 AI 后的稳定性和成本问题

AI接入后最容易遇到三个问题：超时、不稳定、费用。

大模型生成回答耗时比普通接口长。前端HTTP请求如果默认3秒超时，几乎必失败。我的建议是把AI接口的超时时间单独调大，比如30秒到60秒，或者改成异步提交再轮询结果。如果追求交互体验，可以接入流式输出，但流式输出对前端处理要求更高，不建议毕设一上来就实现。

模型输出的不稳定性也要处理。同一道题可能回答得不一样，这是正常现象。系统层面可以做两件事：一是设置固定的系统提示词，约束回答风格；二是为AI功能加入工复核入口，不让模型直接产生不可控影响。

费用方面，云API按Token计费，普通问答对话消耗不大，但要防止循环调用或恶意刷接口，后端要做频率限制。

本地模型不花钱，但需要你下载模型文件并关注资源占用。如果你的机器是8GB内存，建议选小模型；如果有独显，显存够用再考虑更大参数版本。

6. 核心业务链路实操：从登录到员工列表

6.1 登录认证链路

登录是微服务系统里最容易被问的一条链路。整体流程是：

前端Layui登录页把用户名密码发给网关，网关路由到auth-service，auth-service校验账号密码，成功后生成JWT返回给前端。前端把Token存在本地，后续请求在请求头里带上Token。网关统一校验Token是否有效，有效才放行到后端服务。

密码不能明文存库，要用BCrypt加密。注册时加密，登录时用加密工具比对。

如果项目使用Sa-Token，那就把Token逻辑替换成Sa-Token的登录态管理，思路是一样的。关键是能说清楚“无状态认证”和“每次请求都要带上凭证”这两个概念。

6.2 部门树和员工分页

员工管理是HR系统的核心页面。在这个页面里要同时实现两个事：左侧部门树，右侧员工列表。

部门树由部门表形成。每个部门有parent_id，根部门的parent_id为0。后端一次性返回全部部门，前端用Layui树组件渲染。点击某个部门时，把部门ID作为条件传入员工分页接口。如果点击的是父级部门，还需要考虑是否查询所有子部门员工，这个逻辑要在设计阶段就定好。

员工分页接口参数一般包括：

pageNum pageSize deptId empName postId status

后端用MyBatis或MyBatis-Plus的分页插件处理。满足条件后按创建时间倒序返回。前端Layui table把page参数传给后端，对应后端的pageNum。

这个链路很常规，但每一步都有可问的东西。比如“分页为什么用插件”“部门树为什么一次返回而不是递归查询”。

6.3 关键代码或配置示例

网关路由是微服务联调最容易出问题的地方。下面是一个简化版配置示例，实际以你的Spring Cloud版本为准。

spring: cloud: gateway: routes: - id: auth-service uri: lb://auth-service predicates: - Path=/api/auth/** filters: - StripPrefix=1 - id: org-service uri: lb://org-service predicates: - Path=/api/hr/** filters: - StripPrefix=1

lb://表示从注册中心按服务名负载均衡。StripPrefix=1表示去掉第一段路径前缀，这样前端请求/api/hr/employee/list会被转发到org-service的/hr/employee/list。

如果你改了路径，但接口一直404，绝大多数情况是StripPrefix和实际Controller路径没有对应清楚。

6.4 成功运行后的判断标准

这条链路跑通，可以用下面几个标准判断：

1. 使用管理员账号能登录，成功后跳转到主页。
2. 左侧菜单能正常加载出系统管理、组织人事、招聘管理等模块。
3. 进入员工管理页面，左侧能看到部门树，右侧能显示员工分页数据。
4. 点击“新增员工”，保存成功后刷新列表，新记录出现在第一页。
5. 访问服务日志，能看到auth-service、org-service各自打印的日志。

到这里，核心业务闭环已经完成。再做考勤、薪资、招聘，都是在这个框架上增加服务。

7. 微服务联调、网关路由与权限控制

7.1 网关路由配置注意点

网关是微服务统一的入口，所有前端请求都走网关，再由网关转发到具体服务。好处是前端只需要记一个地址，后端服务之间的调用关系也被集中管理。

配置路由时注意几个点：

路径不要写太死。如果服务内部路径变化，网关配置也要跟着改，维护成本高。尽量保持服务内部路径稳定。

跨域统一在网关层解决。每个后端服务不要单独配置CORS，否则会出现过滤器顺序问题，出现“请求到了但拿不到响应头”的坑。

网关可以做简单限流。比如用Spring Cloud Gateway自带的RequestRateLimiter过滤器，或接入Sentinel。毕业设计不强制要求，但如果你写“本项目通过网关实现了统一入口和基础限流”，面试时可以多讲几句。

7.2 服务间调用用 Feign 时的常见坑

服务间调用推荐用OpenFeign，声明式接口写起来很简洁。

坑主要在几处：

Feign接口里的路径必须和提供方Controller路径完全一致。很多人对不上路径，导致调用返回404。

Feign接口不要直接依赖对方服务的数据库实体。因为一改对方表结构，调用方也要跟着改。建议单独定义DTO对象，只放当前业务需要的字段。

调用超时要设置合理。默认超时时间可能很短，服务间调用一慢就会失败。如果你遇到“服务A调用服务B偶尔失败”，先检查超时配置。

还要给Feign调用设计降级。服务B挂了，服务A不能跟着报错。降级可以返回一个空结果或者缓存值，保证前端有响应。

7.3 统一权限校验怎么做

权限控制不能只靠前端隐藏按钮，后端必须要校验。

常见做法是：网关层统一校验Token。Token合法就放行，不合法就返回401。网关不负责具体权限判断，只做身份认证。

具体某个用户能不能访问某个接口，由后端服务自己判断。在Controller拦截器或注解里配置角色要求，比如@PreAuthorize("hasRole('ADMIN')")。

管理员、HR专员、普通员工看到不同页面和按钮，前端在登录后获取当前用户的菜单权限，动态渲染菜单。后端在每个接口上做二次确认。

有一点需要注意：不要把用户的完整信息都放进JWT里。Token只放用户ID、用户名、角色等核心信息，具体业务数据还是要从数据库查。否则别人拿到Token，就等于拿到全部身份信息，风险很大。

8. 常见报错排查清单

8.1 服务注册与连接类问题

服务注册类问题，优先看日志里的全报错信息。不要只看“连接失败”四个字，往下翻十行，通常能看到具体是哪个IP和端口连不上。

8.2 前端数据加载类问题

Layui表格空白的概率非常高。我的排查顺序是：先看接口能不能通，再看返回JSON长什么样，最后看列字段名是否和field一致。大部分问题都出在“接口有数据，但字段名对不上”。

8.3 AI 和资源占用类问题

本地部署大模型时，如果电脑只有16GB内存，运行7B模型会比较吃力。建议先用小模型跑通，再考虑大模型。

8.4 通用排查顺序

遇到任何一个问题，不要急着改代码。先按下面的顺序排查。

1. 看现象：是启动失败、接口报错、页面空白，还是数据处理不对。
2. 看日志：后端服务日志、网关日志、前端Network。
3. 看输入：请求参数、JSON格式、URL路径、Token是否带上。
4. 看中间件：MySQL、Redis、Nacos、MinIO是否都正常。
5. 看配置：端口、命名空间、路由、超时时间、账号密码。
6. 最后再改代码。

这个顺序能解决我遇到的大部分微服务问题。真正需要改代码的情况，往往比想象中少。

9. 论文、PPT 和讲解演示：别让代码白写

9.1 毕设论文写作结构

代码写完只是第一步。毕业设计评审更看重你是否能讲清楚“为什么这么做”。

论文结构可以参考：

• 绪论：背景、意义、国内外现状、主要工作。
• 相关技术介绍：SpringCloud、Layui、AI大模型、MySQL、Redis。
• 需求分析：角色分析、业务流程分析、功能需求、非功能需求。
• 系统设计：架构图、功能模块图、数据库设计、接口设计。
• 系统实现：按模块截图，配合关键代码说明。
• 系统测试：功能测试用例、结果分析。
• 总结与展望：完成情况、不足、后续方向。

写论文时不要大段贴源码，老师不关心全部代码。要把设计过程和效果说清楚，比如“为什么用红黑树”“不，是为什么用Redis做缓存”“为什么AI结果要人工复核”。

9.2 PPT 和现场演示要点

PPT控制在一页一个主题，不要堆字。重点准备这几页：

• 项目背景和技术选型
• 微服务架构图
• 功能模块图
• 数据库ER图或核心表关系
• 核心业务页面截图
• AI功能演示截图
• 项目总结和不足

现场演示提前准备好测试数据和演示脚本。优先演示一条完整链路：管理员登录 → 查看部门树 → 新增员工 → 员工列表刷新 → AI助手提问 → 简历摘要。

演示前先检查基础设施是否启动。我见过很多次翻车现场：Nacos没启动、Redis密码错误、AI接口Key过期。演示前30分钟走一遍全流程，把摘要在旁边写清楚。

9.3 问答环节容易问到的点

答辩时老师会围绕几个方向提问，提前准备答案。

• 为什么选微服务？单体不行吗？要能客观对比。
• 服务拆分原则是什么？可以讲按业务边界划分。
• 服务间是怎么通信的？走OpenFeign，网关统一入口。
• JWT过期了怎么办？刷新Token机制，或者重新登录。
• 服务之间调用失败怎么处理？Feign降级、超时设置。
• 大模型返回结果不准怎么办？限制领域、人工复核、Prompt调优。
• 数据库为什么这么设计？主外键关系、索引、业务约束。
• 系统并发大概能支撑多少？要根据实际环境说明，不要夸大。

回答原则是：说清楚“我做了什么、为什么这样做、还有什么局限性”。承认不足比硬撑显得更专业。

如果你决定做这个毕设，我个人的建议是把第一步“跑通登录到员工列表”作为第一目标。不要一开始纠结是不是所有模块都要微服务化。先把一条业务主链路跑透，再往里面加考勤、薪资、招聘和AI能力。这样代码可控，论文有内容，答辩也有底气。微服务和AI只是工具，真正让你毕业的，是通过这个项目把属于你自己的实践过程和解决问题的能力展示出来。