基于Vue.js和Node.js的线上美术馆网站平台设计与实现

带过的学生里，十个有八个选毕设题目时，第一反应都是“XX管理系统”——图书馆管理系统、学生选课管理系统、会议室预约管理系统。不能说不行，但这类题目有个共同问题：功能模型太成熟，创新点难挖，答辩时老师一眼就能看到头。今天想聊的这个选题——“基于Vue.js和Node.js线上美术馆网站平台”，属于那种表面看起来不复杂、实际上容量非常大的方向。它既不是纯展示站，也不是传统业务系统，而是把内容展示、用户互动、后台管理、甚至虚拟体验串在一起的综合型项目，能承载的工作量弹性很大。无论你是准备做毕业设计，还是想自己练手做一个完整的前后端分离项目，这个案例都值得拆开看一遍。

这个项目的主要技术栈是Vue.js（前端框架）+ Node.js（后端运行环境），数据库通常搭配MongoDB或MySQL，核心场景是搭建一个可以线上看展的美术馆平台——用户可以浏览作品、查看展览、收藏评论；管理员可以上传作品、维护展览信息。整套系统包含用户端、管理端和接口层，是标准的前后端分离架构。下面我会按一套完整的竣工项目复盘来写：选题怎么考虑、技术栈为什么这么配、数据库和接口怎么设计、环境搭建有哪些坑、核心功能怎么落地、最后演示答辩怎么准备，尽量把能想到的细节都写清楚。

1. 选题价值拆解：为什么“线上美术馆”这个题目容易做出亮点

1.1 从“管理系统”到“线上美术馆”：选题差异背后的分数差异

很多同学担心“美术馆”这个题目会不会太偏、找不到参考。实际上它的定位很妙：它不是纯技术型难题，也不是纯页面展示型项目，而是介于内容网站和业务系统之间的综合体。管理系统类题目强调“增删改查”，但线上美术馆的核心是“内容呈现 + 用户体验 + 互动行为”，这三件事叠加在一起，直接决定了系统要有更丰富的层次。

我见过很多选题翻车的例子：选电商系统的结果在做订单流程上深陷，库存、优惠券、对账越做越复杂，最后闭环都讲不清；选博客系统的又太单薄，用户、文章、评论三张表写完就没了，答辩时内容量撑不够。美术馆平台的优点在于，它的内容域（作品、展览）天然带展示属性，界面做漂亮了直接是加分项；同时它又能自然延伸到用户系统、权限控制、文件上传、状态管理等传统后端技术点，技术覆盖面一点都不少。

从评分视角看，毕设一般看四个维度：选题新颖度、技术复杂度、功能完整度、项目完成度。美术馆这个方向在“新颖度”上明显优于管理系统，因为业务域本身就带有文化和体验色彩；在“技术复杂度”上，前后端分离、文件存储、搜索筛选、虚拟展厅等模块都能加分；在“功能完整度”上，围绕“策展—看展—互动”的业务闭环连得很自然，比硬凑出来的模块要合理得多。

1.2 工作量可控且可增可减，适合不同的基础

另一个现实问题是工作量。毕设时间通常三五个月，其中还要上课、实习、找工作，真正能写代码的时间其实不多。美术馆平台最具价值的一点是，它的功能边界是可以“伸缩”的：

• 基础版：用户注册登录 + 作品分类展示 + 作品详情页 + 管理员作品管理。这个体量适合时间紧、基础弱的同学，两张表、十来个接口、五六个页面就能跑通闭环。
• 标准版：增加展览模块（线上主题展）、收藏与评论功能、后台用户管理。这是大多数同学应该瞄准的目标，工作量适中，功能完整度够，答辩不会被挑出明显短板。
• 进阶版：增加虚拟展厅（Three.js或CSS 3D场景）、在线购票/预约、作品搜索引擎、数据统计仪表盘。这个体量适合冲优秀毕设，或者有前端兴趣想多写点东西的同学。

这种“弹性”其实就是选题的核心优势——同一个题目，可以根据自己进度随时决定做深做浅，不会出现做到一半发现范围失控、或者早早做完无事可做的情况。

2. 技术选型的真实逻辑：Vue.js + Node.js组合为什么稳妥

2.1 前后端分离是主流，也是答辩时最好讲的架构

这套项目采用的前后端分离架构，前端用Vue.js框架，后端基于Node.js运行环境，典型实现是Express或Koa框架提供接口服务。前后端分离在现在的中小型Web项目里几乎是默认选项，前端专注页面渲染和交互，后端专注数据接口和业务逻辑，两者通过HTTP请求中的JSON数据对接。这种模式的好处是，职责边界清晰，前端的页面开发不会阻塞后端的接口开发，反过来也一样，项目演示和后续扩展也方便。

对毕业设计来说，前后端分离还有一个隐性好处：答辩解说时逻辑非常清楚。你可以在演示时说“我从前端这个页面点了一个按钮，它调用了后端的哪个接口，数据库里发生了什么变化，然后数据返回页面刷新”——这个闭环讲下来，老师的思路会完全被带着走。而传统的JSP、PHP混合开发模式，代码在服务器端混在一起，讲解起来反而容易混乱。

2.2 对比其他组合：优势与代价在哪里

选技术栈不能只看流行度，要看它是否匹配自己的基础和学习成本。简单的横向对比：

为什么我在这个案例里推荐Vue.js + Node.js而不是Spring Boot？主要是因为前后端语言统一。前端Vue用的是JavaScript，后端Node.js跑的还是JavaScript，学生只需要熟练掌握一套语法就能兼顾两端，大脑不用来回切换。学习成本集中在框架本身，而不是语言语法上。相反，如果选Java后端，前端学Vue，后端写Spring，两套语言、两套生态、两套规范，很多基础弱的同学很容易顾此失彼。

当然，Node.js后端也有它需要补的课，比如进程模型、异步IO、错误处理，这些在生产环境里非常重要。但因为毕设项目规模不大，Express框架把这些底层逻辑都封装好了，你只需要按“路由—中间件—数据库操作”的模式写接口即可，比较容易上手。

2.3 版本选择：LTS优先，别在版本上给自己挖坑

Node.js版本这块我见过太多同学栽跟头。打开官网看到下载页面有“推荐给绝大多数用户”的LTS版本和“当前最新特性”的Current版本，很多同学习惯性点最新的，结果装完之后某些依赖编译不过去，报错日志翻半天也不知道原因。

这里面有一个常识容易被忽略：Node.js生态里很多工具链（比如一些老版本的node-sass、某个依赖的原生模块）对新版本的适配是有滞后性的。即使你用的是Vite、Express这类对新版本友好的工具，也完全没有必要为了“新”去踩坑。正确做法是：统一使用LTS版本，并且多人协作时锁死版本号。比如项目里写清楚Node.js 20.x LTS，所有成员都装这个版本，避免“我本地能跑，你那边报错”的尴尬。

另外，现在前端工程化普遍推荐用Vite来创建和管理Vue项目，而不是老的Vue CLI。Vite基于原生ESM，开发时启动快、热更新快，社区也已经是主流。这个选择本身不需要纠结太久，跟着官方文档走就好。

3. 功能模块划分与数据库设计：先想清楚再动手写代码

3.1 功能模块地图：用户端、管理端、可选增强功能

先说结论，一个结构清晰、工作量饱满的美术馆平台，建议拆成用户端和管理端两条线来设计：

用户端：

• 首页：轮播图、精选作品、近期展览预告
• 作品列表页：按分类筛选（油画、国画、书法、雕塑、摄影等）、按年代或热度排序、分页加载
• 作品详情页：作品大图、作者信息、创作年代、尺寸、艺术介绍、用户评论列表
• 展览模块：线上主题展的封面列表、展览详情页（策展语、参展作品集合）
• 用户中心：注册、登录、修改个人信息、我的收藏、我的评论记录

管理端：

• 仪表盘：作品总数、评论总数、用户总数等统计
• 作品管理：上传新作品、编辑作品信息、下架作品、图片上传与预览
• 展览管理：创建展览、选择参展作品、设置展览起止时间
• 用户管理：查看注册用户列表、禁用/启用账号
• 评论管理：查看评论、删除违规评论

可选增强功能（按进度决定是否加）：

• 虚拟展厅：通过前端技术模拟一个可切换视角的线上展厅空间
• 作品收藏热度排行：按收藏量或浏览量生成热门榜单
• 搜索功能：按作品名、作者名模糊搜索

这个模块拆分的思路是：每个功能都能对应一个明确定义的“用户故事”。例如“作为游客，我想在首页看到展览预告，这样我不用专门进板块查找”，而不是为了堆功能而堆。答辩时老师问“为什么设计这个功能”，你能说清楚它的使用场景和业务价值，这已经超过大部分只做机械增删改查的项目了。

3.2 数据库集合设计与关联关系

数据库端，如果后端用Node.js，最顺手的搭配是MongoDB。它是文档型数据库，存储结构天然和JSON接口对应，省去了很多ORM映射的麻烦；作品、展览这类内容型数据字段不是完全规整的（有的有尺寸、有的有材质、有的有馆藏编号），用文档模型存起来非常灵活。如果你学校课程只教过MySQL，用MySQL也完全没问题，只需要把下面的表结构概念转换成关系表即可。这里按MongoDB的“集合”来说：

需要注意两个设计细节。第一，密码字段不能明文存储，必须用加密算法处理后再入库，Node.js生态常用的方案是bcryptjs。第二，关联关系上，MongoDB里一般用ObjectId引用而不是物理外键，比如评论里的artworkId就存的是作品的_id。这种设计在项目里操作起来非常直接——查询某个作品的评论时，只需按artworkId过滤comments集合即可。

3.3 接口设计草案：RESTful风格怎么落地

接口层按RESTful风格设计，资源用名词复数表示，操作通过HTTP方法区分的思路来规划。一个完整的接口列表大概长这样：

鉴权放在“需要登录”或“需要管理员权限”的接口上，通常做法是登录成功后签发一个JWT（JSON Web Token），前端后续请求在请求头里带上Authorization: Bearer <token>，后端通过中间件校验token并解析出用户身份。这个流程是整条权限链路的核心，也是答辩时很可能被追问的技术点，建议每个接口都实际试过，能讲清楚token从签发到校验的完整过程。

4. 环境搭建最容易拖垮进度的几个坑

4.1 Node.js版本管理：nvm怎么用，v24.20.0这类报错怎么破

先说一个很多新手不知道的概念：Node.js官方有两种版本线，偶数版本号（如18、20、22）多为LTS长期支持版，奇数版本号（如19、21、23）是Current版，不稳定周期短。项目开发务必参考LTS版本，不要在版本号上追求最新。如果你是一个刚开始做毕设的同学，团队环境还比较乱（有人的电脑装过旧版Node、有人卸载过但注册表残留），强烈建议用nvm来管理Node版本。

nvm的全称是Node Version Manager，简单说就是Node的“版本管家”，可以在电脑上装多个Node版本，随时切换。安装完nvm后的常用命令是nvm list available查看可用版本，nvm install 20安装指定版本，nvm use 20切换版本，node -v验证是否切换成功。

热搜词里有一句报错信息非常典型——error installing 24.20.0: node.js v24.20.0 is not yet released or is not available。这个报错发生在执行nvm install 24.20.0之类的命令时。原因通常是两种：一种是你把版本号拼写错了，官方发布列表里根本没有这个版本，比如24系列的正式发布可能才到24.5.0，你却写了24.20.0，nvm去官方源里查不到自然报错；另一种是nvm自带的版本索引没有同步更新，需要执行nvm update或刷新远程源。遇到这类问题不要慌，先用nvm list available看真实存在的版本，再选择一个稳定版本安装即可。这类环境问题不是你的代码问题，但不处理会卡住所有后续工作，很影响心态。

4.2 npm镜像与依赖安装：慢与失败怎么解决

安装完Node.js，自带包管理器npm。如果你直接原样使用官方源安装依赖，大概率会体验到什么叫“等待半小时，失败一瞬间”。比较靠谱的做法是提前把npm源切换成国内镜像。执行npm config set registry https://registry.npmmirror.com，然后执行npm config get registry验证配置是否生效。配置完成后，新开一个小项目实测一下安装速度，通常能快上好几倍。

还有一个容易踩的细节：如果你的项目中有个别依赖包是某个公司内部私有包或需要登录的包，镜像站里是没有的，这时候npm install会提示404。你只需要在项目根目录新建.npmrc文件，把公共依赖和特殊局部分开配置，或者直接用官方源拉取，拉完再切回镜像源。这个小技巧在很多实际项目里都会遇到，提前有个印象能省不少功夫。

另外，npm安装过程中出现node-gyp编译错误在中老年依赖里非常常见，通常是因为某些包需要本地编译原生模块，而电脑上没有安装Python或C++编译工具链。解决方案是按官方要求安装Windows Build Tools，或者尽量避免使用老版本依赖，选择这些原生模块已经预编译了二进制文件的替代包。毕业设计不是造轮子，能用新工具就不碰旧轮子，所有依赖尽量安装最新稳定版本。

4.3 前端工程化初始化：Vite、Vue Router、DevTools版本对应

前端项目初始化，现在推荐直接用npm create vue@latest命令。这个命令会引导你选择是否需要TypeScript、Vue Router、Pinia、ESLint等选项。对绝大多数毕设来说，建议选上Vue Router（页面路由必备），状态管理看个人情况（项目不复杂的话可以不加Pinia），TypeScript如果学校没教过、自己也不熟可以暂时不选，避免一路写下去全是类型报错，心态崩了。这里不要盲目追求“全程TypeScript更高级”，你的首要目标是在有限时间内做出来，选择自己驾驭得住的技术栈也是工程师的智慧。

Vue Router和页面路由是配套的。创建完项目后，你会在src/router/index.js里看到路由配置，形如：

const routes = [ { path: '/', name: 'home', component: () => import('../views/HomeView.vue') }, { path: '/artworks', name: 'artworks', component: () => import('../views/ArtworkListView.vue') }, { path: '/artworks/:id', name: 'artwork-detail', component: () => import('../views/ArtworkDetailView.vue') } ]

这里的动态路由/artworks/:id很关键，作品详情页就是通过这个id参数去后端请求具体数据的。组件里通过useRoute()拿到路由参数，再调用接口。

还有一个小细节，热搜词里频繁出现“vue.js devtools版本6下载”。Vue官方浏览器扩展Vue.js devtools是调试Vue项目的利器，但它有个版本对应问题：Vue 2要用Vue.js devtools 5.x，Vue 3要用6.x版本。如果装的版本和项目Vue版本不匹配，打开F12开发者工具看不到Vue组件树面板。所以装扩展之前确认一下你的项目用的Vue是几，项目里package.json的dependencies.vue字段一眼就能看到。

5. 核心链路实现：从展品上传到线上看展

5.1 项目目录与启动流程

结构清晰的目录能让项目维护和后续写文档都轻松很多。推荐按下面这种方式组织代码：

frontend/ # 前端项目（Vue 3 + Vite） src/ api/ # 接口请求封装 router/ # 路由配置 views/ # 页面组件 components/ # 公共组件 assets/ # 静态资源 App.vue main.js package.json vite.config.js # 含开发代理配置 backend/ # 后端项目（Express） app.js # 应用入口，挂载中间件 routes/ # 路由文件（auth, artworks, exhibitions, comments...） controllers/ # 业务逻辑处理 models/ # Mongoose数据模型 middleware/ # 鉴权中间件、错误处理中间件 uploads/ # 本地上传的图片存储目录 package.json

启动流程分成两步。先启动后端：在backend目录下执行npm run dev，后端监听在3000端口；再启动前端：在frontend目录下执行npm run dev，前端默认跑在5173端口。前后端开发时存在跨域问题，一次搞定它的方式是在Vite配置里加代理，让所有/api开头的请求转发给后端服务：

// vite.config.js export default defineConfig({ server: { proxy: { '/api': { target: 'http://localhost:3000', changeOrigin: true } } } })

这样前端代码里请求接口时直接写/api/artworks，不用写完整域名，浏览器就感知不到跨域了。这个配置解释了“为什么前端代码里的请求地址可以没有localhost”这个问题，写文档的时候别漏掉。

5.2 展品列表与详情的数据流实现

作品列表页是用户端最核心的页面。它的数据流是：前端组件挂载完成后，触发onMounted钩子里的请求函数，调用/api/artworks接口，后端查询数据库作品集合，返回JSON数组，前端用v-for把数组渲染成卡片列表。一个典型的列表接口实现如下：

// backend/routes/artworks.js router.get('/', async (req, res) => { const { category, page = 1, pageSize = 12 } = req.query; const filter = {}; if (category) filter.category = category; const list = await Artwork.find(filter) .sort({ createdAt: -1 }) .skip((page - 1) * Number(pageSize)) .limit(Number(pageSize)); const total = await Artwork.countDocuments(filter); res.json({ list, total }); });

分页用skip + limit实现，返回数据里同时带上总数total，前端根据这个总数计算总页数、渲染页码组件。这里要留意一个容易犯的错：接口里查询参数从req.query取出来时全是字符串，如果不转成数字直接用，limit('12')在Mongoose里偶尔会异常，养成Number(pageSize)的习惯更稳。

作品详情页则是点击列表项后进入动态路由/artworks/:id，组件读取route.params.id，调用/api/artworks/:id接口。后端根据id查作品，再并行查这个作品下的评论列表，组装成一个对象返回给前端：

router.get('/:id', async (req, res) => { const artwork = await Artwork.findById(req.params.id); if (!artwork) return res.status(404).json({ message: '作品不存在' }); const comments = await Comment.find({ artworkId: artwork._id }) .populate('userId', 'nickname avatar') .sort({ createdAt: -1 }); res.json({ artwork, comments }); });

populate作用是拿评论数据时把userId字段替换成对应的用户资料，这样前端渲染评论时直接能拿到用户名和头像。这个字段关联技巧很实用，MongoDB虽然没有关系型数据库的外键物理约束，但通过populate可以实现类似联表查询的效果。

5.3 作品上传与图片处理

管理员上传作品是管理端最核心的功能。前端页面上传文件，用FormData格式发送POST请求到后端；后端用multer这个中间件接收文件，存到本地uploads目录；然后写入数据库作品记录，图片地址存成/uploads/xxx.jpg。

// backend/controllers/artworkController.js const storage = multer.diskStorage({ destination: (req, file, cb) => cb(null, 'uploads/'), filename: (req, file, cb) => { const ext = path.extname(file.originalname); cb(null, Date.now() + ext); } }); const upload = multer({ storage, limits: { fileSize: 5 * 1024 * 1024 } }); router.post('/', authMiddleware, adminMiddleware, upload.single('image'), async (req, res) => { const { title, artist, category, year, description } = req.body; const artwork = await Artwork.create({ title, artist, category, year, description, imageUrl: `/uploads/${req.file.filename}` }); res.status(201).json(artwork); });

这里有几个细节值得注意。文件名的处理做成时间戳 + 扩展名，可以避免中文文件名乱码和重复覆盖的问题。限制文件大小到5MB，防止有人传超大图片把磁盘撑爆。拿到上传文件后，必须通过multer的upload.single('image')中间件解析，字段名要跟前端FormData里的key完全一致，这个对应关系写错是最常见的上传报错原因。

图片文件存本地虽然简单，但有一个隐患：前端Vite开发服务默认只代理/api路径，不代理/uploads目录。所以前端页面渲染<img src="/uploads/xxx.jpg">时同样会跨域/找不到文件。这个坑很多人踩。解法有两个：一是把/uploads也加入Vite的proxy配置，目标指向后端端口；二是前端不用相对路径，写成http://localhost:3000/uploads/xxx.jpg。毕设场景下第一个解法更优雅。

5.4 虚拟展厅：两种可选实现方案

虚拟展厅是美术馆项目在“亮点功能”上最值得投入的模块，也是拉开档次的关键。这里说两种可选方案，按实现成本排序。

方案一是基于图片序列的简易全景。准备展厅的几张不同角度的静态图，前端通过简单的切换交互（点击左右箭头或拖拽）模拟“穿行”效果。优点是实现成本极低，能在几天内做出来，答辩时也可以说“营造了观展体验”；缺点是交互感弱，可讲解的技术点有限。

方案二是用Three.js做一个可旋转、可移动的三维展厅空间。在场景里建一个白盒子空间，墙壁按网格挂上作品贴图，利用OrbitControls实现视角旋转和缩放。这套实现的技术含量明显更高，涉及3D场景搭建、贴图加载、光照设置、控制器交互，光是这些名词往答辩PPT上一放，老师自然会觉得项目有深度。缺点是需要补一些Three.js的基础概念，对于完全没接触过3D的同学来说，学习曲线稍陡。

从毕设投入产出比角度，我的建议是：如果时间紧，做方案一，但要在文档里写清楚“为什么没有采用真正的三维展厅”——可以写成因为作品图片的透视匹配成本高，或因为当前数据规模下2.5D交互已经满足用户预期。如果时间充裕且对前端有热情，做方案二，它既是学习新技术的动力，也是答辩时的主力亮点。无论选哪种，都要保证页面性能可用，图片大了记得用压缩图或懒加载，千万别让展厅页面卡成PPT。

6. 演示、文档与答辩：最后的临门一脚

6.1 演示顺序的设计

很多同学辛苦几个月做出来的系统，演示环节一塌糊涂：上来就乱点页面、找不到功能入口、接口报错半天弹不出来，导致老师印象分直线下降。演示顺序是有一套讲究的，尤其是美术馆这种视觉导向的系统，一定要让老师“看到东西”。

我建议的顺序是：先打开用户端首页，展示首页的视觉设计、精选作品、展览预告，让老师对系统的整体气质有第一印象；然后进入作品列表，演示分类筛选、分页浏览；再点进一个作品详情页，展示作品大图和评论区；接着操作收藏功能，顺便登录、注册流程在这里一起演示；之后切到管理端，登录管理员账号，演示上传新作品、编辑作品、创建展览的操作，重点展示上传的图片在前端立刻可见的闭环效果；最后如果做了虚拟展厅或搜索功能，放在收尾展示，作为“亮点”压轴。

另外，演示前一定要准备干净的测试数据。不要用随手写的“test01”账户和乱码标题，建议提前造好一批像样的作品数据。艺术品字段不一定要真实数据，但“名称/作者/年代/描述”要写完整，例如参考公版艺术作品的元数据格式，这部分数据的用心程度直接影响老师对项目完成度的判断。

6.2 答辩高频问题与应答方向

答辩环节老师最爱问的问题集中在几个方向：技术选型理由、关键流程实现、安全性措施、数据来源合法性、并发与性能、项目改进方向。这里挑几个高频问题给出应答建议：

“为什么前端用Vue而不是React？”——回答重点可以放在项目规模和团队熟悉度上，不要贬低React。说Vue上手快、官方中文文档完善、渐进式框架适合中小型项目，同时提到本项目用到了Vue Router和组合式API，最后补一句“如果后续需要更灵活的组织形式，React也会是很好的选择”，既全面又谦虚。

“图片存在服务器本地，如果用户量大了怎么办？”——这类性能问题不指望你真的解决大规模分布式存储问题，而是考察你是否有架构意识。可以承认本地存储适合小规模场景，然后指出演进方向：对象存储、CDN加速、图片压缩和懒加载。把演进路线说清楚，比拍胸脯保证“没问题”要可信得多。

“数据库为什么选MongoDB？”——从数据模型匹配度回答：作品和展览这类文档型数据和JSON天然契合，字段结构灵活；再提到populate处理关联关系方便，开发效率高；最后补一句如果业务强一致要求高，关系型数据库可能更合适，这个选择是基于本项目内容展示为主的业务特点做出的。

“你的项目有什么不足？”——不要回答“没有不足”。诚恳地说出一个真实存在的问题（比如虚拟展厅的性能还需要优化、图片压缩策略比较简单），然后马上接上“如果进一步迭代，我会……”给出解决方案。整个项目观感会好很多，给人一种“这个学生是真实在做项目”的感觉。

6.3 文档写作要点与定制扩展方向

毕设文档通常包括开题报告、需求分析、系统设计、数据库设计、系统实现、测试报告、总结与展望。很多同学把文档当成硬凑字数的大任务，其实它完全可以跟着代码进度走：每做完一个模块，顺手截图、收集接口返回结果、记录遇到的问题和解决办法，等系统完成就有大量素材。

文档里最值得认真写的是数据库设计和接口文档。数据库设计部分把集合/表的字段、类型、关联关系画清楚；接口文档列出每个接口的方法、路径、请求参数、返回示例，可以用表格罗列参数，再配一个真实的JSON返回示例。这部分内容答辩时老师看概率极高，写得清晰直接可以减掉大半答辩压力。

定制扩展方向上，这个项目的延展空间很大：比如加入用户个性化推荐（根据收藏分类推送同类作品）、加入多语言版本做国际艺术传播主题、用ECharts展示馆藏数据分析面板、或者增加移动端适配做响应式页面。这些方向不只是写文档用的“展望”，如果你学有余力，真在系统里实现一个，项目的档次立刻不一样。我自己做项目时的体会是，扩展功能宁精勿多，一个做到80分的亮点功能，比三个做到30分的半成品更能打动评委。

最后再分享一个小技巧：整个项目从新建到完工，一定要养成阶段性提交的好习惯。每完成一个清晰的节点就做一次版本提交，提交信息写清楚“完成了什么、改了哪些文件”。这个习惯带来的最大好处不是代码安全，而是当你在答辩前要写“系统实现”章节时，翻提交历史就能准确回忆起项目演进的时间线，文档写得又快又真实。身边很多同学吃过“做完了代码但想不起来过程细节”的亏，希望这个分享能帮你看得更远一步。