企业官网建设流程全解析

简介：基于微信小程序的企业内部员工管理系统，是一份面向计算机专业毕业生和项目实战学习者的完整毕业设计项目，整合了前端小程序、后端服务、论文与数据库设计，覆盖员工信息管理、考勤记录、工作日志、绩效考核、薪酬福利等模块，用于解决企业日常人事管理数字化问题。包内共1337个文件，前端以vue、wxml、wxss、js为主，后端为php接口，另有sql数据库脚本和docx文档，配套图片素材，整体约18.99MB，目录层次清晰，便于按模块查阅。目前已有38人学习，适合作为课程设计、毕业设计或企业小型管理系统的参考蓝本。源码可本地编译运行，前后端分离，后端处理数据逻辑并保障安全性；论文与说明文档详细描述了系统设计思路、实现方法、数据库结构及配置流程，可帮助学习者掌握微信小程序开发的完整链路，并理解企业级应用中的业务处理与权限管理。

1. 企业内部员工管理系统这套毕设源码：拆开看看有货没货

抓员工打卡、请假审批、公告通知这几件事拧成一个闭环，前端用微信小程序，后端配数据库和后台接口，再附上论文和说明文档——这就是这套“基于微信小程序的企业内部员工管理系统”源码包。它解决的问题特别清楚：你手里已经有一套能跑的代码，而不是一堆不知道从哪看起的散装文件；论文、数据库脚本和操作说明也齐着，毕业设计需要的东西基本一步到位。适合两类人：一类是临近答辩的在校生，另一类是手上缺现成内部管理后台、想快速搭一套练手的开发者。

2. 读懂源码包的结构：目录、技术选型与数据库表怎么咬合

2.1 解压后先别急着跑：三层目录分别负责什么

拿到压缩包，第一件事永远是解压之后把目录树完整读一遍，而不是双击就运行。我拆过不少同类毕设源码，这一类包的解压结构基本都长这样：

employee-management ├── miniprogram # 微信小程序前端，原生语法 │ ├── app.js # 小程序入口逻辑，含全局登录态 │ ├── app.json # 页面注册、tabBar 配置 │ ├── app.wxss # 全局公共样式 │ ├── config/ │ │ └── api.js # 后端接口地址统一配置 │ └── pages/ │ ├── login/ # 登录页 │ ├── workbench/ # 工作台：待办、打卡入口 │ ├── attendance/ # 考勤打卡 │ ├── leave/ # 请假申请 │ ├── announce/ # 公告列表 │ └── mine/ # 个人中心 ├── server # Spring Boot 后端工程 │ ├── pom.xml │ └── src/main/java/com/... │ ├── controller/ # 接口层 │ ├── service/ # 业务层 │ ├── mapper/ # 数据访问层 │ └── entity/ # 实体类 │ └── src/main/resources/ │ └── application.yml # 数据库、端口等配置 ├── database │ └── employee_db.sql # 建库建表脚本 └── docs ├── 论文.docx └── 说明文档.md

也许你拿到手的包目录名跟这个不完全一致，但没有关系，你只需要在解压后找到四件东西：小程序前端目录、后端工程目录、SQL 文件、文档目录。这四件齐了，项目骨架就完整了。

值得提醒的是，docs 里的说明文档常被忽略，但里面往往记录了数据库账号密码、初始管理员账号和后端启动方式，是排查问题的第一手资料。我拿到任何源码包都会先打开说明文档看一眼，重点看三处：数据库版本要求、后端端口、小程序端是否需要改 request 合法域名——这三个信息决定了你后面要花多少时间在联调上。

2.2 技术选型为什么是这一套：原生小程序配 Spring Boot 的现实逻辑

很多人在拿到源码后会问一句“为什么不用 uniapp 或者 vue 来做前端？”这个问题的答案其实要从毕设场景出发。原生微信小程序最大的优势是零构建链，微信开发者工具直接导入 miniprogram 目录就能编译预览，不需要装 Node 依赖、不需要跑 npm install，对一台刚配好环境的电脑来说，少了最不确定的一环。

后端用 Spring Boot 也是同类项目里最常见的选择。它内置 Tomcat，一个 mvn spring-boot:run 就能把接口服务跑起来；再加上 MyBatis 或 MyBatis-Plus 做数据访问，配合 MySQL 存储业务数据，整个链路就是国内高校管理系统类毕设最标准的组合。

你拿到手之后可以快速验证一下后端的选型细节。打开 server/pom.xml，看三个关键依赖：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> </dependency>

这三个依赖分别对应接口服务、数据库驱动和数据持久层。如果中间那个 mysql-connector-java 版本较老，而你本机装的是 MySQL 8.0，导入数据库时可能要额外处理认证插件的问题，这一点后面避坑章节会细说。

为什么这套组合值得推荐而不是换成更花哨的框架？因为它在“能演示”和“好答辩”之间取了平衡。Spring Boot 的 controller 层一眼能看到接口清单，MyBatis 的 SQL 逻辑集中在 mapper 里，论文里写架构图和数据流的时候，每一层都能对应到实际代码，而不是空谈概念。

2.3 从表设计读业务：考勤、请假、审批从一开始就不是孤立的

数据库脚本是这份资源里最不应该跳过的文件，因为表结构就是业务的切片。先看典型的员工表长什么样：

CREATE TABLE t_employee ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键ID', emp_no VARCHAR(20) NOT NULL UNIQUE COMMENT '工号', name VARCHAR(50) NOT NULL COMMENT '姓名', dept_id BIGINT COMMENT '所属部门ID', role VARCHAR(20) DEFAULT 'EMPLOYEE' COMMENT '角色：ADMIN/EMPLOYEE', phone VARCHAR(20) COMMENT '手机号', avatar VARCHAR(255) COMMENT '头像URL', status TINYINT DEFAULT 1 COMMENT '账号状态 1正常 0禁用' );

这张表同时承担了登录、员工管理和角色判断三个职责。工号 emp_no 是登录账号，role 字段用来区分普通员工和管理员，status 控制账号能否登录。把这三个字段放在同一张表里，代码里就不用再单独维护账号体系，毕设的复杂度也能控制得住。

把员工、请假、考勤、公告这几张表放在一起看，业务链路就很清楚了：

请假表里的 approve_status 是一个典型的流程状态字段，常见取值是 0 待审批、1 已通过、2 已驳回，管理员端审批时改的就是这个字段。考勤表的 punch_time 记录打卡时间，punch_type 区分上班卡和下班卡。公告表的 publish_time 则用来做列表排序。

把表读完，你也就知道小程序页面大概要请求哪些接口了。登录接口查 t_employee 校验工号和密码，工作台首页查 t_notice 统计待办数量，请假页 insert 一条 t_leave 记录，审批页 update approve_status。整个系统的数据流在小程序、接口、数据库三层之间流转，没有绕路的地方，这就是这类毕设源码的典型优点——结构直白，容易讲清楚。

3. 把它跑起来的最短路径：数据库导入、后端启动与小程序联调

3.1 环境准备：JDK、Maven、MySQL、微信开发者工具四件套

这套资源对运行环境的要求不高，但该装的四样东西一个都不能少：JDK 1.8 或以上版本、Maven 3.6+、MySQL 5.7 或 8.0、微信开发者工具稳定版。装好之后先用命令确认环境在位：

java -version mvn -v mysql --version

三个命令都能打印出版本信息，再打开微信开发者工具能正常登录，环境就齐了。Spring Boot 项目用的是 Maven 管理依赖，第一次 mvn spring-boot:run 会下载大量 jar 包，耗时取决于网络，这一步急不来，下载完成后后续启动都会很快。

你可能会问为什么不直接用 IDEA 打开后端然后点运行，命令行跑也能跑，但如果你是新手，我更推荐先用命令跑通再考虑 IDE。原因很简单：命令行报错信息更原始，能看到完整的堆栈，容易定位端口占用、依赖缺失这类基础问题，真到了答辩演示时，IDE 反而可能因为缓存或配置问题翻车。

3.2 导入数据库与修改配置：三步让后端先活起来

后端能不能启动，核心取决于数据库是否导入成功。先建库再导数据，并且建库的时候把字符集显式指定成 utf8mb4，这是避免中文乱码最关键的一步：

mysql -uroot -p

进入 MySQL 命令行之后执行以下 SQL：

CREATE DATABASE IF NOT EXISTS employee_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE employee_db; SOURCE /your/absolute/path/employee_db.sql;

这里几个参数逐个说清楚：-uroot 是数据库用户名，按你本机的实际账号替换；YOUR密码 是 MySQL 的登录密码；SOURCE 后面的路径必须是 SQL 文件的绝对路径，Windows 下注意路径里的反斜杠要写成正斜杠，否则容易报找不到文件。SOURCE 执行完成后看到多条 Query OK，说明表都建出来了，可以用 SHOW TABLES; 验证一下。

数据库就绪后，打开 server 下的 application.yml，把数据源改成你自己的账号密码：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/employee_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你自己的密码

url 里的 employee_db 对应刚才建的库名；characterEncoding=utf8 保证写入中文不乱码；serverTimezone=Asia/Shanghai 是避免 MySQL 8.0 时区报错的关键参数。密码如果没有就留空，但大多数情况下源码包会在说明文档里写默认密码，找不到就填入你自己 MySQL 的密码。

然后回到后端工程根目录启动：

cd server mvn spring-boot:run

看到类似 Started Application in 5.32 seconds 的日志就是启动成功。如果启动失败，优先看日志里的三个关键字：port 表示端口被占用，Access denied 表示账号密码错，Table doesn't exist 表示 SQL 没导进去。这三个错误对应的问题不一样，但处理方向都很单一，按日志提示改配置再重启即可。

3.3 小程序端联调：改出正确的请求地址与本地调试开关

后端跑起来后，下一步就是把小程序端指向这个后端服务。源码包一般在 config/api.js 里集中维护请求地址，这是我最推荐的做法，因为只需要改一处：

// miniprogram/config/api.js module.exports = { baseUrl: 'http://localhost:8080/api', };

baseUrl 的含义是后端接口的统一前缀，后面 controller 里写的 @RequestMapping 路径都会拼在这个地址后面。本地联调保持 localhost 即可，但如果要在手机上真机预览，必须把这个地址改成电脑的局域网 IP，比如 http://192.168.1.10:8080/api，手机和电脑连同一个 Wi-Fi 才能访问。

改完地址还有一个非常关键的开关。微信开发者工具默认会校验 request 的域名是否在合法域名列表里，本地联调时后端跑在 IP 或 localhost 上，肯定不在列表里，所以需要手动关闭校验，否则请求会被直接拦截。打开开发者工具的“详情”面板，找到“本地设置”，勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”即可。这个开关只影响本地开发环境，上线时必须用备案过的 HTTPS 域名，逻辑上不能混淆。

4. 避坑：本地部署与答辩演示必看的五条翻车记录

4.1 域名校验挡路：开发者工具报 url not in domain list

现象：小程序端点击登录，接口请求直接失败，控制台报错内容类似 “url not in domain list”，但同一个地址在浏览器里访问后端接口完全正常，后端日志里也根本看不到这条请求进来。

原因：微信小程序对 wx.request 的请求域名有限制，线上环境要求域名必须备案并且配置在公众平台的 request 合法域名里。本地联调走的 localhost 或局域网 IP 不满足条件，默认情况下请求会被前端拦截。

解决：在微信开发者工具右上角“详情”进入“本地设置”，勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”。这是本地开发的正常操作，不是绕过限制的玄学——上线前把后端换成 HTTPS 域名并在小程序后台配置好白名单就没问题。勾选之后重新编译，请求就能打到 localhost:8080。

4.2 异步时序：token 还没回来，数据请求已经发出去了

现象：登录成功之后跳到工作台页，但工作台里的待办数量、公告列表全是空的，刷新也没用，重新登录有时又正常。

原因：wx.request 是异步请求。登录接口的返回在回调里才拿到 token，但页面跳转逻辑放在 wx.request 外面或者回调外面执行，导致工作台页发起后续请求时，本地 storage 里还没有 token，后端按未登录处理直接返回空数据或 401。

解决：把登录后要做的动作全部放在成功回调内部，按顺序执行，不要出现回调外面再发请求的写法。我在接这类源码时习惯把登录流程从页面里拆出来，统一维护成下面这种结构：

wx.login({ success: (res) => { wx.request({ url: config.baseUrl + '/login', method: 'POST', data: { username, password }, success: (res) => { wx.setStorageSync('token', res.data.token); wx.setStorageSync('userInfo', res.data.userInfo); wx.switchTab({ url: '/pages/workbench/workbench' }); } }); } });

这里的要点是：setStorageSync 写 token、switchTab 跳转页面、以及工作台页面里发起的后续请求，三者必须形成严格的先后依赖，token 写入完成后再跳转。凡是报“登录成功但页面没数据”的，九成是时序问题，把这段代码改成回调嵌套就能解决。

4.3 数据库导入后中文乱码：一个参数没对齐全表遭殃

现象：SQL 文件导入成功，后端也启动正常，但小程序里查出来的员工姓名、公告标题全是问号或乱码，英文和数字正常。

原因：MySQL 服务端默认字符集不是 utf8mb4，最常见的情况是建库的时候没指定字符集，直接 source 了 SQL 文件，表沿用了服务端的 latin1 或 utf8mb3 字符集。中文字符在存储和读取时编码不一致就变成乱码。

解决：把库删掉重建，严格按第 3 章的建库语句先执行：

DROP DATABASE IF EXISTS employee_db; CREATE DATABASE employee_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE employee_db; SOURCE /path/to/employee_db.sql;

同时检查后端连接串里要带 characterEncoding=utf8，两条同时满足，中文数据才能正常存取。这里要特别提醒：如果 SQL 脚本文件本身是用 GBK 编码保存的，source 的时候同样会乱码，这种情况可以用记事本打开 SQL 文件另存为 UTF-8 编码再导入。这一条我在多个项目里踩过，明明是同一个脚本，换台电脑导入结果不一样，多半就是文件编码和服务端字符集的组合问题。

4.4 后端端口被占用：明明重启了还在报连接被拒

现象：后端改了代码重启，发现永远启动不成功，或者第一次启动成功，第二次提示端口被占用，小程序端一直报连接失败。

原因：有几种可能，一是上一次 Spring Boot 进程没有完全被杀掉，Windows 下 IDEA 或命令行关闭窗口后 Java 进程可能仍然驻留；二是本机的 8080 端口已经被其他服务占用，比如本地的 Nginx 或另一个 Tomcat；三是你改过 application.yml 里的端口，但小程序 config/api.js 里还指向旧端口。

解决：先用命令查看端口占用情况：

netstat -ano | findstr 8080

输出结果里最后一列是占用该端口的进程 PID，然后打开任务管理器找到对应 PID 的 Java 进程并结束。如果是你自己改过端口，确定 application.yml 里的 server.port 和 config/api.js 里的 baseUrl 保持一致就行。从那以后我每次启动后端前都会习惯性地先看一眼 8080 是不是已经被占，这个习惯帮我省掉很多无意义的重启时间。

4.5 登录态不持久：小程序重启后被打回登录页

现象：本地开发时登录正常，但小程序一重启或者过一晚再看，又回到登录页；更糟的是答辩演示现场，评委刚拿起手机，页面就退出了。

原因：登录态存放的是 token，而 token 被存在本地 storage，但页面每次启动时检查登录态的逻辑只判断了“有没有 token”，没有判断 token 是否过期；或者检查逻辑里读错了 key 名，工程不同页面 getStorageSync 的字段名不统一，一处写 token 一处写 userToken，对不上就判定未登录。

解决：统一登录态的存取操作，不要在每个页面里直接操作 storage。建议所有页面通过一个公共方法读取登录态，同时在小程序启动入口做一次主动校验：

// app.js 中检查登录态 onLaunch() { const token = wx.getStorageSync('token'); if (!token) { wx.reLaunch({ url: '/pages/login/login' }); } }

这个 onLaunch 是微信小程序的生命周期函数，每次冷启动都会执行。在这里做统一检查，能避免每个页面各写一套判断逻辑。答辩演示前还要记得在开发者工具里确认“清理缓存”没有被误触，因为一键清缓存会把 token 一起清掉。

5. 让它变成答辩加分项：统一请求封装与按钮级权限控制

把源码跑通只是第一步，答辩时真正能讲出深度的地方，是代码里有没有统一的请求层和权限控制思路。这套源码包的基础功能完备，但原版代码在请求层通常比较朴素，页面里直接 wx.request 散落各处。我一般会做一个小改造，把请求统一封装起来。

// utils/request.js const config = require('../config/api.js'); function request(path, method = 'GET', data = {}) { const token = wx.getStorageSync('token') || ''; return new Promise((resolve, reject) => { wx.request({ url: config.baseUrl + path, method: method, data: data, header: { 'Content-Type': 'application/json', 'Authorization': token }, success(res) { if (res.statusCode >= 200 && res.statusCode < 300) { resolve(res.data); } else if (res.statusCode === 401) { wx.removeStorageSync('token'); wx.reLaunch({ url: '/pages/login/login' }); } else { reject(res); } }, fail(err) { reject(err); } }); }); } module.exports = { request };

这段代码的收益在答辩时很容易讲清楚：所有请求统一带 Authorization 头，后端通过这个头识别登录用户；统一处理 401 状态码，登录过期时自动踢回登录页，不用每个页面重复写错误弹窗。对外暴露的 request 方法返回 Promise，页面里就可以用 async/await 或 .then 管理异步流程，不用再一层层嵌套 wx.request 回调。

再做一层权限控制就更有说头了。原版的小程序前端里，“审批”“删除”这类按钮通常对所有人可见，真正判断角色是在后端接口层，前端体验不够好。改成前端也做一层按钮级控制，逻辑上更完整：

<!-- 审批按钮只对管理员显示 --> <button wx:if="{{role === 'ADMIN'}}" class="btn-approve" bindtap="approve">通过</button>

页面加载时从 storage 里取出当前用户角色，绑定到 data.role 上，普通员工就直接看不到审批按钮。这个小改动让演示时能直观看到“不同角色看到不同界面”，比单纯讲解后端权限设计更有说服力。

那段时间我帮朋友调试同类型的毕设源码，每次都用同样的流程重走一遍：先读三层目录，再导库跑后端，改完小程序地址后把请求层统一封装，最后补上按钮级权限。从那以后我每次拿到带微信小程序的源码包，都强制自己先做这三步检查：token 是不是统一携带、登录态是不是统一校验、权限控制是不是分成接口层和前端层两层。这套资源拿到手之后，建议你也按这个顺序走一遍，把每一处改动的理由讲清楚，答辩的深度基本就够了。希望帮到你。

本文还有配套的精品资源，点击获取