企业官网建设流程全解析

这几年带毕业设计，SpringBoot加Vue的博物馆信息管理系统几乎是我见过最多人选的题目之一。光一个方向，我前后看过几十个版本：有的偏重藏品管理，有的着重预约流程，还有的把展厅和志愿者都塞进去。题目年年类似，但做得好的和做得一般的，拿出来的完成度会有天壤之别。这篇文章我想把这套系统从选题逻辑、数据库设计、前后端实现，到怎么转化成毕业论文，再到搭建过程中的高频坑位，整体捋一遍。如果你正在准备这类毕业设计，或者想用这个项目作为全栈入门练手，顺着这条线走下去，能少走不少弯路。

我先说一个判断：博物馆信息管理系统不是简单的“增删改查”堆砌，它是一个非常适合用来展示工程能力的综合型业务系统。无论从业务复杂度、表结构设计、权限控制、预约逻辑，还是从Vue端界面呈现的角度，它都能装下足够的干货。对毕业生来说，它既不会难到无法落地，也不会简单到答辩时无话可说。

1. 这个选题为什么年年火——毕业设计题型的真实分析

1.1 “信息系统类毕业设计”的底层逻辑

先把这个题目的本质拆开。任何信息管理系统，无论前面挂的是“博物馆”“图书馆”“健身房”还是“宠物店”，它的底层骨架都差不太多：用户管理、内容管理、预约或订单处理、统计展示。选这类题目的学生，本质上是在用一套全栈技术栈，解决一个中等复杂度的业务数据管理问题。

为什么博物馆场景特别受欢迎？原因是它兼顾了两头。一端是普通用户，也就是参观者，他们要浏览展览、查看藏品、在线预约；另一端是后台管理员，要维护藏品档案、发布展览信息、审核预约、管理展厅数据。这种“两端都有事干”的设计，让前端页面显得丰富，后端接口也不至于只是几个空壳子。

我在跟学生聊选题时经常说一句话：毕业设计最怕的不是功能多，而是功能少到没法支撑论文的章节结构。博物馆管理系统天然有至少五个功能域——藏品信息管理、展厅与展览管理、参观预约管理、用户与权限管理、公告与数据统计。这五个域一个个写进论文里，需求分析、系统设计、功能实现、系统测试四章就都有实打实的内容可以写。

1.2 相比其他信息系统，博物馆场景的特殊优势

有学生问我：那跟“图书管理系统”“二手交易平台”比，选博物馆有什么差别？

差别在业务语义。图书管理基本就是图书增删改查加借还流程，业务逻辑相对线性；二手交易平台虽然业务丰富，但涉及到支付、订单状态扭转、买家卖家纠纷处理，对毕业设计来说容易“收不住”。博物馆系统的业务量级恰好卡在中间：藏品有朝代、材质、年代、分类、状态这些有专业感的属性；展览有策划周期和关联关系；预约有一整套状态流转。它比纯CRUD多了一层“业务味道”，但又不会像电商平台那样复杂到让你陷进分布式事务的泥潭。

更要紧的是，博物馆系统在答辩时非常“好讲”。评委老师不用懂技术也能理解场景。你说“参观者在线预约参观，管理员后台审核”，一句话就能讲清系统价值。反过来，如果你做一个算法类的题目，可能光解释问题定义就得花五分钟。信息管理系统的优势就在这里：业务模型是透明的，技术实现的讨论门槛自然就低了。

1.3 动工之前，先确认自己的基线技能

选这个题目之前，我建议你先做一次诚实的现状评估。需要具备的硬指标有这么几项：Java基础语法和面向对象思想不能生疏，至少能看懂@Service、@Controller这些注解的含义；会写最简单的SQL，知道主键、外键、索引大概是怎么回事；前端方面，能看懂Vue单文件组件的基本结构，知道data、methods、mounted是干什么用的。

如果这些条件离你还有点远，那第一步不是急着敲代码，而是先花两周把基础补齐。我见过一些学生，Java还停留在“照着抄能跑”的阶段就直接开项目，结果被Maven依赖、MyBatis映射、前端跨域三连击劝退，最后只能花钱请人代做，这对于毕业设计来说就失去意义了。

反过来，如果你已经具备这些基础，那博物馆管理系统是一个很好的放大器——你可以在一个可控的复杂度内，把后端分层、接口设计、前端组件化、权限控制整套工程实践都过一遍，做完之后简历上也能多一个拿得出手的项目。

2. 数据模型先行：博物馆信息系统的功能边界与表单设计

2.1 从需求分析到功能清单：哪些模块该保留，哪些没必要做

很多学生拿到题目第一反应是打开IDE新建项目开始写代码。这是顺序错了。做信息系统，第一步永远是画功能清单。我习惯让学生先拿一张纸，把系统角色和功能列出来，再决定表结构。

博物馆信息管理系统通常保留两大角色：普通用户（参观者）和管理员。管理员内部还可以再拆：超级管理员负责账号和数据维护，普通管理员负责展览和预约审核。这里的核心功能模块，我建议锁定为五个：

• 藏品管理：藏品的录入、编辑、下架、详情查看，支持按名称、朝代、分类检索。
• 展厅与展览管理：维护展厅基础信息，创建展览并将展品关联到展览。
• 预约管理：参观者提交预约、查看预约状态；管理员后台审核或者自动审核。
• 用户管理：注册、登录、角色分配、账号启停用。
• 系统管理：公告发布、数据统计、操作日志。

至于要不要做展厅VR、语音导览、线上文创商城，我一律建议慎重。这些功能听起来好看，但每一个都会显著拉长开发周期。毕业设计的核心是“完整”，不是“酷炫”。做一个逻辑闭环的小系统，远比做一个半成品的“大平台”更有说服力。

2.2 核心表的字段设计与关系约定

功能清单定了之后，表结构就是整个项目的承重墙。我建议至少设计这六张核心表：

用户表（user）：主键、用户名、密码（密文存储）、昵称、联系电话、角色标识、创建时间、状态。角色标识可以用一个字段区分，也可以引入角色表做标准RBAC。小系统里我倾向于直接用字段区分，省事且够用。

藏品表（collection）：主键、藏品编号（业务唯一）、名称、类别、朝代、材质、尺寸、图片地址、藏品状态（在库/展出/修复/下架）、简介、录入人、录入时间。这张表的字段是后面检索功能和列表展示的数据来源，字段命名要规范，别一会儿用create_time一会儿用created_at。

展厅表（hall）：主键、展厅名称、位置、容纳人数上限、开放时间、简介。

展览表（exhibition）：主键、标题、封面图、展览介绍、举办时间起止、关联展厅ID、状态（筹备中/进行中/已结束）。

预约表（reservation）：主键、预约编号、用户ID、展览ID、预约日期、到馆时间、预约人数、联系电话、状态（待确认/已确认/已取消/已完成）、提交时间。这张表是整个系统业务逻辑最密的地方，后面会详细说。

公告表（notice）：主键、标题、内容、发布人、发布时间。这张表用来撑起首页信息和论文里的“信息发布”功能点。

字段层面有几个细节要提醒。第一个是密码必须加密存储，这是安全底线。第二个是含有状态语义的字段，建议用Integer而不是String，方便做状态机的逻辑判断。第三个是大量用于联表查询的字段，比如exhibition_id、user_id，一定要建索引。别小看这种细节，答辩时老师问到数据库设计，你能说出索引和唯一约束的设置理由，印象分会明显不一样。

2.3 角色权限体系如何划分，超级管理员为什么不可或缺

权限设计是信息系统类毕业设计的必考点。最简单好用的做法是：用一张用户表加一个role字段，区分USER和ADMIN两种角色。查询功能通过登录状态控制，管理功能通过角色控制。

超级管理员往往是学生容易漏掉的点。很多人觉得，系统里有管理员账号就够了，为什么还要分超级管理员和普通管理员？实际场景是这样的。普通管理员可以管理藏品和展览，但不应该能删除其他管理员账号，也不应能修改系统参数。系统则需要有一个最高权限账号来兜底。这种“分级授权”的思想写进论文里，是对权限管理的合理展开，也让你后端的权限校验逻辑有了层次。

3. SpringBoot后端：接口设计顺序与实现要点

3.1 地基先打好：统一返回体、异常处理和JWT

后端工程搭建的时候，我强烈建议第一件事不是写业务接口，而是把三样基础设施先做好。

第一个是统一返回体。所有接口都返回一个统一包装对象，比如Result ，里面包含code、message、data三个字段。这样前端可以用统一的逻辑处理成功和失败，而不是每个接口各写各的返回格式。

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

第二个是全局异常处理。用@RestControllerAdvice统一捕获业务异常和系统异常。这一写在排错时会救你很多命。否则一旦代码里某个查询报空指针，前端只会看到一个格式乱七八糟的报错，排查起来效率极低。

第三个是登录认证。我推荐用JWT而不是简单的Session。JWT的核心思路是：用户登录成功后，后端签发一个带有效期的token，前端后续请求都在header里带上这个token，后端通过拦截器解析并校验。这个方案的好处是无状态、易于前后端分离部署，而且“Token认证机制”本身也是论文里一个很漂亮的章节素材。

jwt: secret: your-secret-key expire: 86400 # 24小时

3.2 藏品管理接口：CRUD中容易被忽视的细节

藏品管理模块对应的是一组标准CRUD接口。但这里有两个细节值得展开。

第一个是分页条件查询。接口需要支持同时按照名称模糊查询、按朝代筛选、按分类筛选，并返回分页数据。使用MyBatis-Plus时，可以这样组织查询条件：

@Override public PageResult<Collection> pageCollections(CollectionQuery query) { LambdaQueryWrapper<Collection> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.hasText(query.getName()), Collection::getName, query.getName()); wrapper.eq(StringUtils.hasText(query.getDynasty()), Collection::getDynasty, query.getDynasty()); wrapper.eq(query.getCategory() != null, Collection::getCategory, query.getCategory()); wrapper.orderByDesc(Collection::getCreateTime); Page<Collection> page = new Page<>(query.getPageNum(), query.getPageSize()); Page<Collection> result = collectionMapper.selectPage(page, wrapper); return new PageResult<>(result.getRecords(), result.getTotal()); }

这里有个经验：查询条件对象和实体类分开定义，不要直接用实体类接收前端参数。原因很简单，实体类字段会被MyBatis-Plus用于自动填充和逻辑删除，混用容易出问题，而且在论文里你可以把“DTO与实体分离”作为接口设计的一项规范写出来。

第二个是图片处理。藏品图片的上传，建议上传到服务器本地目录，数据库里只存访问路径。这个方案对毕业设计来说够用，也不需要额外花钱开通云存储。但要注意配置虚拟路径映射，否则图片文件写到了本地磁盘，前端却访问不到。

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + uploadPath + "/"); } }

3.3 预约模块：整个系统最容易出错的地方

预约管理是博物馆系统区别于普通CRUD系统的核心点，也是答辩时老师最喜欢深挖的地方。预约这里有三层逻辑。

第一层是预约创建的合法性校验。用户提交预约时，后端不能只往表里插一条记录，要先校验：预约的展览是否存在并处于“进行中”状态；预约日期是否在展览举办时间范围内；当前预约人数是否超过展厅人数上限。这些校验逻辑全部通过，才允许落库。

第二层是预约人数的控制。这里有两种做法：简单做法是预约时只校验单次预约人数不超过上限；完整做法是统计该日期的累计预约人次与上限比较。做完整版的难度并不高，一条SQL聚合查询就搞定，但避免超限的效果和论文里的说辞会漂亮很多。

SELECT COALESCE(SUM(visit_count), 0) FROM reservation WHERE exhibition_id = #{exhibitionId} AND visit_date = #{visitDate} AND status = 'CONFIRMED'

第三层是状态流转。预约状态我建议设置为：PENDING待确认、CONFIRMED已确认、CANCELLED已取消、COMPLETED已完成。最简单的流转是用户在待确认状态下可以取消；管理员可以将待确认转为已确认；系统在预约日期过后，可以定时或手动将已确认变更为已完成。这个状态机写清楚后，后端代码结构会清晰很多，论文里也能画一张状态流转图。

3.4 接口设计顺序建议

后端接口不要零散地乱写，我建议按依赖顺序推进：先写登录注册，因为没有token就无法调试其他接口；再写用户管理和公告，这些表结构简单，能帮你把统一返回体和异常处理的代码跑通；接着写藏品和展厅，吃透分页条件和实体类分离；最后写预约模块，因为它要依赖展览和展厅的数据，属于业务集成层。

每写完一个模块，就用Postman或Apifox把接口跑一遍再往前推进。不要等全部写完了再统调，那时代码里积累的错误会让你调试到崩溃。

4. Vue前端：管理端与参观端的页面结构拆解

4.1 后台管理界面怎么组织导航与表格

前端部分我建议使用Vue3加Element Plus，这也是目前最主流的中后台前端组合。管理端页面结构通常是标准的左侧菜单加右侧内容区：

左侧菜单按照后端模块一一对应：首页仪表盘、藏品管理、展厅管理、展览管理、预约审核、用户管理、公告管理。右侧内容区用Router来控制页面切换，每个模块配一个独立的视图组件。注意，菜单别做得太花哨，Element Plus的el-menu组件能满足需求，而且这套结构在论文里的“前端架构设计”章节非常好写。

列表页的设计有固定的套路：顶部是筛选条件区域（关键词输入框、下拉选择、搜索重置按钮）；中间是表格区域；底部是分页器。这个结构几乎适用于所有管理模块。format一下，用el-table绑定数据，用el-pagination绑定分页参数。

<template> <div class="collection-page"> <el-form :inline="true"> <el-form-item label="藏品名称"> <el-input v-model="query.name" placeholder="请输入" clearable /> </el-form-item> <el-form-item label="朝代"> <el-select v-model="query.dynasty" clearable> <el-option label="唐代" value="唐代" /> <el-option label="宋代" value="宋代" /> </el-select> </el-form-item> <el-form-item> <el-button type="primary" @click="handleSearch">搜索</el-button> </el-form-item> </el-form> <el-table :data="tableData" v-loading="loading"> <!-- 列定义省略 --> </el-table> <el-pagination v-model:current-page="query.pageNum" v-model:page-size="query.pageSize" :total="total" @current-change="fetchData" /> </div> </template>

当你把第一个列表页完整做出来后，后面所有模块的列表页都是复制、改字段、调接口三个动作。这也是为什么我不建议一上来就搞复杂封装，先做一个标准的，让你理解套路。

先做一套最朴素的页面，跑通之后再考虑封装一个BaseTable组件。按照做中学的顺序来，对新手更友好。如果一开始就搞很多抽象组件，很容易因为过度设计把自己绕晕。

4.2 参观端页面：观众视角的动线设计

参观端是面对普通用户的页面，主要包括：首页展示、展览列表、藏品浏览、预约提交、个人中心。

首页我建议简单直接：轮播图展示重点展览，下面放最新公告和推荐展品。不要试图塞太多东西，信息层级越清晰越好。展览列表页展示所有正在进行的展览，点击进入详情页，在详情页预留“立即预约”按钮。

预约流程前端要设计得尽量少出岔子：用户选择预约日期，系统需要在页面显示该日期的剩余可预约情况。这个“剩余量”数据，需要前端调一个接口去后端查询。查询到之后，再让用户选择参观人数，校验不超过剩余限额，最后提交预约。整个流程可以做成一个步骤条组件，引导用户一步步完成操作。

个人中心要展示我提交的预约列表，每条记录显示状态。注意，待确认状态下的预约需要显示“取消预约”按钮，已确认状态的预约可以展示二维码或者取票码。哪怕这个取票码只是系统自动生成的一串编号，没有真正的对接闸机，它也能让系统看起来有完整业务闭环。在论文里你可以写“为已确认预约生成唯一预约凭证”，功能描述上完全说得通。

4.3 联调时的关键约定：API路径、数据格式、Token注入

前后端联调是很多学生卡壳的地方，其实大部分问题都出在没有提前约定接口规范。我这里分享一个我惯用的约定体系。

接口路径统一以/api开头，比如/api/user/login、/api/collection/page。前端所有请求走axios实例，baseURL指向这个前缀，开发环境通过Vite的proxy把请求转发到后端地址：

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

这个配置的原理是：开发环境前端跑在5173端口，后端跑在8080端口，两者不同源，浏览器会拦截跨域请求。通过代理，让前端的请求先到达自己的5173端口，再由Vite去请求后端，从而绕过浏览器同源策略限制。

axios请求拦截器统一注入token，响应拦截器统一处理code不等于200的情况：

service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = `Bearer ${token}` } return config }) service.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message) return Promise.reject(new Error(res.message)) } return res }, error => { ElMessage.error('网络请求异常') return Promise.reject(error) } )

这套约定跑通之后，联调基本不会出现“前端拿不到数据”“后端说前端没传参”这类互相甩锅的局面。

5. 毕业论文：如何把系统实现写成有逻辑的论文

5.1 论文结构如何映射到系统模块

很多学生做完系统之后开始写论文，发现写不出来，或者写出来像“系统说明书”，原因是没有建立“论文结构”和“系统结构”的对应关系。我建议按这个框架来走：

绪论这一章内容包括：研究的背景和意义（博物馆数字化管理的需求）、国内外研究现状（这里要写文献梳理，不能只罗列网址）、主要工作与论文组织结构。

相关技术介绍这一章：把SpringBoot、Vue、MyBatis-Plus、JWT、Element Plus各用一个小节来介绍。注意，不要写成百科词条，要写“为什么在本次系统中选用这项技术”，比如“选用MyBatis-Plus是为了借助其内置分页插件简化数据访问层的开发”之类。

需求分析这一章：从系统角色出发，画用例图，写各角色的功能需求。非功能需求也要写，比如安全性（密码加密、Token鉴权）、性能（分页查询控制数据量）、易用性（前端操作流程清晰）。

系统设计这一章：总体架构图、功能模块设计、数据库设计（ER图和表结构说明表）、接口设计（列出主要接口的路径、请求方式、参数、返回值）。

系统实现这一章：分模块描述每个功能的实现，配合核心代码片段和页面截图。

系统测试这一章：测试环境说明、功能测试用例表、测试结果分析。

结论与展望这一章：总结完成的工作，指出不足和未来改进方向。

5.2 摘要、需求分析、系统设计这三章的写作技巧

摘要别看它放在最前面，通常是最后写的。摘要是全文的微缩版，核心逻辑是四句话：系统解决什么问题；系统采用什么技术；系统实现了哪些功能模块；经过测试达到什么效果。第一次不会写，可以先写一个粗糙版本放那儿，等正文全部完成之后回头精炼。

需求分析这一章的得分点在于用例图和数据流描述。用例如能用UML工具画出来最好，画不出来的话，画一个功能结构图也比纯文字强。功能需求描述要写成“用户能够做什么”，而不要写“系统提供了什么按钮”，前者是需求语言，后者是说明书语言。

系统设计这一章注意两点。一是数据库设计不能只贴建表SQL，要给字段说明表，列名、类型、允许为空、说明，一列列列清楚。二是接口设计建议给出一个接口清单表格，把每个模块的接口统一列出，包括请求类型和功能简述。这份表格不需要太细节，但能直接证明你的系统设计是有规划的。

图是论文中非常能提升观感的部分。架构图、ER图、功能结构图、预约流程图，建议多用图说话。画图工具不必纠结，能用清楚的就行。

5.3 测试章节避免流水账

测试章节是学生最容易写砸的地方。很多人写“打开系统，输入用户名密码，点击登录，成功进入首页”，这种写法既无技术含量，也无法体现测试的严谨性。

测试应当以用例为单位，每个用例包含：用例编号、测试名称、前置条件、操作步骤、预期结果、实际结果、是否通过。比如预约功能可以设计这样的用例：前置条件是后台已存在一个正在进行的展览，当前预约人数未满上限；操作是用户选择展览、日期、填写人数后提交；预期结果是预约成功并生成待确认状态的预约记录。这个用例可以验证并发的逻辑。测试结论不要只写“全部通过”，写上缺陷修复的过程更能体现工作量。

5.4 截图素材的收集心得

写论文时你会需要大量系统截图。建议在开发完成之后，按照论文的章节顺序，统一把所有功能页面截图一遍，归档到文件夹里。我见过一些学生，代码写完了，结果页面上的测试数据乱糟糟，截图也临时补，效果惨不忍睹。提前准备一套排版整洁、数据合理的截图数据，会让整个论文质量上一个台阶。我在搭建演示环境时，通常会在数据库脚本里预置一批样例数据，包括几个朝代分明的藏品、两个状态不同的展览，以及一条待审核的预约。演示和截图都能直接展示出系统的多状态效果。

6. 搭建过程中的高频坑位与排查思路

6.1 前端代理跨域时报错怎么查

搭建时最常见的现象：前端页面能打开，但请求接口就报错。报错信息通常是CORS相关，或者404。

排查路径是分层的。第一步，先用浏览器直接访问后端接口地址，比如直接打开http://localhost:8080/api/collection/page，看能不能返回数据。如果后端本身报错，那是代码问题；如果后端正常而前端代理失败，那就是代理配置问题。第二步，检查前端proxy的target端口是不是后端实际端口。第三步，检查请求路径是否被正确拼接，比如代理配置的是/api前缀，请求写成了http://localhost:8080/api，那就会被拼成http://localhost:8080/api/api，自然404。

记住一个原则：前端请求不要写完整后端地址，写相对路径，由代理或部署后的网关来转发。

6.2 登录认证的死循环：token过期与拦截器放行

JWT相关的常见坑是：登录接口请求抵达后端时，JWT拦截器先拦截了它，发现没有token，返回“未登录”错误，前端跳转登录页，但这就是登录页，形成死循环。

解决方案是在拦截器配置里放行登录接口、注册接口和静态资源。同时在前后端约定好：凡是接口返回401状态码，一律做清空token并跳转登录页处理。这里我还要提示一个小细节，响应拦截器里要先优先处理401，再处理code逻辑，顺序放反了也会出问题。

6.3 MyBatis-Plus时间字段、逻辑删除和事务的隐藏坑

如果你用了MyBatis-Plus，有几个细节容易踩坑。

第一个是时间字段的自动填充。创建时间、更新时间如果每次插入、更新都手动set，会非常痛苦。用@TableField(fill = FieldFill.INSERT)配合MetaObjectHandler实现自动填充，代码会清爽很多。

第二个是逻辑删除。配置了@TableLogic之后，查询语句会自动拼接deleted=0条件，这是好事。但如果你在同一张表里用了唯一约束，逻辑删除的用户再注册同一个用户名会报唯一键冲突，因为逻辑删除并没有物理删除记录。解决办法通常是把唯一键改成包含deleted字段的联合唯一索引，或者注册时先查询包含已删除的记录。这个坑很少有人提前意识到，但一旦踩到，排查时间会很久。

第三个是事务。预约创建时要查询、校验、插入三步，如果其中一步失败，之前的操作也应该回滚。在方法上加上@Transactional注解，能在异常时自动回滚数据库操作。这个注解的使用在论文测试章节也可以作为事务一致性验证的一个点来写。

6.4 演示环境的数据初始化

临近答辩时，你需要一个可以直接演示的环境。建议准备一个演示数据库脚本，里面包含可用的管理员账号、测试用户账号、若干条规格完整的藏品数据、进行中和已结束的展览各一个。开启服务后打开前端，登录、浏览、预约、审核，一路点下来不出错。

还要注意静态资源的路径问题。如果服务器换了操作系统，上传目录的绝对路径会失效，尽量把上传路径做成可配置项，写在配置文件里。部署时只需改配置，不需要改代码。涉及文件上传的演示环节，最好在答辩前用同样路径试一次，不然图片显示不出来的尴尬真会让人挠头。

7. 写在最后的实操体会

如果让我总结这套系统的搭建心得，排第一位的是顺序。先数据库，再后端，再前端，最后论文，这个顺序不是随便定的，每一步都是在为下一步铺路。数据库设计得不清楚，后端代码就混乱；后端接口不定好，前端联调就返工；系统功能不稳定，论文截图就得一直重截。

排第二位的是留痕。开发过程中每一步遇到的问题和解决方式，建议记录下来。毕业设计的论文里，测试章节和总结章节非常需要这些素材。平时记录的三言两语，写论文时可能就是一段宝贵的内容。

排第三位的是控制欲望。别觉得功能越多越好。把核心模块做扎实，把异常情况处理好，比挂一堆用不到的边缘功能强得多。答辩时老师最看重的是你对系统的理解——为什么这么设计、遇到问题怎么排查、系统有哪些可优化之处。这些理解，只有自己一行行敲出来，才能真正说得明白。

最后分享一个小技巧：在预置样例数据时，把藏品的朝代、材质、来源、尺寸这些字段都填满、填细致。一来页面表格显得专业，二来论文截图时不用手忙脚乱去补数据。细节上多花十分钟现场演示，观感完全不同。祝每一个准备做这套系统的同学都能顺利走完全程。