企业官网建设流程全解析

又到了毕业设计选题的季节。我每年都会被问同一个问题：SSM加Vue做什么项目最不容易翻车？答案其实很稳定，民宿网站。这个题目的好处在于业务模型清晰、功能边界明确，用户端和管理端的职责划分天然合理，不会出现那种"题目太大做不完"或者"题目太小没内容写"的尴尬情况。更关键的是，整个项目从零开始写，前后端代码量都很适中，既能让论文有足够的技术深度可写，又不会在答辩前把自己逼到通宵改bug的绝境。

这篇文章我打算把民宿网站这个项目从需求分析、数据库设计、后端核心实现到前端Vue页面，再到论文写作和答辩准备，完完整整捋一遍。不管是打算直接复现这个项目，还是想参考它的思路改成其他方向的毕设，这篇文章都能帮你少踩不少坑。

1. 项目整体定位与技术选型思路

1.1 民宿网站的业务模型究竟在做什么

很多人把民宿网站理解为"简化版携程"，这其实是个误区。民宿网站的核心业务不是简单的酒店预订，而是围绕"非标准化住宿"展开的一套流程。房东发布房源，需要管理房间信息、价格策略、退订规则；房客搜索房源，需要按区域、价格、设施条件筛选，下单预订后还可能产生取消和退款；平台方需要审核房源、处理订单、管理评价。这三方角色的诉求叠加起来，就构成了这个系统的核心业务线。

做毕设的时候最容易犯的错，是照着某个OTA平台的界面去抄功能，把智能推荐、地图找房、在线支付全塞进来。这种做法的结果是功能列表很好看，但论文里的数据库设计和代码逻辑根本撑不起来，答辩时被老师一问就露馅。正确的做法是精确控制业务范围，把核心闭环做好。

我的建议是民宿网站聚焦四件事：房源展示与检索、用户预订流程、订单状态流转、评价与收藏。这四件事已经能覆盖SSM框架的大部分核心技术点，而且每件事都可以在论文里展开写，不会显得内容单薄。

1.2 为什么SSM加Vue是毕设的黄金组合

先回答一个很多人纠结的问题：为什么不用Spring Boot，而要用SSM？不是说Spring Boot不好，而是对于本科毕设来说，SSM框架的"配置驱动"特性反而是优势。Spring Boot的自动配置太"黑盒"了，写论文的时候你很难讲清楚一个请求进来之后，Spring Boot背后替你做了哪些事情。SSM的配置是显式的，从web.xml、Spring配置文件到MyBatis的SQL映射，每一个环节都可以在论文的技术栈章节里写出两三百字的分析。

再来说Vue。Vue在前端技术栈里的地位不用多说，最大的优势是学习曲线平缓，模板语法直观，一个没接触过前端框架的人，一周时间就能上手写页面。而且Vue的响应式机制和组件化开发模式，正好是论文里可以展开讲的"前端设计"内容。用原生JavaScript写页面的话，论文里只能写"通过DOM操作实现动态交互"，这种写法太单薄，答辩老师一眼就能看出来没有认真做。

SSM加Vue的组合，本质上是一个传统后端渲染模式向前后端分离模式过渡的典型案例。后端只提供RESTful接口，前端用Vue做单页应用，两者通过JSON数据交互。这个架构在论文里能讲清楚"前后端分离的优势"，也能在部署时说清楚"静态资源和动态请求的区别"，整个项目的技术含量一下子就上去了。

1.3 项目整体架构设计

整个系统的架构可以分成三层来看：前端Vue应用负责页面渲染和用户交互，后端SSM服务负责业务逻辑和数据处理，MySQL数据库负责数据持久化。前端通过Axios调用后端接口，接口返回JSON数据，前端再绑定到页面上。

这里有一个关键决策很重要：前后端分离的项目，在部署和联调阶段会遇到跨域问题，所以必须在一开始就设计好接口规范。我的做法是所有接口统一使用/api前缀，后端通过CORS配置允许前端开发服务器的跨域请求。这样在开发阶段可以前后端并行推进，前端用Mock数据调试，后端用Postman测试接口，最后联调时只需要改一个配置文件就能对接起来。

这样的架构还有一个好处，就是论文的"系统设计"章节可以画出清晰的架构图。从浏览器端到Vue组件，从Axios请求到Controller层，从Service层到MyBatis映射，每一层都可以配图和文字说明。这就是论文深度的重要来源。

2. 功能模块划分与数据库设计实战

2.1 用户端和管理端的功能边界

民宿网站的功能模块划分，我习惯按照角色来切分，而不是按照"页面"来切分。系统一共三类角色：普通用户（房客）、房东、管理员。为了控制毕设工作量，我建议把房东和管理员合并成同一个后台管理端，房东发布房源、处理订单的功能和管理员审核、统计的功能放在同一个管理界面里，用权限字段区分可访问的菜单即可。

用户端的功能列表我整理成了七项：

• 用户注册与登录，注册时需要填写手机号和邮箱，密码用MD5加盐存储
• 首页展示推荐房源，支持按区域、价格区间、入住人数搜索
• 房源详情页，展示房间图片、设施列表、房主信息、历史评价
• 在线预订，选择入住和离店日期，系统自动计算天数并生成订单
• 个人中心，查看自己的订单列表、收藏列表、待评价订单
• 订单操作，对未入住的订单可以取消，入住完成后可以发表评价
• 收藏功能，收藏感兴趣的房源，方便下次直接查看

管理端的功能整理成五项：

• 房源管理，对用户发布的房源进行审核、上下架操作
• 订单管理，查看所有订单状态，处理用户取消申请
• 用户管理，查看注册用户列表，禁用违规账号
• 分类管理，维护民宿的分类标签，如海景房、公寓、农家乐等
• 数据统计，展示每日订单量、营业额、热门房源Top10

这个功能列表不需要再多，再多就会超出工作量。关键是每个功能都能对应到数据库的一张表或者几张表的关联查询，这样数据库设计的时候心里就有底了。

2.2 数据库表结构设计与关系梳理

数据库设计是整个项目的基石，也是最值得在论文里花篇幅写的内容。民宿网站我设计了七张核心表。先看用户表，字段包括用户ID、用户名、密码、真实姓名、手机号、邮箱、头像地址、角色、注册时间、状态。这里角色字段我用role，取值为1表示普通用户，2表示管理员，这样一张表就能支撑整个系统的登录鉴权。

民宿信息表是业务的核心，字段比较多：民宿ID、民宿名称、所属城市、详细地址、房东ID、封面图片、图片列表、房间类型、面积、可住人数、床型、每晚价格、设施标签、平均评分、描述、审核状态、上下架状态、创建时间。这里的房东ID关联用户表的用户ID，设施标签我用逗号分隔的字符串存储，比如"无线网络,空调,洗衣机"，查询的时候用MySQL的FIND_IN_SET函数做匹配，比单独建一张关联表简单很多。

订单表的设计需要特别注意，订单信息涉及预订的核心流程：订单ID、订单编号、民宿ID、房间ID、用户ID、入住日期、离店日期、入住天数、每晚价格、订单金额、联系手机号、入住人姓名、订单状态、创建时间。订单状态我用数字来表示：1待支付、2已支付待入住、3已入住、4已完成、5已取消。这个状态机是整个系统逻辑最复杂的部分，每一笔订单从创建到完成，状态流转都有明确规则。

评论表记录用户对房源的评价：评论ID、民宿ID、用户ID、订单ID、评分、内容、回复内容、创建时间。收藏表更简单，就是用户ID和民宿ID的组合。最后还有一张公告表，用来发布平台通知。

这几张表之间的关系在论文里要用E-R图画清楚，用户和民宿是一对多关系，民宿和订单是一对多关系，订单和评论是一对一关系，用户和民宿通过收藏表形成多对多关系。数据库设计这一章是论文里最好写的部分，只要你把表结构、字段说明、关系约束写清楚，基本上两三千字就有了。

2.3 核心SQL设计的几个关键点

数据库设计光把表建出来还不够，实际写代码的时候有几个地方特别容易出问题。第一个是民宿列表的分页查询，光模糊搜索就包含三个条件：城市、价格区间、可住人数，再加上上下架状态和审核状态的两个限制，SQL条件稍微一复杂，MyBatis的动态SQL就派上用场了。

我写了一个比较典型的查询逻辑：在selectHouseList这个Mapper方法里，先用<where>标签包裹动态条件，城市用等值匹配，价格区间用BETWEEN，可住人数用>=，状态字段用等值条件。这种写法在论文的MyBatis章节里可以重点展示，动态SQL正是MyBatis框架最有价值的功能之一。

第二个是首页推荐房源的排序逻辑。这个不要搞任何复杂的算法，就直接用订单数量加评分做加权排序，SQL语句里用子查询统计每个民宿的订单总数，再按订单数倒序、评分倒序取前六条。写论文的时候把这个SQL的加权逻辑讲清楚，完全够用。

第三个是订单金额的关联查询。查询订单列表的时候，除了订单表本身的数据，还要关联民宿表拿民宿名称和封面图，关联用户表拿用户名称。这种多表关联查询在论文里要写出具体的JOIN语句，也是"系统实现"章节的素材。

3. 后端SSM核心实现与关键代码拆解

3.1 Maven工程结构与依赖配置

后端项目我习惯用Maven来管理，整体结构分成controller、service、mapper、entity、common五个包。entity包放数据库实体类，mapper包放MyBatis的接口和XML映射文件，service包写业务逻辑，controller包写接口层，common包放统一返回结果类、异常处理类、工具类。

在pom.xml里需要引入的依赖包括：spring-context、spring-webmvc、mybatis、mybatis-spring、mysql-connector-java、druid连接池、jackson-databind、javax.servlet-api、jstl、lombok。这里有一个很多人会踩的坑：注意Spring版本和JDK版本的兼容性，比如Spring 5.3以上版本要求JDK 8以上，如果本机是JDK 11也没问题，但如果还在用JDK 7就要把Spring版本降到4.x，否则启动时会直接报错。

配置文件方面，SSM项目至少需要三个配置文件：web.xml、spring-mvc.xml、mybatis-config.xml。我用druid连接池来管理数据库连接，连接池配置里最关键的两个参数是初始连接数和最大连接数，毕设项目规模不大，初始5个、最大20个就够用了。数据库连接这块要记得在url参数里加上characterEncoding=utf-8，否则插入中文数据会出现乱码，这个问题我在毕设季见过太多次了。

3.2 后端三层架构的调用流程

SSM项目最核心的思想就是分层。我拿"用户提交预订订单"这个场景来走一遍完整流程，大家就理解了。

前端Vue页面把表单数据提交到后端的/api/order/add接口，这个请求首先被SpringMVC的前端控制器DispatcherServlet拦截。DispatcherServlet根据请求URL找到对应的OrderController，OrderController接收到JSON数据后，调用OrderService的createOrder方法。OrderService会先校验用户是否登录、房源是否存在、日期是否冲突，然后生成订单编号，最后调用OrderMapper的insert方法把订单数据写入数据库。数据写完之后，OrderService返回订单ID给Controller，Controller把结果封装成统一的JSON格式返回给前端。

三层架构的好处在于：Controller只负责参数接收和结果返回，Service负责业务逻辑，Mapper只负责数据操作。这个分层在论文里可以画出一张完整的时序图，把每一步的调用关系讲清楚，内容非常有料。

我在OrderService里写了一个抢购场景的模拟，用来解释事务的重要性：如果两个用户同时预订同一个房型的最后一天，数据库层面就可能出现超卖。因为预订操作包含"检查日期是否可用"和"插入订单"两步，这两步必须放在同一个事务里，否则就会出现检查完可用但插入时已被锁定的竞态条件。@Transactional注解在这里就派上用场了，我在方法上加上注解并指定rollbackFor = Exception.class，确保任何异常都会触发事务回滚。

3.3 统一返回结果与异常处理

接口层设计我觉得可以做一个统一返回结果类，这会让前端联调时非常省心。类名我习惯叫Result，包含三个字段：code表示状态码、msg表示提示消息、data表示返回数据。成功时code为200，参数错误时400，未登录时401，服务器异常时500。前端拿到这个结构后，只需要判断code是不是200，再决定怎么处理数据。

异常处理方面，我写了一个@ControllerAdvice的全局异常处理器，拦截所有Controller层抛出的异常。业务异常直接返回对应的错误提示，未知异常打印日志后统一返回"服务器开小差了，请稍后再试"。这样做的直接效果是，前端不管遇到什么错误，拿到的JSON格式都是一致的，前端代码里不需要写很多try-catch去适配各种异常情况。

3.4 登录鉴权方案：拦截器加Token

SSM项目里登录鉴权方案我推荐用拦截器加Token的组合，不要用Session，因为前后端分离场景下Session跨域很麻烦。具体做法是：用户登录成功后，后端生成一个UUID作为Token，存到Redis里并设置过期时间，然后把Token返回给前端。前端每次请求时在请求头里带上Token，后端写一个LoginInterceptor拦截器，在请求进入Controller之前校验Token是否存在且有效。

这里要注意，拦截器要配置放行哪些路径。登录接口、注册接口、房源列表和详情这些公开接口不需要Token，而提交订单、添加评论、查看个人中心这些需要登录的接口必须校验。我配置拦截规则时，用excludePathPatterns把/api/user/login、/api/user/register、/api/house/list、/api/house/detail/**这些路径排除掉，其余接口统一走拦截器。

Redis不是每个同学的电脑上都有环境，如果不想装Redis，也可以用一个简单的内存Map来替代，但这仅限于毕设演示。如果论文里要展示Redis的使用，我还是建议装一个Windows版Redis，配置也很简单，跑起来不占多少资源。

3.5 MyBatis映射文件里的细节

MyBatis的XML映射文件是SSM项目里最需要耐住性子写的东西。好几个小细节需要注意。第一个是resultMap的配置，因为实体类字段和数据库字段基本是驼峰命名和下划线命名的对应关系，比如实体类的houseName对应数据库的house_name。在mybatis-config.xml里开启mapUnderscoreToCamelCase配置项，就能自动完成这种映射，省去大量手写resultMap的时间。

第二个是<foreach>标签的使用，这个在做批量操作时特别方便。比如民宿图片列表存的是逗号分隔的字符串，要把图片数据拆开插入详情表，就可以用<foreach>遍历。但毕设里我建议图片字段直接存在house表里不做拆分，减少不必要的复杂度。

第三个是#{}和${}的区别。这个知识点在面试和论文里都容易考到，#{}是预编译参数占位会被转义，${}是直接拼SQL字符串。做模糊查询时可能有人写LIKE%${keyword}%，这样关键字里有单引号就会SQL注入，正确写法是LIKE CONCAT('%', #{keyword}, '%')`。这个细节写在论文里是加分项。

4. 前端Vue项目搭建与页面实现

4.1 Vue项目初始化和目录规划

前端项目用Vue CLI来搭建，创建项目的时候选择使用Vue Router、Vuex（或者直接用Pinia也行，但Vue2生态下Vuex更稳）、Axios这几个插件。装完之后我会先把目录结构规划一下：views目录放页面组件，components目录放公共组件，api目录放接口请求模块，router目录放路由配置，store目录放状态管理，assets目录放静态资源。

这里要提一个建议：如果之前没有接触过前端工程的读者，不要直接上手Vue3加TypeScript，就老老实实用Vue2加JavaScript，生态最成熟，网上搜问题的答案也最多。Vue3的Composition API和setup语法虽然新，但对毕设来说不是必需项，Vue2的Options API写法更直白，论文里也好描述。

4.2 路由配置与页面结构

路由设计上，我按角色区分了两套页面结构。用户端页面包括：首页路由/、房源列表页/house/list、房源详情页/house/detail/:id、登录页/login、注册页/register、个人中心/user、订单列表页/user/orders。管理端页面单独挂在/admin路由下，包括仪表盘、房源管理、订单管理、用户管理和分类管理。

路由守卫的逻辑是前端鉴权的重要部分。beforeEach全局钩子里，判断当前访问的路径是否需要登录权限。如果需要但用户没有Token，就重定向到登录页。管理端页面还需要再判断用户角色是否为管理员。但要注意，前端路由守卫只是一种体验层面的限制，真正的安全校验必须在后端拦截器里做，前端只是让普通用户看不到管理入口。

4.3 Axios请求封装与接口对接

Axios封装是前端项目里我觉得最有必要写好的模块。我在api/request.js里创建一个Axios实例，统一设置baseURL为后端接口地址，并且配置请求拦截器和响应拦截器。请求拦截器里从localStorage取出Token，放到请求头里；响应拦截器里统一判断返回的code，非200状态就弹出错误提示，401状态就跳转到登录页。

接口模块按业务拆分：api/user.js放登录注册相关接口，api/house.js放房源列表和详情接口，api/order.js放下单和订单查询接口，api/comment.js放评论相关接口。每个模块导出的就是一个函数，函数内部调用封装好的Axios实例。这样页面组件里只需要引入对应模块的函数，不用关心请求细节，前后端联调时只需要统一修改baseURL就能搞定。

4.4 首页和房源列表页的关键实现

首页是整个项目对外展示的门面。我设计的首页包含四个部分：顶部导航栏、轮播图、搜索栏、推荐房源卡片列表。轮播图我用Element UI的el-carousel组件实现，图片数据从后端轮播图接口获取。推荐房源区域在mounted钩子函数里调用getRecommendHouseList接口，拿到数据后通过v-for渲染卡片。

房源列表页的功能稍微复杂一点。页面左侧是筛选条件面板，包括城市下拉框、价格区间滑块、可住人数选择器；右侧是房源卡片列表，下面有分页组件。筛选条件的实现思路是：页面数据对象里维护一个queryParams对象，用户修改筛选条件时更新这个对象，然后调用接口重新查询。这里有个小技巧：监听筛选条件变化时加一个防抖处理，避免用户拖动价格滑块时频繁请求后端，减少服务器压力。

房源详情页面包含基本信息展示、图片画廊、设施标签、房东信息、历史评论和预订表单六块内容。预订表单的默认入住日期和离店日期用日期选择器设置，组件内通过计算属性自动算出入住天数，再乘上每晚价格得到总价，用户点击提交后调用下单接口。

4.5 前后端联调时的跨域处理

联调阶段最常见的报错就是浏览器控制台出现"CORS policy"的红色报错。跨域的原因是前端开发服务器运行在8080端口，后端Tomcat运行在8088端口，两个端口不同就构成了跨域。

解决跨域我推荐在后端加CORS配置，写一个CorsConfig类实现WebMvcConfigurer接口，重写addCorsMappings方法，允许所有来源、所有请求头、所有方法的跨域请求。开发阶段这样配没问题，但如果是部署到服务器，建议把allowedOrigins改成实际的域名，更安全，也能在论文的"系统安全设计"章节里写几句。

5. 论文写作思路与答辩准备要点

5.1 论文的章节结构与篇幅分配

民宿网站的毕业论文，我建议按照经典的"六章结构"来组织：绪论、相关技术介绍、系统分析、系统设计、系统实现、系统测试。每一章大概的篇幅是这样分配的：绪论一千字左右，写研究背景和意义、国内外研究现状；相关技术介绍三千字左右，重点写Spring、SpringMVC、MyBatis、Vue、MySQL这几个技术栈的原理和特点；系统分析两千字左右，包含可行性分析、需求分析、用例图；系统设计三千字左右，包含总体架构设计、功能模块设计、数据库设计；系统实现五千字左右，这是核心章节，需要展示关键代码并配合截图说明功能实现过程；最后系统测试一千字左右，用表格列出测试用例和结果。

论文最大的坑是把系统实现章节写成了代码堆砌。正确做法是每展示一段代码，都要解释这段代码完成什么功能、为什么这么写、涉及什么原理。比如展示MyBatis动态SQL的代码时，要说明<if>标签实现了什么条件判断，这种写法的好处是可扩展性。

5.2 数据库设计和系统分析图的画法

论文里的E-R图、用例图、时序图、流程图是绝对不能少的。很多同学会卡在画图上，其实工具选择很简单：ProcessOn在线画就行，支持拖拽式操作。数据库E-R图要把每张表的字段和关系标注清楚，用例图要区分用户角色，时序图选一个订单流程来画就行，不用把每个功能都画一遍。

5.3 答辩时的高频问题和应答思路

答辩环节不用太紧张，老师问的问题基本都在项目范围内。高频问题有几个：项目为什么选SSM框架？关键业务的实现思路是什么？遇到过什么困难怎么解决的？MySQL索引的原理是什么？这些问题的回答要点其实都可以从论文里找，只要是自己动手写的项目，这些问题都是送分题。

我特别想提醒的一点是：如果老师在答辩现场要求改需求，比如"加一个模糊搜索功能"或者"这个地方不加个判断吗"，不要慌也不要急着辩解，先顺着老师的意思说"可以加，实现思路是在某某层加个逻辑判断"，然后再简单说两句具体实现方案。这种临场反应能体现出对项目的理解深度，往往比提前准备的漂亮话更有效。

如果有些同学是不想自己写程序，想直接用开源项目来交差的，我的建议是无论如何都要把整个项目的源码看一遍，尤其是核心流程的代码，把每个表字段的含义搞清楚。答辩时老师问到你负责的模块，你至少能说出数据从哪来、经过哪些处理、最后怎么展示。完全不了解项目就上台，不管项目质量多好都容易露馅。

6. 常见问题与避坑指南

6.1 环境配置阶段的高频报错

SSM项目环境配置阶段的报错多到能写满一页纸。最常见的几个第一个是Maven依赖拉不下来，原因是本机用了国内镜像或者网络问题，解决方案是在Maven的settings.xml里配置阿里云镜像源，然后刷新项目让依赖重新下载。第二个是Tomcat启动时端口被占用，Port 8080 is already in use，排查方案是用命令行netstat -ano | findstr 8080查出占用进程PID，然后去任务管理器结束进程，或者直接把Tomcat端口改成8088一劳永逸。

第三个是ClassNotFoundException: org.springframework.web.context.ContextLoaderListener，这个错误的原因通常是依赖冲突或者系统库没有正确加入依赖。解决方案是在项目发布配置里，把Maven依赖部署到WEB-INF/lib目录下。用IntelliJ IDEA的同学特别容易踩这个坑，需要在File菜单下的Project Structure里，把Artifacts配置中的"Put into output root"改成"Copy to the output directory and link via manifest"，然后重新部署。

6.2 数据库和MyBatis相关的坑

数据库中文乱码是最常见的低级别错误，根源多半是数据库连接URL里没有指定编码。连接MySQL时，URL一定要加上characterEncoding=utf-8。如果你在Navicat里查询中文正常但程序查出来是乱码，那基本可以断定是连接URL的问题。

MyBatis相关的报错有一个比较隐蔽：Invalid bound statement (not found)。这个问题是说Mapper接口的方法在XML里找不到对应的SQL语句。原因一般是XML文件的namespace没有写对，或者id与接口方法名不一致，或者XML文件没有放在resources目录下导致编译时被忽略。排查思路是把MapperXML文件和接口放在同一包路径下，检查namespace是否写成了接口的全限定名，再确认一下构建后target目录里有没有XML文件。

还有TooManyResultsException这个异常，意思是预期返回一条记录但实际查出了多条。出现这个异常时先检查Mapper方法的返回类型，如果方法声明返回单个实体对象，但SQL查询出来两条以上记录，就会抛这个异常。在写登录按手机号查询用户或者按订单号查询订单这类方法时，一定要确保查询条件的唯一性。

6.3 前端Vue项目的调试经验

前端项目几个让我印象深刻的调试经历，正好可以分享出来。第一个是Element UI的组件样式不生效，多半原因是全局样式覆盖了组件样式，检查一下App.vue里有没有scoped没有写好。第二个是Axios请求带不上Token，检查一下请求拦截器里的代码逻辑，Token从localStorage取出之后有没有正确放到请求头。第三个是列表页数据更新后页面不刷新，检查数据是直接赋值还是通过Vue.set，Vue2的响应式系统对数组下标赋值无能为力，所以操作数组时要使用this.$set或者对数组重新赋值。

前端页面调试工具方面，Chrome的Vue Devtools插件几乎是必备的，组件层级、状态数据、路由参数都能一目了然。遇到页面空白的情况，先打开控制台看有没有JS报错，再检查路由配置是否正确匹配到组件，最后排查数据是否成功获取。这样一条线排查下来基本都能解决。

6.4 时间规划和代码备份的建议

最后给一个时间规划的建议。如果你是从零开始做这个项目，我给的时间安排是：第一周做数据库设计和接口文档，第二三周完成后端全部接口，第四周完成前端页面和联调，第五周写论文初稿，第六周打磨论文和准备答辩PPT。这个节奏比较从容，每天晚上花两三个小时就够。

代码管理方面，我强烈建议把项目提交到码云或GitHub上，不只是为了备份，更因为论文写作时你需要回看每一段关键的代码和提交记录。数据库表结构如果改过几次，最好保留一份地区分版本的表结构SQL文件。答辩前把数据库导出一份完整的备份，防止演示现场数据库被误操作。这些细节看着琐碎，真正经历过一次毕业设计的周期，你就会知道它们有多重要。

整个项目做下来，我的体会是民宿网站这个选题的优势在于"小而完整"。麻雀虽小五脏俱全，从用户注册登录到房源管理到订单流转，这条业务线能覆盖SSM框架绝大多数学术概念，前后端分离的架构又能写出足够的技术深度。把上面这些设计思路和实现细节走通一遍，不管是代码、论文还是答辩，心里都会很有底气。