企业官网建设流程全解析

如果你点进来，十有八九是冲着“基于JS的个人云盘管理系统”这个题目来的。这个题在我当年选题表上第一眼看上去并不难，一个云盘不就是“上传文件 + 文件列表 + 下载”吗？真正动手写代码才发现，这个看起来人畜无害的课题，把前端交互、后端接口、数据库设计、文件上传、权限控制、安全防护全都串到了一起，任何一个环节没处理好，都能让你在答辩前夜对着满屏报错怀疑人生。这篇博文，我就从一个刚把完整项目做完的同学视角，把这个课题从技术选型、数据库设计、核心代码，到论文怎么写、PPT怎么讲、演示视频怎么录，整条链路都摊开讲一遍。不管你现在是刚拿到题目还不知道从哪下手，还是代码写得半死不活准备补功能，这篇文章应该都能让你少走很多弯路。

1. 动手之前先定方案：技术选型与整体设计

1.1 为什么我的最终选型是“原生JS + Node.js + MySQL”

先解决第一个问题：题目里写的是“基于JS”，这个范围其实很宽。JS能跑在浏览器里，也能跑在服务器上，还能用来做桌面应用。最稳妥、最适合毕业设计的路线，就是“浏览器里的原生JavaScript + Node.js后端 + MySQL数据库”，一个纯正的JS全栈方案。

我的具体选型是：

• 前端：原生 HTML + CSS + JavaScript，配合 axios 发请求，页面结构用简单的模块化拆分
• 后端：Node.js + Express 框架
• 数据库：MySQL
• 文件存储：服务器本地磁盘，按用户和日期分目录保存

有人可能会问，为什么不用 Vue 或 React ？我的回答是：如果做课程设计或者毕业设计，用框架当然可以，但原生JS能让你把请求怎么发、数据怎么处理、DOM 怎么渲染这套底层逻辑讲得更清楚。答辩的时候老师最喜欢问的就是“你这个列表数据是怎么从后端拿过来的”“上传进度条是怎么实现的”，你要是用原生JS写的，随便往深处问都能答上来。用脚手架搭出来的项目，有时候反而容易卡在框架原理上。

还有一点很实际：论文工作量。如果你全程用框架，导师可能会觉得工作量不饱和，因为很多页面是组件化拼出来的。原生JS的代码细节更多，贴到论文里的核心代码也更饱满。而且原生JS对学生的前端基础是很好的锻炼，这套东西搞明白了，后面学什么框架都快。

1.2 功能模块划分：先做闭环，再铺亮点

个人云盘系统，表面上“上传下载”四个字就能概括，但真要做得像个正经系统，功能模块可以拆出这么几块：

• 用户模块：注册、登录、退出登录、会话保持
• 文件管理模块：文件上传、下载、删除、重命名、新建文件夹、文件移动、文件搜索
• 分享模块：生成分享链接、提取码、过期时间设置
• 回收站模块：把删除文件放进回收站、恢复文件、彻底删除
• 扩展功能：文件预览（图片、文本、视频）、大文件分片上传、秒传

我的建议是，开发顺序一定不要按照模块清单从头到尾做。先做“注册登录 → 上传 → 文件列表 → 下载/删除”这个最小闭环，让系统先能跑起来，然后再往上加文件夹、回收站、分享、预览这些功能。很多同学一上来就想着做炫酷的拖拽上传，结果地基还没打好，后面反复返工。

这个顺序也方便你控制风险：如果你时间不够，保底版本至少有一个完整可用的流程；如果时间充裕，再往上加亮点功能，每个功能都往论文里写一小节，工作量就很丰满了。

1.3 数据库设计：用三张表把业务撑起来

个人云盘系统的数据库设计不复杂，核心就三张表：用户表、文件表、分享表。

用户表：

文件表是核心，这张表设计得好不好直接影响后续功能好不好写：

分享表：

文件表里的 parent_id 字段是实现文件夹树的关键。新建文件夹就是插入一条 is_dir=1 的记录，浏览文件夹就是查 parent_id 等于当前文件夹ID的所有文件。回收站不需要单独建表，用 status 字段做软删除，在查询时过滤 status=1 就行，这样可以防止误删数据，也方便实现“恢复”功能。

数据库这块在论文里要画 E-R 图和表结构说明。我建议表结构的字段名设计得规范一些，注释写齐全，后期写论文能直接截图或者重新画图，省很多事。

2. 文件模块从零实现：上传、存储、下载与预览

2.1 文件上传的坑：从 multer 配置到文件名处理

文件上传是整个系统的核心，也是坑最多的地方。我用的方案是 Node.js 的 multer 中间件，配置磁盘存储模式，文件的保存路径和文件名都可以自己控制。核心代码如下：

const multer = require('multer'); const path = require('path'); const fs = require('fs'); const uploadDir = path.join(__dirname, '../uploads'); if (!fs.existsSync(uploadDir)) { fs.mkdirSync(uploadDir, { recursive: true }); } const storage = multer.diskStorage({ destination: function (req, file, cb) { const date = new Date(); const dayDir = `${date.getFullYear()}${date.getMonth() + 1}${date.getDate()}`; const targetDir = path.join(uploadDir, dayDir); if (!fs.existsSync(targetDir)) { fs.mkdirSync(targetDir, { recursive: true }); } cb(null, targetDir); }, filename: function (req, file, cb) { const ext = path.extname(file.originalname); const uniqueName = Date.now() + '_' + Math.random().toString(36).slice(2, 8) + ext; cb(null, uniqueName); } }); const upload = multer({ storage: storage, limits: { fileSize: 100 * 1024 * 1024 } });

这里有几个细节必须注意。文件名一定不要直接用用户上传的原始名字，因为不同用户可能上传同名文件，而且中文文件名在某些环境下会出编码问题。我用“时间戳 + 随机字符串 + 原扩展名”生成新文件名，把原始文件名存到数据库的 file_name 字段，展示给用户时读数据库里的名字，这样就彻底把“存储名”和“展示名”解耦了。

上传接口用 multer 的单文件中间件处理：

app.post('/api/upload', upload.single('file'), (req, res) => { if (!req.file) { return res.json({ code: 1, msg: '未接收到文件' }); } // 把文件信息写入数据库，返回文件ID给前端 const fileData = { user_id: req.user.id, file_name: req.file.originalname, file_url: path.relative(uploadDir, req.file.path), file_size: req.file.size, file_type: path.extname(req.file.originalname), parent_id: req.body.parent_id || 0, md5: req.body.md5 || '' }; // 执行 INSERT，返回新插入的 id res.json({ code: 0, data: { fileId } }); });

前端用 axios 配合 FormData 提交文件。要注意的是，Express 的 body-parser 不需要也不能解析 multipart 格式，这部分的坑后面专门讲。

2.2 大文件分片上传：毕设答辩的加分亮点

如果你的系统只支持普通上传，答辩时大概率会被问：“如果上传一个 2GB 的视频，或者网络中断了怎么办？”这时候如果你做了分片上传和断点续传，就是稳稳的加分项。

分片上传的思路其实不复杂：前端把大文件切成多个小块，逐个上传，全部传完后通知后端把分片合成完整文件。我实现的时候分片大小定的是 5MB，这个值在普通网络环境下比较均衡，分片太多会导致请求数量过大，分片太少又失去了分片的意义。

前端分片的核心逻辑：

function sliceFile(file, chunkSize = 5 * 1024 * 1024) { const chunks = []; let start = 0; while (start < file.size) { chunks.push(file.slice(start, start + chunkSize)); start += chunkSize; } return chunks; } // 每个分片都带上分片序号和文件唯一标识 const uploadId = Date.now() + '_' + file.name + '_' + file.size; chunks.forEach((chunk, index) => { const formData = new FormData(); formData.append('chunk', chunk); formData.append('uploadId', uploadId); formData.append('index', index); formData.append('total', chunks.length); axios.post('/api/upload/chunk', formData); });

后端接收每个分片后单独保存，等到最后一个分片到达时触发合并。分片文件先存在一个临时目录，文件名用 uploadId_index 这种格式，合并时按 index 顺序读取拼接成完整文件。合并的代码：

async function mergeChunks(uploadId, total, fileName) { const chunkDir = path.join(uploadDir, 'chunks', uploadId); const ext = path.extname(fileName); const finalPath = path.join(uploadDir, `${Date.now()}_${Math.random().toString(36).slice(2, 8)}${ext}`); const writeStream = fs.createWriteStream(finalPath); for (let i = 0; i < total; i++) { const chunkPath = path.join(chunkDir, String(i)); await new Promise((resolve, reject) => { const readStream = fs.createReadStream(chunkPath); readStream.pipe(writeStream, { end: false }); readStream.on('end', resolve); readStream.on('error', reject); }); } writeStream.end(); return finalPath; }

分片上传天然就支持断点续传：如果某个分片没传成功，重新上传时只需要检查哪些分片已经存在，跳过已存在的分片继续传就行。不过这里要说明一点，断点续传的完整实现还涉及前端“记住上传进度”的问题，页面刷新后要能恢复，实际做的时候建议用 localStorage 存一下已上传分片列表。我当时时间有限，只做了“失败分片重传”的简单逻辑，就已经能在答辩时讲清楚了。

2.3 文件秒传去重：MD5 在个人云盘里的应用

秒传的意思是，当你上传一个服务器上已经存在的文件时，系统通过识别文件内容判断可以跳过真实上传，直接生成一条文件记录。个人云盘里做个简单的全局去重并不复杂，但对答辩来说是个很有讲头的点。

实现思路是前端用 spark-md5 计算文件的 MD5，上传前先向后端发一个查询请求：

// 前端计算MD5，file是File对象 const spark = new SparkMD5.ArrayBuffer(); const reader = new FileReader(); reader.onload = (e) => { spark.append(e.target.result); const md5 = spark.end(); // 发送查询 axios.post('/api/upload/check', { md5 }).then(res => { if (res.data.exists) { // 直接创建文件记录，不执行真实上传 } else { // 走正常上传流程 } }); }; reader.readAsArrayBuffer(file);

后端收到查询请求后，在文件表里查 md5 字段：

app.post('/api/upload/check', (req, res) => { const { md5 } = req.body; const sql = 'SELECT id, file_url, file_size FROM file WHERE md5 = ? AND is_dir = 0 LIMIT 1'; db.query(sql, [md5], (err, rows) => { if (rows && rows.length > 0) { return res.json({ code: 0, exists: true }); } return res.json({ code: 0, exists: false }); }); });

计算 MD5 对大文件来说需要一段时间，所以一般会在前端加一个异步计算的进度提示。还要注意，MD5 在这里只做去重，不涉及安全用途，所以不需要担心碰撞问题。这个功能在答辩时很好讲，因为它涉及了“文件指纹”“哈希算法”“去重逻辑”三个知识点，老师非常吃这一套。

2.4 下载与预览：单文件、批量压缩包与视频播放

文件下载接口需要设置响应头让浏览器识别为附件下载：

app.get('/api/download', (req, res) => { const fileId = req.query.id; // 先查数据库，确认文件存在且属于当前用户 const sql = 'SELECT * FROM file WHERE id = ? AND user_id = ?'; db.query(sql, [fileId, req.user.id], (err, rows) => { if (!rows || rows.length === 0) { return res.status(404).json({ msg: '文件不存在' }); } const file = rows[0]; const filePath = path.join(uploadDir, file.file_url); res.setHeader('Content-Type', 'application/octet-stream'); res.setHeader('Content-Disposition', `attachment; filename=${encodeURIComponent(file.file_name)}`); fs.createReadStream(filePath).pipe(res); }); });

这里有个重点：文件名必须用 encodeURIComponent 处理，否则中文文件名在下载时会乱码或者直接被浏览器拒绝。这个坑我在开发时踩过一次，后面会展开讲。

批量下载我是用 archiver 库把多个文件打包成 zip 再返回给前端，代码量不大，但对用户体验提升很明显，也是个值得写在论文里的功能点。预览功能可以这样处理：图片文件直接映射到静态目录，用<img>标签展示；文本文件用接口读取内容后渲染到页面上；视频文件用 HTML5 的<video>标签配合文件流地址播放。视频预览如果要支持拖进度条，还得实现 Range 请求，这个属于进阶内容，如果时间有限可以先不做，答辩时提一句“目前支持顺序播放，后续可扩展 Range 流式传输”就够了，不用真的做出来。

3. 用户系统实现：注册登录、会话保持与权限隔离

3.1 密码不能明文存：加盐哈希的正确姿势

个人云盘涉及用户文件，密码安全这块务必重视。最基础的要求就是密码不能明文存到数据库里。我用的是 Node.js 内置 crypto 模块做加盐哈希，没用 bcryptjs，因为内置模块无需额外安装，答辩时讲起来也更清楚。

const crypto = require('crypto'); function hashPassword(password) { const salt = crypto.randomBytes(8).toString('hex'); const hash = crypto.pbkdf2Sync(password, salt, 10000, 32, 'sha256').toString('hex'); return { salt, hash }; } // 注册时 const { salt, hash } = hashPassword(req.body.password); // 把 username, hash, salt 存入数据库 // 登录校验时 const sql = 'SELECT * FROM user WHERE username = ?'; db.query(sql, [req.body.username], (err, rows) => { if (!rows || rows.length === 0) { return res.json({ code: 1, msg: '用户名或密码错误' }); } const user = rows[0]; const hash = crypto.pbkdf2Sync(req.body.password, user.salt, 10000, 32, 'sha256').toString('hex'); if (hash === user.password) { // 密码正确，签发token } else { res.json({ code: 1, msg: '用户名或密码错误' }); } });

加盐哈希的原理很简单：同样的密码如果加了一个随机盐值再哈希，结果完全不同，这样攻击者就算拿到数据库，也很难通过彩虹表反推出原始密码。PBKDF2 迭代 10000 次是为了增大暴力破解成本。这个点也是答辩时一个很好的安全知识点，一定要能解释清楚。

3.2 登录状态用 Token 维持：从后端生成到前端携带

登录状态维护有两种常见方式：Session 和 Token。毕业设计我推荐用 Token，因为实现简单、前后端分离很自然、而且不用配置 Session 存储。

后端用 jsonwebtoken 签发 Token：

const jwt = require('jsonwebtoken'); // 登录成功后 const token = jwt.sign( { id: user.id, username: user.username }, 'your_secret_key', { expiresIn: '7d' } ); res.json({ code: 0, token });

前端把 Token 存到 localStorage，在 axios 请求拦截器里统一加上请求头：

axios.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = 'Bearer ' + token; } return config; });

后端做一个全局的鉴权中间件，除注册、登录、文件预览等公开接口外，其他接口都过一遍校验：

function authMiddleware(req, res, next) { const authHeader = req.headers.authorization || ''; const token = authHeader.split(' ')[1]; if (!token) { return res.status(401).json({ msg: '未登录' }); } try { const decoded = jwt.verify(token, 'your_secret_key'); req.user = decoded; next(); } catch (err) { return res.status(401).json({ msg: '登录已过期' }); } }

有个细节容易被忽略：前端如果做了“记住我”功能，不要直接在 localStorage 里存用户的用户名和密码，这是安全大忌。Token 本身带了过期时间，7 天过期后用户重新登录，这个体验对个人云盘来说完全够用。

3.3 文件权限隔离：为什么每个查询都必须带 user_id

个人云盘最怕的问题就是用户 A 访问到了用户 B 的文件。这个问题我在开发时专门测试过很多次，核心原则就一句话：所有文件相关的查询和操作，必须同时带上当前用户的 user_id。

拿删除接口举例：

app.post('/api/delete', (req, res) => { const { fileId } = req.body; // 错误示范：WHERE id = ? 这样任何用户都能删除这个文件 // 正确做法： const sql = 'UPDATE file SET status = 1, delete_time = NOW() WHERE id = ? AND user_id = ?'; db.query(sql, [fileId, req.user.id], (err, result) => { if (result.affectedRows === 0) { return res.json({ code: 1, msg: '文件不存在或无权操作' }); } res.json({ code: 0 }); }); });

这样即使用户恶意猜测请求参数，后端也会因为 user_id 不匹配返回“文件不存在或无权操作”。前端隐藏按钮只是体验优化，真正的安全屏障必须落在后端。

另外一个安全细节是文件路径的处理。后端在拼接文件实际路径时，如果直接使用前端传过来的文件名或路径参数，非常容易出路径穿越漏洞。比如用户构造一个 fileUrl 为../../etc/passwd的请求，后端如果直接path.join(uploadDir, fileUrl)，那就能读到系统文件了。我的做法是：下载和读取文件时一律通过数据库里查到的 file_url 字段来定位，绝不信任前端传的路径参数。

4. 毕业设计包装指南：论文结构、PPT 与演示视频

4.1 论文骨架怎么搭：八章内容安排与图表素材清单

代码做完只是完成了一半，论文写不好一样会翻车。基于JS的个人云盘管理系统这种题目，论文结构一般可以按下面八章来安排：

• 第一章 绪论：研究背景与意义、国内外研究现状、主要工作内容
• 第二章 相关技术介绍：JavaScript、Node.js、Express、MySQL、前端技术
• 第三章 系统需求分析：可行性分析、功能需求、非功能需求、用例图
• 第四章 系统设计：总体架构、功能模块设计、数据库设计（E-R图、表结构）、界面设计
• 第五章 系统实现：各模块的详细实现，附核心代码和运行效果截图
• 第六章 系统测试：测试环境、功能测试用例表、测试结果分析
• 第七章 总结与展望：总结工作内容，说明不足和未来改进方向
• 参考文献与致谢

这里我特别想提醒的一点是，论文里的截图一定要自己跑程序截，不要用网上的图片。我看到过有人从别人博客里截图放到论文里，结果图片水印还在，答辩时非常尴尬。建议在开发过程中就养成分模块截图的习惯，每个功能页面至少准备三张图：初始状态、操作中状态、完成后的结果状态。

论文里的核心代码不要贴大段大段的完整源码，贴关键片段就可以，配合文字解释代码逻辑。老师看的是你懂不懂，不是你的代码量。我当时的做法是每个核心模块贴 10 到 30 行代码，重点注释加粗描述，效果很好。

4.2 PPT 怎么讲不冷场：结构节奏与答辩话术

PPT 页数控制在 15 到 20 页之间，结构大概是：封面（1页）、目录（1页）、背景与意义（1页）、技术选型（1页）、需求分析（1-2页）、系统设计（3-4页）、功能实现展示（3-5页）、测试结果（1-2页）、总结与展望（1页）。

答辩最忌讳照着 PPT 念。我建议每个页面准备两三句“人话”，比如讲技术选型时可以说“我之所以选择原生JS，而不选择 Vue，是因为原生JS能在不依赖框架的情况下把核心交互过程完整呈现，也方便后续的二次开发”。千万不要说“我用这个框架是因为它很流行”，这样显得没有思考。

演示环节是最容易翻车的，后面我会给一个检查清单。这里先说一个答辩时的通用技巧：当你演示文件上传时，提前准备好一个小体积的示例文件，不要现场从桌面拖一个几 GB 的视频进去，页面卡两分钟那场面真的很难受。

4.3 演示视频怎么录：流程脚本与剪辑要点

演示视频一般要求 5 到 10 分钟，内容基本等于把答辩演示环节完整录一遍。我用的录屏工具是 OBS Studio，免费开源，设置输出分辨率 1920x1080、帧率 30、码率 8Mbps 以下的 MP4 格式，文件不会太大，画质也够清晰。

录之前一定要写一个流程脚本，按这个顺序走：

• 开场：系统名称和功能简介
• 用户注册新账号
• 登录系统，进入主界面
• 创建文件夹
• 上传文件（建议一个图片、一个文本文件、一个30MB左右的视频）
• 文件列表展示，演示重命名和移动
• 打开文件预览
• 生成分享链接，用提取码查看分享文件
• 删除文件，进入回收站，恢复文件
• 退出登录并总结

录制时尽量一次性录完，不要中途停下来改代码，因为剪辑拼接的痕迹太多会显得很假。如果录错了，我的经验是不要马上停，深呼吸停顿两秒，然后从上一个步骤的关键节点重新开始，后期把停顿的位置剪掉就行。最怕的是录的时候数据库服务没启动，界面白屏，自己还不知道，等录完才发现视频废了，所以录之前先完整过一遍流程。

5. 从踩坑到填坑：个人云盘开发中的问题排查实录

5.1 上传大文件连接中断或卡死：问题定位与解决

这个可以说是文件上传开发里遇到最多的坑。我一开始测试上传 200MB 视频时，总是传到一半就卡住不动，控制台报 413 或者直接超时。排查后确认是三个地方没配置对。

第一个是 multer 的 limits.fileSize 限制，默认不限制，但如果你用的 Express 版本比较老，或者中间件顺序不对，可能会被前面的 urlencoded 解析限制影响。第二个是反向代理的超时时间，如果用了 nginx，client_max_body_size 和 proxy_read_timeout 都要调大。第三个是前端 axios 的默认超时时间，默认是 0（不超时），但如果你配置了 timeout，也要调大。

我的处理方式是：后端把 limits.fileSize 设为 100MB，前端对超过 50MB 的文件提示用户使用分片上传通道，这样小文件走普通上传、大文件走分片上传，两个通道各司其职，也方便在论文里分别描述。

5.2 中文文件名乱码与下载文件名错误

文件上传时中文文件名保存到数据库没问题，但下载时如果直接拼在 Content-Disposition 头里，浏览器会显示乱码或者直接拒绝下载。原因是最早的 HTTP 规范里，响应头只支持 ASCII 字符，中文必须做编码处理。

解决办法是下载时用encodeURIComponent(file.file_name)，或者使用 RFC 5987 的 filename* 格式：

res.setHeader('Content-Disposition', `attachment; filename*=UTF-8''${encodeURIComponent(file.file_name)}`);

顺带提一个容易忽略的点：如果你用 multer 的 diskStorage 直接把原始文件名作为存储文件名，遇到中文名加上特殊字符，在某些操作系统和文件系统下也会出问题。所以核心思路还是我前面说的，存储名和展示名分开，这是最省事的方案。

5.3 路径穿越风险：一个低配云盘最容易忽略的漏洞

我在给一个朋友的项目做代码 review 时看到过这种写法：

res.sendFile(path.join(uploadDir, req.query.filename));

前端请求http://localhost:3000/files?filename=../../../../etc/passwd，后端就把系统密码文件读出来了。这就是典型的路径穿越漏洞，在网络安全课程里经常出现，但实际开发中很多人会疏忽。

修复方法，最简单的就是用数据库里的相对路径存储字段，下载时拼接路径后做一次规范化校验：

const realPath = path.resolve(uploadDir, file.file_url); const uploadRoot = path.resolve(uploadDir); if (!realPath.startsWith(uploadRoot)) { return res.status(403).json({ msg: '非法路径' }); }

这个安全点在论文里写出来很加分，建议在系统测试章节专门加一个“安全性测试”小节，列一个非法路径请求的测试用例。

5.4 Node.js 异步带来的“灵异现象”

开发过程中最让我崩溃的一个 bug 是：分片文件合并后，总有一部分数据是坏的，文件打开提示损坏。排查了半天，发现问题出在合并逻辑上——循环里用 fs.createReadStream 去 pipe 到同一个 writeStream，但 pipe 是异步的，如果不等前一个分片读完就开始读下一个分片，数据就会交叉写入，文件自然就坏了。

解决办法就是我在 2.2 节写的那样，用 Promise 包裹每个分片的读取过程，确认前一个分片完全读完再继续下一个。这个坑说明了一个很重要的 Node.js 知识点：流式操作不是同步的，不能图省事写一个简单 for 循环就完事。调试这类问题最直接的方法，就是打印每个分片的读取完成状态，看有没有重叠。如果你在开发中也遇到“文件大小对但内容损坏”的情况，先怀疑这里。

6. 答辩前夜：检查清单与最终建议

6.1 三个让老师眼前一亮的加分功能（有时间再做）

如果你的核心功能都做完了，还有余力，我强烈建议挑着做这几个功能，投入产出比很高。

第一个是回收站恢复。这个做起来非常简单，就是用 status 字段软删除，恢复时把 status 改成 0、清空 delete_time 就行，但功能价值很直观，几乎每个答辩老师都会问“删错了怎么办”。

第二个是文件搜索。前端一个输入框，后端用 LIKE 查询文件表里的 file_name 字段，一节课就能做完，但能明显提升系统的完整度。

第三个是移动文件的拖拽交互。在文件列表里拖住一个文件放到某个文件夹里，前端记录拖拽目标文件夹的 ID，后端更新 parent_id 字段。前端拖拽 API 实现起来有一点门槛，但只要做出来，演示效果非常亮眼。注意，如果时间不够，不要硬做，先把前面两个搞定。

6.2 最后一天还能做什么：演示检查清单

就算代码有问题，只要演示不翻车，答辩就成功了一半。我把自己踩过的演示事故总结成了一份检查清单，答辩前一天照着过一遍：

• 数据库服务是否启动，数据库里是否有演示用的账号和数据
• Node.js 服务能否正常启动，有没有端口被占用
• 上传目录和分片临时目录是否存在且有读写权限
• 前端页面能否通过实际访问地址打开，不要用 file:// 协议打开
• 提前准备几个小体积演示文件，放在桌面显眼位置
• 视频预览功能是否能正常播放，音频是否能听到
• 分享功能是否正常生成链接和提取码
• 回收站里没有残留的过期数据，避免演示时出现“异常状态”
• 页面加载速度是否正常，有没有明显的控制台报错

我见过太多人答辩现场打开浏览器，结果登录接口报 500，原因就是 MySQL 服务根本没有启动。这种低级错误带来的影响是致命的，一定要提前过一遍。

6.3 如果时间可以倒流，我会怎么安排节奏

写完这个项目，如果让我重来一次，我会把时间分配改成“先写文档，再写代码”。当时我一上来就兴奋地写代码，结果做到一半发现需求边界没定清楚，文件夹层级、分享逻辑、回收站规则这些都是在开发中临时补的，导致后期频繁改表和重构代码，白白浪费了大量时间。

正确做法是，拿到题目先用两三天把需求分析、功能列表、数据库表结构、页面草图全部定下来，哪怕不用正式文档，也要在纸上把流程走一遍。然后按“最小闭环 → 核心功能 → 亮点功能 → 美化界面”的顺序推进。这样做的好处是你对项目的整体把握非常清晰，写论文时框架也早就有了，只需要把开发过程中的截图和细节填进去，效率会翻倍。

最后再分享一个小技巧：你在论文里写“系统测试”这一章时，不需要真的写很复杂的自动化测试，一个功能测试用例表就够了。比如“输入正确的用户名密码，点击登录，系统跳转到文件列表页，测试结果：通过”，列十几条这种用例，表格一做，这章就稳稳拿下了。关键在于你测的时候要真的每个功能都点一遍，别在测试结果里编数据，因为答辩老师大概率会现场操作一遍验证。保持代码和文档的一致性，最好的论文就是你真的把系统从零到一亲手做出来的过程记录。