企业官网建设流程全解析

我做毕业设计辅导这几年，见过太多同学在“选题”这一步就卡住了。要么选了太大太空的题目，论文写不下去；要么选了太偏门的技术栈，连环境都搭不起来。今天要拆的这个题目——基于微信小程序的日常活动记录系统，属于那种看着不起眼、但实际做起来非常舒服的毕设类型。功能闭环完整，技术栈大众化，文档也好写，而且做完之后你真能拿它当个习惯打卡工具用起来，不是那种答辩完就删库的“僵尸项目”。

尤其要注意的是，这种带“源码+LW文档”的毕设资源，网上流传的往往是残缺的。有的只给了前端代码，后端接口全是Mock；有的LW文档是从别的题目抄的，字段都对不上。这篇文章我不光把这个系统的核心设计和解法掰开揉碎讲清楚，还会把我自己复现这类项目时踩过的坑、排查过的报错全部列出来，给正准备做类似题目的同学一个能直接照抄的解题思路。

1. 这个选题为什么“很能打”：需求拆解与技术选型思路

1.1 日常活动记录系统到底解决什么问题

先别急着写代码，把题目读三遍。“日常活动记录”这个词听起来很简单，但落到毕设的场景里，它其实是一个信息管理系统的变体。核心逻辑绕不开三件事：

• 用户能不能方便快捷地记录一条活动（比如跑步、阅读、写代码、喝水）；
• 记录完之后，用户能不能看到历史数据的统计和规律（比如这一周运动了几天）；
• 用户和管理员之间，数据权限怎么划分（用户看自己的，管理员能不能看全部的）。

很多同学把这类系统理解成“记账本”，一上来就画了三张表：用户表、记录表、分类表。这样确实能做出来，但答辩的时候老师一般会追问一个问题：“你为什么要用微信小程序来做？换成网页不行吗？”

这个问题，其实就是整个选型的起点。日常活动记录的使用场景天然是碎片化的、高频率的。你跑步的时候不可能打开网页登录、找到入口、填一张表单；但掏出手机，打开小程序，可能三次点击就搞定了一条记录。微信小程序不需要安装、用完即走、还能通过订阅消息做每日提醒，这三条特性决定了它是这类轻量级记录工具的最佳载体。

1.2 为什么选微信小程序而不是原生App或H5

这里不用讲太深的技术对比，你只需要在开题报告和LW文档的“技术选型”章节里把逻辑说通就行。我整理了一张对比表，直接抄进文档也能用：

负责人一看这张表，基本就明白你做的是合理的判断题，而不是跟风选了一个热门词。

技术栈方面，我的建议是不要搞花活。前端就用微信小程序原生框架（WXML + WXSS + JS），后端优先选Node.js + Express或者Java + Spring Boot，数据库用MySQL。原因很简单：你是来做毕业设计的，不是来给大厂做高并发架构的，技术栈越主流，你搜到的资料越多，答辩老师也不会在冷门框架上刁难你，因为他自己大概率也只会主流的。

2. 系统架构设计与数据模型：把后端接口想清楚再动手

2.1 前后端分离的轻量级架构

日常活动记录系统不需要微服务，更不需要消息队列。一个标准的前后端分离 + RESTful API架构就完全够用。项目从物理上分成三块：

wx-miniapp/ # 微信小程序前端 ├─ pages/ │ ├─ index/ # 首页：今日概览 + 快捷记录 │ ├─ record/ # 添加/编辑活动记录 │ ├─ stats/ # 数据统计 │ ├─ profile/ # 个人中心 │ └─ admin/ # 管理员视角（可选） ├─ utils/ │ ├─ request.js # 封装 wx.request │ └─ util.js # 日期格式化等 └─ app.js server/ # 后端服务 ├─ routes/ # 接口路由 ├─ controllers/ # 业务逻辑 ├─ models/ # 数据模型 └─ app.js # 入口 doc/ # LW文档（毕业论文/设计说明书）

前后端分离的好处是：你在写LW文档的“系统设计”一章时，可以很自然地画出架构图，然后对着图拆解每一个模块的职责。而且如果时间不够，后端接口可以先写好，前端用微信开发者工具里的“不校验合法域名”模式直接联调，不用急着买服务器和域名。

2.2 数据表设计——核心字段与关联关系

数据库设计是整个系统的地基，也是LW文档里最容易被老师挑刺的地方，一定要谨慎。

我按一个完整可答辩的标准，设计了下面这几张表：

用户表（user）

这里有个关键点：不要用微信的wx.login()返回的 code 直接当用户ID。code是临时凭证，5分钟就失效了。正确流程是：小程序端调用wx.login()拿到 code，传给后端，后端用 code 换 openid（需要调用微信的接口jscode2session），再用 openid 去 user 表里查或建记录，最后下发一个自定义的 token。以后的每次请求，前端带上这个 token，后端就认出你是谁了。

活动分类表（category）

为什么要单独分一张分类表？而不是在记录表里直接存一个字符串字段？

原因有两个。第一，方便做统计：你要在统计页按分类维度聚合数据，如果记录表里直接用varchar存分类名，SQL里就得做字符串匹配，效率低还容易因为空格、错别字导致统计不精确。独立的分类表让分类有稳定的ID，聚合查询只要GROUP BY category_id就行。第二，用户有自定义分类的需求，预设的分类不可能覆盖所有活动类型，分离出来可以很自然地支持“用户自定义分类”。

活动记录表（activity_record）

这里最容易被忽略的是record_date为什么不直接用create_time。因为系统要支持补录——你可能昨天忘了记，今天早上补一条昨天的记录。这个字段如果设计错了，统计页的“每日打卡日历”功能根本没法做。

3. 核心功能模块实现：从登录鉴权到数据可视化

3.1 用户登录与授权——别在第一步就翻车

微信小程序的登录是很多新手第一个翻车点。简化后的完整流程如下：

小程序端：

// utils/auth.js function login() { return new Promise((resolve, reject) => { wx.login({ success: async (res) => { if (res.code) { try { // 将临时code发送到后端 const data = await request({ url: '/api/user/login', method: 'POST', data: { code: res.code } }); // 存储token到本地缓存 wx.setStorageSync('token', data.token); wx.setStorageSync('userInfo', data.userInfo); resolve(data); } catch (err) { reject(err); } } else { reject(new Error('登录失败：' + res.errMsg)); } }, fail: (err) => reject(err) }); }); }

后端（以Node.js为例）：

// controllers/userController.js const axios = require('axios'); const jwt = require('jsonwebtoken'); const APPID = '你的小程序AppID'; const SECRET = '你的小程序AppSecret'; exports.login = async (req, res) => { const { code } = req.body; // 使用 code 向微信服务器换取 openid const url = `https://api.weixin.qq.com/sns/jscode2session?appid=${APPID}&secret=${SECRET}&js_code=${code}&grant_type=authorization_code`; const { data } = await axios.get(url); if (!data.openid) { return res.status(401).json({ message: '微信登录失败', error: data.errmsg }); } // 在数据库中查找或创建用户 let user = await User.findOne({ where: { openid: data.openid } }); if (!user) { user = await User.create({ openid: data.openid, nickname: '微信用户' + Math.random().toString(36).slice(2, 8), role: 0 }); } // 签发JWT token，有效期7天 const token = jwt.sign({ userId: user.id }, 'your_jwt_secret', { expiresIn: '7d' }); res.json({ token, userInfo: { id: user.id, nickname: user.nickname, avatarUrl: user.avatarUrl } }); };

注意：微信的jscode2session接口，每天的调用量是有限制的，开发调试的时候还好，但如果真上线运行，用户量大起来，建议用app.json里的login配置配合云开发来减轻压力。不过毕设场景下，自建接口完全够用。

3.2 活动记录与打卡——提交表单和双端校验

记录页是小程序的核心交互页面。前端是一个简单的表单：选择分类、填写内容、选择日期、填持续时间、提交。这个页面技术上不难，真正需要小心的反而是交互体验——你想想，用户是来“快速记录”的，不是来填政府表格的。

我的建议是：

1. 分类用“宫格选择”而非下拉框：运动、阅读、学习、喝水、写代码……一排排图标点一下就行；
2. 日期默认选今天，但允许点击修改，方便补录；
3. 内容输入框要支持默认占位提示，比如“今天做了什么？”，减少输入负担；
4. 提交后要有成功反馈，比如wx.showToast({ title: '记录成功', icon: 'success' })，然后跳转回首页列表。

后端接口的设计要遵循“前端传什么，后端验什么”。我见过很多毕设代码，后端接口对参数完全不做校验，前端传啥它存啥，这种代码答辩时被老师压测一下就能发现漏洞。下面这个写法是标准模板：

exports.createRecord = async (req, res) => { const userId = req.userId; // 从JWT中间件获取 const { categoryId, content, recordDate, duration } = req.body; // 参数校验 if (!categoryId || !content) { return res.status(400).json({ message: '分类和内容不能为空' }); } if (recordDate && isNaN(new Date(recordDate).getTime())) { return res.status(400).json({ message: '日期格式不正确' }); } try { const record = await ActivityRecord.create({ user_id: userId, category_id: categoryId, content: content.trim(), record_date: recordDate || new Date().toISOString().slice(0, 10), duration: duration || 0 }); res.status(201).json({ message: '记录成功', recordId: record.id }); } catch (err) { res.status(500).json({ message: '服务器内部错误' }); } };

3.3 数据统计与可视化——用ECharts还是用Canvas手绘

统计页面是这类系统的“加分项”，也是LW文档里可以重点截图展示的模块。你要用柱状图展示“近7天各分类活动频次”，用饼图展示“分类占比”，再用一个日历控件展示“本月打卡天数”。

绘图方案无所谓好坏，但你要知道代价：

• ECharts：功能最全，图形好看，但引入包体积较大（压缩后约300KB），小程序要做分包加载，而且涉及到ec-canvas组件的适配。我用下来感觉整体稳定，但调试时容易遇上版本兼容问题。
• wx-charts：轻量很多，但项目维护不够活跃，图表类型有限，遇到复杂需求得魔改源码。
• Canvas自绘：适合那种只画一个简单柱状图的情况，代码量不多，而且彻底避免依赖问题。但如果要画坐标轴、网格线、tooltip，工作量就上来了。

个人建议直接用ECharts 的 ec-canvas，社区资料最多。唯一注意：在onLoad里初始化图表之前，一定要确保canvas 的宽高已经从 rpx 换算成了 px。这里报错通常是获取不到节点信息，原因是wx.createSelectorQuery()在页面还没渲染完成时执行了。

下面是统计页一个“近7天活动次数”柱状图的标准写法：

// pages/stats/stats.js const wxCharts = require('../../utils/wx-charts.min.js'); Page({ data: { chartData: null }, onLoad() { this.loadStats(); }, loadStats() { // 请求后端统计接口 request({ url: '/api/stats/weekly', method: 'GET' }).then((res) => { const categories = res.map(item => item.categoryName); const counts = res.map(item => item.count); this.drawWeeklyChart(categories, counts); }); }, drawWeeklyChart(categories, counts) { const chart = new wxCharts({ canvasId: 'weeklyChart', type: 'column', categories: categories, series: [{ name: '活动次数', data: counts }], width: 320, height: 220, xAxis: { disableGrid: true }, yAxis: { min: 0 } }); } });

对应的WXML就只需要放一个canvas节点：

<view class="chart-container"> <canvas canvas-id="weeklyChart" id="weeklyChart"></canvas> </view>

后端统计接口的SQL如果用Sequelize写，大概长这样：

// controllers/statsController.js const { Op } = require('sequelize'); exports.getWeeklyStats = async (req, res) => { const userId = req.userId; const startDate = new Date(Date.now() - 7 * 24 * 60 * 60 * 1000).toISOString().slice(0, 10); const stats = await ActivityRecord.findAll({ attributes: [ 'category_id', [sequelize.fn('COUNT', sequelize.col('id')), 'count'] ], where: { user_id: userId, record_date: { [Op.gte]: startDate } }, group: ['category_id'], include: [{ model: Category, attributes: ['name'] }], raw: true }); res.json(stats); };

3.4 管理员端与数据权限——毕设加分项

很多同学会忽略管理员端，觉得“日常活动记录”这种纯个人工具不需要管理员。但毕设系统如果要“完整”，通常要求有前后台、有不同角色。哪怕你做一个极简版的管理员页面，只允许管理员查看所有用户的记录列表、统计全站活跃度，在答辩时的“功能完整性”评分项上就能拉开差距。

实现上不需要单独建一个管理后台项目，直接在小程序里按角色渲染不同入口即可：

// app.js 里存储全局登录态 const userInfo = wx.getStorageSync('userInfo'); if (userInfo.role === 1) { // 注册tabBar页面或者在个人中心显示“管理入口” }

后端对所有涉及数据的接口都做一层权限校验：

// middleware/auth.js const jwt = require('jsonwebtoken'); module.exports = function auth(req, res, next) { const token = req.headers.authorization?.split(' ')[1]; if (!token) { return res.status(401).json({ message: '未登录或登录已过期' }); } try { const decoded = jwt.verify(token, 'your_jwt_secret'); req.userId = decoded.userId; next(); } catch (err) { return res.status(401).json({ message: 'token无效' }); } }; // 管理员专属接口，额外校验role module.exports.requireAdmin = async (req, res, next) => { const user = await User.findByPk(req.userId); if (!user || user.role !== 1) { return res.status(403).json({ message: '无权限访问' }); } next(); };

4. 从0到1的完整搭建过程：环境、代码与LW文档并行推进

4.1 环境准备与账号申请——半天搞定，别拖延

开工之前，先把下面这几样准备好。我发现很多同学进度卡住，都是因为在“AppID申请”或“工具版本”这些最基础的地方耗了太久。

小程序开发工具有个细节：创建项目时，如果不填AppID，可以选“测试号”，游客模式能跑通大部分功能，但不能调用登录接口，也不能真机预览。所以还是建议注册一个个人小程序账号，秒批。

4.2 小程序前端关键代码实现——列表加载与上拉刷新

列表页是“今日概览”和“历史记录”的主要呈现方式。这里必须用到热搜词里反复出现的那个需求：页面列表加载更多。

微信小程序里，实现“触底加载更多”的标准方法是使用页面生命周期回调onReachBottom。配合一个简单的分页状态机：

// pages/index/index.js Page({ data: { records: [], page: 1, pageSize: 10, hasMore: true, loading: false }, onLoad() { this.loadRecords(true); }, onReachBottom() { // 触底时判断是否还有更多数据 if (this.data.hasMore && !this.data.loading) { this.loadRecords(false); } }, loadRecords(reset) { const { page, pageSize, loading } = this.data; if (loading) return; this.setData({ loading: true }); const targetPage = reset ? 1 : page; request({ url: '/api/records', data: { page: targetPage, pageSize } }).then((res) => { const newRecords = reset ? res.list : this.data.records.concat(res.list); this.setData({ records: newRecords, page: targetPage + 1, hasMore: newRecords.length < res.total, loading: false }); }).catch(() => { this.setData({ loading: false }); }); }, // 下拉刷新 onPullDownRefresh() { this.loadRecords(true).then(() => { wx.stopPullDownRefresh(); }); } });

这段代码有几个容易踩的细节：

1. reset 与 append 要分开：下拉刷新是重置列表，触底加载是追加列表。如果把两个逻辑混在一个函数里不做区分，刷新后页面会越拉越长。
2. loading 锁：在请求发出期间置为 true，防止用户疯狂触底导致重复请求。
3. hasMore 判定：后端返回{ list, total }，当已加载数量newRecords.length >= total时，触底不再发请求。这是“列表加载更多”免于无限请求的核心。

对应WXML，建议在列表底部加一个状态提示：

<view class="list-container"> <block wx:for="{{records}}" wx:key="id"> <view class="record-item"> <view class="record-category">{{item.categoryName}}</view> <view class="record-content">{{item.content}}</view> <view class="record-date">{{item.recordDate}}</view> </view> </block> <view class="list-footer"> <text wx:if="{{loading}}">加载中...</text> <text wx:elif="{{!hasMore}}">没有更多了</text> </view> </view>

4.3 LW文档写作要点——这7000字比几千行代码更值钱

拿到“源码+LW文档”资源时，大多数同学最关心的是代码能不能跑起来。但我可以负责任地说，答辩老师看重的反而是文档的逻辑完整性。

LW文档通常需要包含以下章节，我建议按这个顺序写：

第一章 绪论：写清楚研究背景和意义。不要上来就“随着移动互联网的发展”，这种套话分不高。改个写法：“现代人缺乏对日常时间的感知，运动、阅读、学习等碎片活动难以量化记录，传统的纸质记录方式存在携带不便、统计困难的问题，因此设计一款随时可用的移动端记录工具具有现实意义。”——有理有据、贴合场景、又有痛点。

第二章 相关技术介绍：逐一把微信小程序、Node.js/Spring Boot、MySQL、JWT的特点写清楚。这块比较简单，算是全文的“基础分”。

第三章 需求分析：画用例图、写功能需求表（模块、功能描述、优先级）、梳理非功能需求（性能要求、安全性要求）。

第四章 系统设计：画系统架构图、数据库ER图、各功能模块流程图。这里的图表尽量用Visio或draw.io画得规范一些，老师第一眼看的就是图表质量。

第五章 系统实现：逐个模块贴核心代码，配截图。关键代码加上注释，说明这段代码实现了什么逻辑，为什么这么做。

第六章 系统测试：一定要有测试用例表格和测试结果。不需要高大上的自动化测试，把“正常添加记录”“空内容添加被拦截”“未登录访问被拒”这类用例列出来就行。

5. 高频报错排查与避坑实录：从崩溃到跑通的经验

5.1 真机预览白屏，开发者工具却一切正常

这是小程序开发最玄学的问题之一。表现是：开发者工具里页面渲染得好好的，一扫码真机预览就空白。

排查顺序：

1. 确认是否开启了“不校验合法域名”：开发者工具右上角“详情-本地设置-不校验合法域名”，这个选项只影响工具环境。真机预览不受这个开关控制，如果你的后端接口是HTTP明文或者IP:Port形式，在真机上会被微信拦截，导致请求失败页面空白。
2. 检查网络权限：个人主体的小程序默认没有配置“服务器域名”，预览时有“开发版”权限，可以在小程序后台“开发管理-开发设置-服务器域名”里临时添加，或者使用“预览二维码”时开启“开发模式”。
3. Console日志定位：真机预览时，打开手机上的“调试”按钮（右上角菜单），查看具体报错信息。这一步能过滤掉90%的“瞎猜”环节。

5.2 返回的日期总是差8小时，所有时间记录全错位

这个坑我几乎在每届学生项目里都能看到。小程序端传给后端的日期字符串，因为时区处理不对，导致数据库里存的时间比实际时间早了8小时。

原因在于new Date('2024-06-01').toISOString()的行为——如果没有指定时区，JavaScript会把它当作UTC时间，而中国是UTC+8，于是转换之后就变前一天了。

安全的做法是：所有日期字符串的传递，统一用YYYY-MM-DD格式，不要经过toISOString()转换。后端接收时也不要用new Date(str)，改用字符串直接存DATE类型字段，或者手动拼接：

function formatDate(date) { const y = date.getFullYear(); const m = String(date.getMonth() + 1).padStart(2, '0'); const d = String(date.getDate()).padStart(2, '0'); return `${y}-${m}-${d}`; }

5.3 “没有更多了”永远不出现，列表一直在加载

原因基本都出在hasMore的计算逻辑上。前端newRecords.length < res.total，如果后端返回的total是undefined或者不是数字，这个比较永远为 false，hasMore永远是 true。

排查方法很简单：在loadRecords的回调里先打印一下res结构，看看res.total是否存在。如果接口返回的是{ code: 0, data: { list, total } }这种嵌套结构，你直接读res.total肯定拿不到。

另外注意concat的类型问题：如果res.list是 null 或返回了对象结构，concat之后的结果会变得莫名奇妙，同样会导致渲染异常。

5.4 自定义导航栏导致顶部高度错位

如果你在小程序的app.json里设置了"navigationStyle": "custom"，那么页面顶部就变成全屏无状态栏了，你的内容会从屏幕最顶上开始渲染。如果不在合适的布局里做 ----------------padding，文字就会被刘海屏吃掉。

常见做法是在页面顶部加一个占位块，高度用wx.getMenuButtonBoundingClientRect()动态获取：

// 获取胶囊按钮位置信息 const menuButton = wx.getMenuButtonBoundingClientRect(); // 状态栏高度一般从 wx.getSystemInfoSync() 获取 const systemInfo = wx.getSystemInfoSync(); this.setData({ statusBarHeight: systemInfo.statusBarHeight, navBarHeight: (menuButton.top - systemInfo.statusBarHeight) * 2 + menuButton.height });

顶部视图：

<view style="height: {{statusBarHeight}}px;"></view> <view style="height: {{navBarHeight}}px;">自定义导航栏</view>

热搜词里还出现了“顶部导航栏高度”，说明这是个高频关注点。很多同学直接写死padding-top: 64px，在部分安卓机上会出现明显的错位，用上面的动态获取方法才是正确的通用解。

5.5 打包超限，2MB的坎怎么过

微信小程序主包大小限制是2MB，热搜词里那条“source size 2612kb exceed max limit 2mb”，意味着代码已经超了。超了以后真机预览直接失败，开发者工具里弹红字。

常见罪魁祸首和解决办法：

1. 图片资源过大：UI切图最好用扁平的图标，把图片压缩到几KB内；背景图尽量去掉了，用纯色或CSS渐变代替。
2. ECharts体积过大：如果只是要个简单图表，考虑从 ECharts 官方定制构建，只包含柱状图、饼图和折线图的模块，体积会从300KB降到100KB以内。
3. 处理“分包”：将管理后台页面、统计图表页面、其他低频页面单独放进subPackages分包，主包只保留首页、tabBar页面和公共依赖。

app.json分包配置示例：

{ "pages": [ "pages/index/index", "pages/record/record", "pages/stats/stats", "pages/profile/profile" ], "subPackages": [ { "root": "pagesAdmin", "pages": [ "admin/userList", "admin/stats" ] } ], "preloadRule": { "pages/index/index": { "network": "all", "packages": ["pagesAdmin"] } } }

注意：tabBar 页面不能放在分包里，分包加载的重点是“内容页”而不是“框架页”。

5.6 后端接口联调时的CORS与域名校验

开发阶段前端用wx.request请求本地http://localhost:3000或局域网IP，在开发者工具里能通，但手机预览就不行了。小程序的网络请求有极其严格的域名限制：必须HTTPS、必须在小程序后台添加域名白名单。

在没有服务器和正式域名的情况下，建议用内网穿透工具（cpolar、natapp都行），生成一个临时HTTPS域名，既能真机调试，又不用马上买服务器。联调完了把接口地址从前端代码里提取到一个公共配置文件中：

// config.js module.exports = { baseUrl: 'https://your-domain.com/api' // 上线时替换 };

所有页面统一从request.js读取config.baseUrl，这样后续切换到正式服务器只需要改一个文件。

6. 拿到“免费源码”后的第一件事：先审计再跑通

现在回到标题里那行“源码+LW文档免费”。这类资源在GitHub、博客、网盘里非常多，但我强烈建议你拿到手之后不要急着解压运行，先做三件事：

1. 审计代码质量：看看后端有没有硬编码数据库密码、接口有没有做登录鉴权、SQL有没有拼接注入风险。很多开源毕设项目为了“演示方便”，把安全校验全部阉割了，你直接拿去答辩，老师一眼就能看出是“半成品”。
2. 理清目录结构和启动方式：先找README或者文档里的部署说明。如果连启动方式都没写清楚的项目，大概率代码也是拼凑的，跑通它花费的时间可能远超自己写一遍。
3. 核对LW文档与代码是否一致：这一点最关键。论文里的数据表结构要和代码里的model完全对应，否则答辩时老师一翻数据库，文档里写的表和实际表对不上，那是致命的。

另外提醒一句：免费源码往往会带一些加密混淆的公共组件（比如某些图表库或登录组件），这些组件一旦出问题你根本没法调试。别迷信“免费”，不如自己从零搭一遍，过程中把关键代码理解透，答辩的时候才能讲得出东西。

从需求分析到架构设计，从数据库建模到接口实现，从LIST加载更多到打包体积优化，这整套流程走完，你收获的不只是一份能过查重的论文和一套能演示的系统，更重要的是你把这个领域从“听说过微信小程序”变成了“我能用它做一个小而美的产品”。这个小项目放进简历作品集里，面试官问起项目的技术难点时，你可以聊上拉分页的竞态问题、聊ECharts定制的体积优化、聊JWT登录态管理——这些都是实打实的开发经验，比背十道面试题有用得多。

我的建议是，拿到题目后第一周啥也不写，先把上面第2、3章的逻辑梳理清楚，把表结构画出来，让指导老师看一眼。确认设计没问题，再开始写代码，你会发现在漫长的调bug过程中，前期设计带来的顺畅感是难以替代的。祝各位毕设顺利。