企业官网建设流程全解析

简介：面向计算机专业学生，这是一份微信小程序个人日程安排系统的毕业设计完整项目，采用微信小程序开发工具搭配Java后端与MySQL数据库，实现了个人中心、用户管理、重要日管理、工作日程管理、会面管理、用餐管理、日程管理及系统管理等模块，可覆盖日常个人日程规划场景。压缩包共1175个文件，以Java后端源码、Vue与JavaScript前端逻辑、WXML与WXSS页面结构样式、PNG图片素材、JSON配置及SQL脚本为主，整体大小约40.44MB。已有160人学习浏览。除完整源码外，资源还附带演示视频、说明文档、构建运行脚本与Eclipse工程配置备份，便于导入开发工具后快速运行，理解系统模块划分，参考界面前端与后端接口设计，也可直接作为毕业设计交付基础，实用性与参考价值兼顾。

1. 这套个人日程安排系统毕设资源包，为什么值得你花两小时研究

刚拿到【微信小程序毕业设计】个人日程安排系统开发项目(源码+演示视频+说明).rar 时，我的建议不是急着解压，而是先把它当成一份“可以复现的产品需求”来拆。这个标题翻译成一句话就是：给你一套能跑通的小程序前端、一个服务端、一份数据库脚本，以及演示和说明，让你在毕业设计里不用从零开始。资源本身不神秘，真正拉开差距的是你能不能在两小时内把它跑起来，并在答辩前把它改造成带个人思考的系统。这篇笔记适合三类人：第一次做全栈毕设的学生、想快速了解小程序前后端联调流程的同学，以及只需要一个基础项目做二次开发的开发者。我会从拆资源包开始，一步步讲到改造和避坑，并给你一份答辩前的检查单。

2. 拆开资源包：源码、演示视频、说明文档各承担什么角色

这类带“源码+演示视频+说明”的毕业设计压缩包，是一个完整交付物，而不是单纯的代码压缩包。如果你只盯着源码看，会漏掉一半信息。我一般会按“先看演示视频、再看说明文档、最后读源码”的顺序处理。这样做的原因是：视频定义了“应该有什么效果”，文档定义了“需要什么环境”，源码负责回答“怎么实现的”。顺序反了，你会在代码里迷路，然后觉得到处都是玄学。

2.1 源码目录结构：一眼分清小程序端、服务端和配置文件

项目根目录通常由四部分组成：小程序前端、服务端、数据库脚本、文档。目录可能叫miniprogram、client、frontend，也可能叫server、backend、api，但结构基本逃不出下面这张图：

project-root/ ├── miniprogram/ # 小程序前端代码 │ ├── pages/ │ │ ├── index/ # 日程列表页 │ │ ├── add/ # 新增/编辑日程页 │ │ ├── calendar/ # 日历视图页（部分项目没有） │ │ └── mine/ # 个人中心页 │ ├── components/ # 自定义组件，比如日期选择器 │ ├── utils/ │ │ ├── request.js # 封装 wx.request │ │ └── date.js # 日期格式化工具 │ ├── app.js │ ├── app.json │ └── config.js # 前端全局配置 ├── server/ # 服务端，常见用 Koa/Express/Flask │ ├── routes/ │ ├── controllers/ │ ├── models/ │ ├── app.js │ └── package.json ├── db/ # 数据库初始化脚本 │ └── schedule.sql ├── doc/ # 说明文档 │ └── README.md └── package.json # 可能没有，取决于是否把服务端独立建包

判断代码归属有一条捷径：看到app.json、app.wxss和pages/开头的是小程序端；看到package.json、routes/和express()之类的则是服务端。数据库脚本一般以.sql结尾，里面全是CREATE TABLE。配置文件的特征也很明显：小程序端有config.js，服务端则可能是.env或config/index.js。先把这些顶层文件找出来，后续改接口地址和数据库密码时就不会找错地方。

# 在解压目录下快速定位三种关键文件 find . -name "*.sql" -o -name "config.js" -o -name "project.config.json" | sort

这条命令的价值在于，它能立刻告诉你老项目把配置放在哪个位置。我见过不少项目把所有敏感信息写在config.js里，答辩前因为没改数据库密码当场报错。先定位文件，再动代码，是省时间的好习惯。如果解压后还发现dist、node_modules这种目录，一般不用管，它们要么是构建产物，要么是依赖包，不是你要改的地方。

2.2 演示视频要怎么看：它其实是需求文档

演示视频通常八到十五分钟，覆盖登录、主页面加载、新增日程、编辑、完成/删除、日历切换。很多人把视频快进过去，这是浪费。演示视频其实是可执行的需求文档，它告诉你页面跳转关系、按钮文案、操作顺序，而这些信息在静态代码里反而不明显。边看边记录，比读源码快得多。我推荐用一张表格做记录：

拿这张表去对照源码，你会发现很多“视频里有但代码里没有”的功能。不要慌，这很常见。视频可能是早期版本录的，源码是最终版本，两者偶有出入。处理办法是以源码为准，把视频当作交互预期，而不是验收标准。真正需要照做的只有“登录、新增、编辑、删除”这条主链路，其他都算加分项。

2.3 说明文档先看这几节，能省三个小时

说明文档是压缩包里最容易被低估的资产。大多数项目会写环境要求、数据库初始化、接口列表和运行步骤。不要从头到尾咬牙读，先跳着看三块。第一是“环境版本”，例如 Node.js 版本、MySQL 版本、微信开发者工具基础库版本。版本不对，后面会出现一堆黑匣子问题，比如npm install装一半报错、SQL 导入失败，表面看是命令问题，其实是版本兼容问题。第二是“数据库初始化”，它通常会给你一句source或让你把.sql文件导入，这一步如果漏了，后端一启动就连不上表。第三是“测试账号”或“演示账号”，没有它你连登录页都进不去。一般说明文档会写admin/123456，但也可能藏在“常见问题”里，找不到就去源码里搜123456或password。

# 在文档和源码里快速搜 demo 账号 grep -rIn "demo\|123456\|password\|测试账号" --include="*.md" --include="*.js" --include="*.sql" .

这里要提醒一句：说明文档里写的运行步骤是按作者的环境写死的，不要照着敲一遍就说跑通了。你要把它当成一张“环境拓扑图”，理解每个命令背后要启动哪个进程、依赖哪个数据库，而不是命令本身。比如文档说npm run dev，你要知道它实际执行的是node app.js还是nodemon，这决定改完代码要不要重启。文档读完，你应该能画出一张链路图：小程序 → 请求 → 服务端 → MySQL；后面排错就是沿着这条链逐段查。能画这张图，才算真正读懂了说明文档。

3. 跑通项目：从工具准备到完成一次日程增删改查的最小路径

现在解决一个最实际的问题：把资源包变成能在你电脑上运行的系统。很多人卡住不是因为代码难，而是因为环境不完整或顺序不对。我的建议是严格按照“准备工具 → 导入前端 → 初始化数据库 → 启动服务端 → 联调验证”的顺序走，每做完一步就先用最简单的方式确认，不要等最后一起点。这样出了问题能很快确认是哪一段，而不是对着黑屏猜。

3.1 准备微信开发者工具、数据库环境与服务端运行环境

先确认本机已安装三样东西：微信开发者工具、Node.js（或项目对应的运行时，有些老项目用 Java/Koa/Flask），以及 MySQL。项目说明文档里一般会标明需要哪个版本。这里给一组最小检测命令：

node -v # 要求 12 以上，建议 16/18 LTS npm -v # 与 Node 匹配即可 mysql --version # 5.7 和 8.0 都能跑，但字符集要统一

如果本机已有更高版本 Node，不用急着降级。多数个人日程项目只用了基础 API，Node 16 到 20 都能跑；但如果npm install编译原生模块失败，再考虑用nvm切换到项目指定版本。微信开发者工具直接装“稳定版”即可，导入项目时需要选择“小程序”而非“小游戏”。这里有个细节：如果你没有注册小程序 appid，工具允许你使用测试号，但测试号无法调用订阅消息等部分开放接口。为了后面改造演示，建议花十分钟去公众平台注册一个个人类型小程序，拿到自己的 appid 再继续。这一步不需要付费，个人主体就能注册，唯一要做的就是实名验证。

3.2 导入小程序端：修改 appid 与接口地址

打开微信开发者工具，点击“导入项目”，选择解压目录里的miniprogram文件夹；如果项目把前后端放在同一目录，就选择包含app.json的那个文件夹。导入成功后，第一件事不是点编译，而是修改两个文件。第一个是project.config.json，把appid改成你自己的：

{ "appid": "wx1234567890abcdef", "compileType": "miniprogram", "libVersion": "2.33.0", "projectname": "personal-schedule" }

第二个是前端接口地址。这个文件在不同项目里可能是config.js、api.js，也可能藏在utils/request.js顶部。我一般先用全局搜索定位baseUrl：

grep -rIn "baseUrl\|BASE_URL\|apiBase\|localhost" --include="*.js" miniprogram

然后把localhost改成你电脑在局域网下的 IP，例如：

module.exports = { baseUrl: 'http://192.168.1.100:3000/api/v1', timeout: 10000 };

这里有两个关键点。第一，不要用localhost，因为真机预览时手机访问不到你电脑上的localhost，它访问的是手机自己。第二，如果服务端不在3000端口，这里要改成服务端实际监听端口。改完接口地址后，先编译一次，确认没有语法错误再继续。这时候页面可能白屏，因为服务端还没启动；别急，下一步启动服务端。

3.3 初始化数据库并启动服务端

数据库脚本通常长这样：建库、建表、插入测试数据。打开 MySQL 命令行，先建库再导入脚本：

CREATE DATABASE IF NOT EXISTS schedule_db DEFAULT CHARACTER SET utf8mb4; USE schedule_db; SOURCE /your/path/db/schedule.sql;

注意SOURCE后面跟的是绝对路径，不要写相对路径。导入完成后用下面这句快速确认表是否存在：

SHOW TABLES;

看到的表一般有user、schedule、category，也可能有remind。如果你的脚本导入报错，先检查字符集是否是utf8mb4，再检查是否在USE schedule_db之后才执行。服务端要能连上数据库，还得改服务端配置。找到server下的.env或config/index.js，把数据库名、用户名、密码改成你自己的：

module.exports = { db: { host: '127.0.0.1', user: 'root', password: 'your_password', database: 'schedule_db' }, port: 3000 };

配置改完后启动服务端。Node 项目的常见命令是：

cd server npm install npm run dev

如果npm install报权限错误，可能是没有用管理员权限或目录被锁定；如果报某个包版本不存在，多半是项目太老，需要手动指定版本。启动后终端会打印监听端口，通常是3000或8080。看到日志输出“数据库连接成功”，或者用浏览器访问http://127.0.0.1:3000/health能返回 JSON，说明服务端已经就绪。

3.4 联调验证：先用接口测试工具跑通后端，再回到小程序操作

不要急着在小程序端点按钮，先用 Postman、Apifox 或 curl 单独验证后端接口。这样可以隔离问题：接口通了，说明问题在小程序端；接口不同，说明问题在后端。假设说明文档里给了登录接口，你可以这样测试：

curl -X POST http://127.0.0.1:3000/api/v1/user/login \ -H "Content-Type: application/json" \ -d '{"username":"demo","password":"123456"}'

能返回token或用户信息，继续下一步；如果返回 404，先去查路由路径；如果返回 500，看服务端终端日志，通常能直接看到 SQL 报错。后端验证通过后，再回到微信开发者工具点“编译”。按演示视频的顺序操作：输入账号密码登录，进入首页后新增一条日程，比如“明天上午 9 点开组会”，保存后看列表是否出现这条记录，再点进详情编辑时间，最后删除。这一串操作全部成功，才叫真正跑通。

跑通之后，我习惯立刻在小程序端把baseUrl从127.0.0.1改回局域网 IP 并用真机预览一次，因为后面答辩大概率是在真机上演示，早发现网络问题比晚发现好。另外，每次重启服务端后，建议重新执行一次curl健康检查，避免服务端启动了但数据库连接失败，导致小程序端报 500。

4. 把“演示品”改造成“能答辩的作品”：四个必改点

跑通只是开始。毕业设计评分通常不只看出程序能不能点，更看重你有没有考虑真实场景。个人日程安排系统最常见的问题是“只有增删改查，没有提醒，没有优先级，没有数据统计”。下面这四个改造点，工作量不大，但能明显提升项目的完整度和答辩时的可讲性。每一个我都给出对应的改动思路和关键代码，你可以直接照着做。

4.1 添加日程提醒：用订阅消息替代本地模拟通知

很多初学者会想用setTimeout或setInterval在微信小程序里做定时提醒。这个做法在小程序端行不通：小程序进入后台后，定时器会被系统挂起，用户关掉微信后更不会执行。真正能触达用户的方案是微信订阅消息，或者使用服务端定时任务发送。对于毕设项目，订阅消息的实现成本最低，演示效果也直观。前提是你要在微信公众平台申请一个“日程提醒”模板，拿到模板 ID。在小程序端，用户新增日程时先请求订阅授权：

wx.requestSubscribeMessage({ tmplIds: ['订阅消息模板ID'], success(res) { if (res.errMsg === "requestSubscribeMessage:ok") { wx.setStorageSync('remind_open', true); } else { wx.showToast({ title: '无法发送提醒', icon: 'none' }); } }, fail: () => wx.showToast({ title: '订阅失败', icon: 'none' }) });

服务端收到创建日程的请求后，按计划时间调用微信发送接口。这里最核心的代码是获取 access_token 并调用订阅消息接口：

const got = require('got'); async function sendSubscribeMessage(openid, templateId, time, desc) { const token = await getAccessToken(); // 从缓存取，不要每次都要 const url = `https://api.weixin.qq.com/cgi-bin/message/subscribe/send?access_token=${token}`; await got.post(url, { json: { touser: openid, template_id: templateId, page: 'pages/index/index', data: { time: { value: time }, thing: { value: desc.slice(0, 20) } } } }); }

需要说明的是，订阅消息要求用户主动点击授权一次才能发送一条，且模板字段有长度限制。因此演示时要设计成“先新增日程并授权，再到服务端手动或定时触发发送”，避免对着评委解释微信政策。这段代码加入后，你的项目就从“记事本”变成了“提醒工具”，这是答辩时一个很自然的亮点。如果项目本身是云开发架构，也可以直接使用云函数定时触发器，但标题里那种自建后端项目用订阅消息更合适。

4.2 数据模型加一个 priority 字段：让日程列表变成优先级矩阵

现成的表结构通常只有标题、时间、状态这几个字段。真实日程管理场景里，用户会希望把重要事项排在最前面。常见做法是给schedule表加一个priority字段，普通日程为 0，重要日程为 1。用一条ALTER TABLE就能完成迁移：

ALTER TABLE schedule ADD COLUMN priority TINYINT NOT NULL DEFAULT 0 COMMENT '0普通,1重要' AFTER status; ALTER TABLE schedule ADD INDEX idx_priority_time (priority, plan_time);

加索引是为了让排序查询走索引，数据量很小时看不出差别，但评委如果问你“为什么这么加”，你可以把这个理由讲出来。前端新增/编辑页加一个开关或选择器，提交时把priority一起传过去。列表查询语句改成：

SELECT id, title, plan_time, status, priority FROM schedule WHERE user_id = ? ORDER BY priority DESC, plan_time ASC;

前端渲染时，对priority === 1的记录加一个“重要”标签，比如红底白字。这个改动看起来简单，但它让系统从“按时间堆叠”变成了“按价值排序”，在答辩中属于“业务思考”而不是“功能罗列”。如果还想更进一步，可以把priority扩展成枚举值：低、中、高，分别对应 1、2、3，查询时用ORDER BY FIELD(priority, 3, 2, 1)，这样能聊的东西更多。

4.3 个人中心页增加统计视图：用一周数据验证系统价值

日程系统做完 CRUD 之后，下一步通常是统计。个人中心页可以显示“未来 7 天日程数”“本周完成率”“今日已完成”。这些数据用一条 SQL 聚合就能取到，不需要额外引入图表库。后端增加一个统计接口：

SELECT DATE(plan_time) AS day, COUNT(*) AS total, SUM(CASE WHEN status = 1 THEN 1 ELSE 0 END) AS done FROM schedule WHERE user_id = ? AND plan_time >= CURDATE() - INTERVAL 6 DAY GROUP BY DATE(plan_time) ORDER BY day;

接口返回 7 天数据后，小程序端不需要引入重的图表组件。我一般会用简单的 view 模拟柱状图：把每天的完成率转成百分比，再通过setData更新。这样既避开 ECharts 体积问题，也展示了你对“轻量化渲染”的理解。核心代码片段如下：

const days = res.data.map(item => ({ date: item.day.slice(5), done: item.done || 0, total: item.total || 0, percent: item.total > 0 ? Math.round(item.done / item.total * 100) : 0 })); this.setData({ days });

在wxml里用一个view根据days[index].percent设置高度。这个功能属于“可视化和数据洞察”，放个人中心页几乎不会影响原有演示流程，却能让评委觉得你做了完整的业务闭环。需要注意的坑是时区问题：如果服务端和数据库时区不一致，CURDATE()取到的日期可能和用户本地日期差一天。解决办法是在服务端统一用Asia/Shanghai时区启动，或者在 SQL 里用DATE_FORMAT(plan_time, '%Y-%m-%d')配合DATE_ADD做位移。

4.4 登录逻辑换成 openid 与自动注册，避免死账户

老的毕设项目通常使用“用户名+密码”登录，用户表里预置一个测试账号。这在演示时没问题，但显得不真实。小程序生态里更合理的做法是wx.login拿到code，后端向微信接口换取openid，然后判断用户是否存在，不存在就自动注册。这样用户第一次进入系统就是登录，不需要手动注册账号。后端代码示意：

const { code } = req.body; const { openid } = await getOpenIdByCode(code); // code2session let user = await findUserByOpenId(openid); if (!user) { user = await createUser({ openid, nickname: '微信用户', avatar: '', created_at: new Date() }); } const token = sign({ userId: user.id }, SECRET, { expiresIn: '7d' }); res.json({ token, user });

小程序端只需要调用wx.login获取 code，然后请求登录接口：

wx.login({ success: async (res) => { const { code } = res; const result = await wx.request({ url: `${baseUrl}/user/login`, method: 'POST', data: { code } }); wx.setStorageSync('token', result.data.token); } });

这里有两个坑需要提前说明：小程序的appsecret只能放在服务端，不能写进前端代码；code只能用一次，不能反复使用。如果你不想动登录逻辑，至少要把原来写死在代码里的测试账号改成环境变量。否则代码一旦公开，等于把你的数据库后台也公开了。改成 openid 登录后，还能在用户表里加一个last_login_at字段，展示“最近登录时间”，这是成本极低的小亮点。接口封装时，记得在utils/request.js里统一带上Authorization头，否则后端 token 校验会一路 401。

5. 避坑清单：日程小程序毕设最容易翻车的 5 个隐藏问题

下面这些坑我都有过真实踩坑记录，整理成“现象 → 原因 → 解决”的格式，你可以直接对着排查。每个问题单独看都很小，但组合起来足以让一次演示彻底翻车。

5.1 开发者工具正常，真机预览白屏或请求超时

现象：电脑上的微信开发者工具里一切正常，拿手机扫码预览后页面白屏，或者点击登录一直转圈。原因：小程序端把接口地址写成了localhost或127.0.0.1，手机访问的是手机本地，根本到不了你的电脑；另外，开发者工具默认打开了“不校验合法域名”，这个设置只对工具内调试生效，真机上会直接拦截非 HTTPS 请求。解决：把baseUrl改成电脑的局域网 IP，例如http://192.168.1.100:3000/api/v1，同时保证手机和电脑在同一个 Wi-Fi。如果项目没有 HTTPS 证书，小程序后台的“开发设置-服务器域名”里无法添加非 HTTPS 域名；答辩用“真机调试-局域网模式”可以避开，但你要提前确认手机能访问电脑端口。实际操作用ipconfig（Windows）或ifconfig（macOS）查到本机 IP，然后随手用手机浏览器访问http://192.168.1.100:3000/health验证一次，比在小程序里猜可靠得多。

5.2 接口一直 404，代码里路径看起来没错

现象：启动服务端后，前端请求登录接口，控制台显示 404，但接口路径和后端路由看起来完全一样。原因：最常见的是后端有统一前缀，比如路由写在/api/v1/user/login，但前端baseUrl里已经写了/api/v1，请求最终变成/api/v1/api/v1/user/login；还有一种是服务端监听了/api，但前端多写了端口，或路径大小写不一致。解决：先用浏览器或 curl 直连后端接口，确认可用的完整 URL 是什么样的，再对着前端baseUrl和url拼一层。不要用视觉比对，直接复制最终地址到浏览器打开，最有效率。如果curl得到 404，再看后端路由表，用grep -rn "router.*login" server/routes找到真正注册的路径。

5.3 删除日程后列表不刷新，必须手动下拉

现象：点击删除，提示“删除成功”，但页面列表里的那条记录还在，要重新下拉或退出页面再进来才消失。原因：删除成功的回调里只弹了 toast，没有删除本地数据，也没有重新拉列表。前端data里的数组还是旧数据，视图自然不会更新。解决：在删除回调里同步更新data。如果后端没有返回剩余列表，就先用setData把当前项从数组里过滤掉；更稳妥的方式是调用列表接口重新请求：

wx.request({ url: `${baseUrl}/schedule/${id}`, method: 'DELETE', success: (res) => { if (res.data.code === 0) { this.setData({ list: this.data.list.filter(item => item.id !== id) }); wx.showToast({ title: '已删除', icon: 'success' }); } } });

这里还有个隐藏问题：如果列表接口本身返回按时间排序，删除后重新拉列表会比 filter 更可靠，因为 filter 只处理了当前页数据，删除位置附近的列表顺序不会变。我的习惯是“删除后直接重新拉首页列表”，这样成本低且能顺便刷新状态。注意请求失败时也要恢复按钮状态，否则界面会停在“删除中”。

5.4 数据库脚本导入报错，或者服务端连不上数据库

现象：执行SOURCE schedule.sql时报错，可能是Unknown database、语法错误，或者导入成功后后端起不来，日志提示Can't connect to database。原因：第一，建库语句和建表语句顺序问题，部分脚本不会自己建库，你需要先建库再导入；第二，字符集不统一，脚本里有 emoji 或中文字段，而表的字符集是latin1；第三，服务端配置里的数据库密码、库名与本地不一致。解决：导入前先手动执行一次：

CREATE DATABASE IF NOT EXISTS schedule_db DEFAULT CHARACTER SET utf8mb4;

然后重新USE schedule_db再SOURCE。服务端连不上时，先检查.env或配置文件里db.user和db.password，不要想当然认为和 MySQL 命令行输入的账号一致。如果还是不行，在服务端代码里临时加一行console.log(config.db)输出配置，看看实际读到的是什么。血泪经验：很多同学把密码写错成默认的123456，但自己的 MySQL root 密码是别的值，这一行日志能立刻救回来。

5.5 说明文档、演示视频和源码三者对不上

现象：说明书写着“登录就是微信一键登录”，但源码里是用户密码；视频里有日历视图，代码里找不到对应页面。原因：很多毕设资源包是不同阶段打包的，视频是演示时录制，说明文档是早期版本，源码是最终提交；也可能是从别的项目改造时把文档留在了原项目。解决：以源码为准，视频只当作“预期效果”的参考。找不到视频里的页面时，别按页面名找，直接搜索拼音或关键词。比如视频里点了“统计”，源码里可能叫statistics或charts，用全局搜索字符串最有效：

grep -rIn "统计\|chart\|calendar\|日历时" --include="*.js" --include="*.wxml" --include="*.json" .

如果确实没有实现，那就在答辩材料里明确说明“我在原项目基础上增加了统计功能”，而不是隐瞒。比起让评委发现功能对不上，主动讲清楚改了什么更能拿分。文档里的接口列表可以当作参考，但真正可用的接口一定以服务端routes目录为准。

6. 答辩前的三个验证：给项目装上“后悔药”

我发现最容易翻车的时候不是开发，而是答辩前十分钟。电脑休眠唤醒后 MySQL 没启动，或者服务端被上一个演示同学占用端口，都是真实事故。所以我会准备一个三分钟的检查流程，每次演示前按顺序做一遍。

第一项，确认数据库能连上。直接执行一条最简单的查询：

mysql -u root -p -e "USE schedule_db; SHOW TABLES;"

能看到表结构，说明数据库服务正常。看不到，就检查 MySQL 是否启动。第二项，确认服务端还活着。用一行命令看健康检查接口：

curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:3000/health

返回200就继续；如果超时或 502，回终端重启npm run dev。第三项，确认小程序真机是亮的，且不是休眠前打开的旧进程。我最常用的是“清后台重新进入”的方式，因为旧进程可能还连着旧接口或缓存了错误数据。这三个检查跑完，再按“登录 → 新增 → 编辑 → 删除 → 查看统计”的路径快速过一遍，基本就能稳住正式演示。

如果你还想多做一步，可以把这三个检查写成一个check.sh脚本丢在桌面，因为脚本里记录了端口和账号，也帮你固定住“项目应该怎么启动”的记忆。我就是靠这个习惯救过自己一次：当时答辩前电脑刚重启，MySQL 服务没自启，我跑了一遍脚本才发现，半分钟解决，而不是整个人愣在台上。希望这个清单也能帮到你，让毕业设计在演示时少一点玄学，多一点底气。

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