从零搭一个旅游管理平台并没有想象中那么复杂但其中的弯路确实不少。这个基于 SpringBoot Vue 的西安旅游系统管理系统是我前后端分离实践里比较完整的一套练手项目技术栈选型非常主流后端用 SpringBoot 整合 MyBatis数据库用 MySQL前端走 Vue 全家桶。为了不让这套源码变成“能跑就行”的玩具我在设计时把用户端和管理端都做进去了覆盖了景点管理、线路规划、票务订单、资讯发布等实际业务场景。这篇文章就把整个系统的设计与实现过程完整拆开讲讲包括表结构怎么设计、接口怎么规划、前端页面与后端逻辑怎么对接以及我在实际调试过程中踩过的那些坑。如果你正在做类似的旅游系统课设、毕业设计或者想入门前后端分离开发这篇可以直接抄作业。1. 项目整体设计与思路拆解1.1 为什么选 SpringBoot Vue 这套组合现在做 Java Web 项目SpringBoot 基本是事实标准。它内置了 Tomcat省去了繁琐的 XML 配置配合 MyBatis 操作数据库非常顺手。前端选 Vue 则是因为组件化开发对页面复用太友好了比如景点卡片、订单条目这些组件可以在列表页、详情页、个人中心多处复用改一处全局生效。前后端分离开发还有一个直观的好处前端跑在 8080后端跑在 8081互相之间只通过 JSON 格式的接口交互逻辑边界清清楚楚。当然选型不是看哪个火就无脑上得看实际场景。旅游管理系统这种典型的 CRUD 密集型业务用 SpringBoot 做后端足够轻量不需要引入 Spring Cloud 那套微服务全家桶数据量级在中小型旅游平台范围内MySQL 单库单表完全能扛住MyBatis 相比 JPA 更灵活SQL 自己掌控遇到多表关联查询、条件动态拼接这种场景特别好用。说白了这就是一套最务实、最成熟的组合。1.2 整体功能模块的规划逻辑拿到需求后别急着写代码先把功能模块画清楚。这个系统分为两个端前台用户端和后台管理端。用户端面向普通游客主要功能是查看景点信息、浏览旅游线路、在线预订门票和酒店、提交订单以及发布评论和收藏感兴趣的内容。管理端面向系统运营人员负责维护景点数据、线路信息、订单审核、用户管理、公告发布等。前后端共用同一套数据库通过权限角色区分可访问的接口。模块划分上我遵循了“高内聚低耦合”的思路。每个业务模块独立成一个包结构景点模块、线路模块、酒店模块、订单模块、用户模块、评论模块、公告模块。各模块之间不互相调用对方的 Service 层方法需要联动时通过事件或统一协调层处理。这样做的直接好处是后期改订单逻辑时不会牵扯到景点模块的代码排查问题时定位也快。1.3 目录结构与包层级设计后端项目的包结构参考了阿里巴巴规范按功能分包而不是按层分包com.travel.system ├── controller // 接收请求参数校验返回结果 ├── service // 业务逻辑层事务管理 ├── mapper // MyBatis 数据访问层 ├── entity // 数据库实体类 ├── dto // 前端交互的数据传输对象 ├── vo // 视图对象组装页面展示数据 ├── config // 配置类跨域、拦截器、静态资源 ├── utils // 工具类JWT、MD5加密、统一返回结果 └── exception // 全局异常处理这样的分包方式有个好处代码从上到下调用链路非常清晰。Controller 不做业务判断只做参数接收和结果包装Service 层只处理业务逻辑不出现 SQL 语句Mapper 层只写数据库操作。前端调接口时看到的返回结构是统一的 Result 对象包含 code、message、data 三个字段前端只需要判断 code 是否为 200 即可不需要为每个接口单独写容错逻辑。2. 数据库设计与核心表结构解析2.1 数据表总体规划这套系统的核心数据表一共 8 张分别是用户表、景点表、线路表、酒店表、订单表、评论表、收藏表、公告表。表之间通过外键逻辑关联但在实际建表时并没有物理外键约束而是靠代码层维护逻辑关系。这是很多实际项目的常见做法因为物理外键在数据量大、分库分表时会成为性能瓶颈而且删除数据时容易触发外键约束报错影响运维操作。以景点表和线路表为例一条旅游线路会包含多个景点通常是线路表和线路景点关联表来维护多对多关系。但考虑到这个项目的业务复杂度线路描述中直接以景点 ID 列表的形式存入 JSON 字符串字段简单直接。对于中小型系统能少一张关联表就少一张查询少一次 JOIN 就是一次性能优化。2.2 核心表字段设计详解用户表user是最基础的表字段包括用户 ID、用户名、密码MD5 加密存储、昵称、手机号、邮箱、头像地址、角色USER/ADMIN、状态启用/禁用、创建时间。其中用户名做了唯一索引防止重复注册密码字段长度为 64因为 MD5 加密后的结果固定是 32 位但预留了以后升级为 SHA-256 或加盐处理的扩展空间。景点表scenic_spot是旅游系统的核心内容表字段设计得比较细CREATE TABLE scenic_spot ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT 景点编号, name VARCHAR(100) NOT NULL COMMENT 景点名称, description TEXT COMMENT 详细描述, category VARCHAR(50) COMMENT 分类自然风光/历史文化/主题乐园等, province VARCHAR(50) COMMENT 所在省份, city VARCHAR(50) COMMENT 所在城市, address VARCHAR(255) COMMENT 详细地址, cover_image VARCHAR(255) COMMENT 封面图片URL, location_lat DECIMAL(10, 8) COMMENT 纬度, location_lng DECIMAL(11, 8) COMMENT 经度, ticket_price DECIMAL(10, 2) DEFAULT 0.00 COMMENT 门票价格, open_time VARCHAR(100) COMMENT 开放时间如08:00-18:00, rating DECIMAL(2, 1) DEFAULT 5.0 COMMENT 评分, status TINYINT DEFAULT 1 COMMENT 状态1上架 0下架, created_time DATETIME COMMENT 创建时间, updated_time DATETIME COMMENT 更新时间 );订单表orders设计时要特别注意金额字段用 DECIMAL 而不是 FLOAT 或 DOUBLE避免浮点数精度误差。订单状态用 TINYINT 存储0 表示待支付、1 表示已支付、2 表示已完成、3 表示已取消。下单时间、支付时间、完成时间三个时间字段分别记录方便统计订单时效和售后处理。订单号字段用时间戳加随机数生成保证唯一性同时具备一定的防猜测能力。2.3 索引设计与查询性能考虑数据库性能优化最直接的手段就是建索引但索引不是越多越好。我在设计时只针对高频查询字段建索引用户表的用户名、景点表的分类和城市、订单表的用户 ID 和订单号。索引选择 BTree 结构因为 InnoDB 存储引擎默认支持适合范围查询和排序操作。sql 层面要注意一个细节尽量避免在索引列上使用函数计算。比如查询某个日期范围内的订单直接写WHERE create_time 2024-01-01 AND create_time 2025-01-01而不是WHERE DATE_FORMAT(create_time, %Y-%m-%d) 2024-01-01。后者会导致索引失效全表扫描数据量大了之后响应时间会成倍上升。3. 后端核心实现与关键逻辑解析3.1 统一返回结果与全局异常处理接口对接中最痛苦的事情就是前后端对返回格式各执一词。我在项目初始化时就直接定义好统一的返回结构避免后面扯皮Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }全局异常处理用的是RestControllerAdvice注解搭配ExceptionHandler可以按异常类型分别处理。业务异常比如下单时库存不足返回 code 500 和具体提示信息参数校验异常返回 code 400系统级异常返回通用提示不把内部堆栈信息直接抛给前端。这样前端拿到的永远是结构一致的 JSON后端出问题也不会暴露 SQL 语句等敏感信息。3.2 基于 JWT 的登录鉴权机制用户登录后需要一个凭证证明“我是谁”这里用的是 JWTJSON Web Token方案。登录成功后后端生成一个 token 返回给前端前端存储在 localStorage 中每次请求在请求头带上Authorization: Bearer token。后端通过拦截器解析 token判断用户身份。JWT 的优势在于服务端不需要存储会话信息天然适合前后端分离缺点是 token 一旦签发在有效期内无法主动失效。解决办法是设置合理的过期时间。这个系统中 token 有效期设为 2 小时用户在前端操作时每次接口返回都会刷新 token 有效期前端判断 token 即将过期时自动重新登录。拦截器配置时要特别注意放行白名单。登录接口、注册接口、景点列表查询这些不需要登录就能访问的接口必须在配置中排除否则会出现用户还没登录就被拦截的尴尬局面。静态资源也要放行不然前端页面都加载不出来。3.3 订单模块的事务与并控处理下单功能是整个系统中业务逻辑最复杂的模块涉及的操作包括校验景点和线路是否存在、计算订单金额、创建订单记录、更新景点剩余库存如果启用了库存限制、推送订单通知等。这些操作必须保证原子性要么全部成功要么全部失败不能出现订单创建了但库存没扣的情况。解决方案是在 Service 层方法上加Transactional注解让 Spring 统一管理事务提交和回滚。并发场景也要考虑。如果两个人同时购买同一景点最后一张票不加控制就会出现超卖。这个项目里我在景点表设计了一个库存字段下单时先执行UPDATE scenic_spot SET stock stock - 1 WHERE id ? AND stock 0通过数据库行锁保证同一时刻只能有一个事务成功更新库存。受影响行数为 0 说明库存不足直接抛出业务异常回滚事务。这种方式比在 Java 代码里加 synchronized 锁靠谱得多因为分布式环境下 synchronized 只能锁住当前 JVM而数据库锁是全局生效的。3.4 MyBatis 的关键配置与动态 SQLMyBatis 的配置中有几个容易出问题的地方需要格外注意。第一个是驼峰命名映射数据库字段create_time默认无法直接映射到实体类的createTime属性必须在 mybatis-config.xml 中开启settings setting namemapUnderscoreToCamelCase valuetrue/ /settings第二个是动态 SQL。景点查询往往带有多个可选的筛选条件分类、城市、价格区间、关键词搜索。如果用 JDBC 硬拼 SQL条件多了之后代码会非常难维护。MyBatis 的where标签配合if标签可以优雅解决这个问题select idselectByCondition resultTypecom.travel.system.entity.ScenicSpot SELECT * FROM scenic_spot where if testcategory ! null and category ! AND category #{category} /if if testcity ! null and city ! AND city #{city} /if if testkeyword ! null and keyword ! AND (name LIKE CONCAT(%, #{keyword}, %) OR description LIKE CONCAT(%, #{keyword}, %)) /if if testminPrice ! null AND ticket_price gt; #{minPrice} /if if testmaxPrice ! null AND ticket_price lt; #{maxPrice} /if /where ORDER BY rating DESC /selectwhere标签会自动去掉多余的 AND 关键字避免“WHERE AND”这种语法错误。这个细节我刚开始写 MyBatis 时踩过坑条件全为空时生成的 SQL 是SELECT * FROM scenic_spot WHERE直接报语法错误换成where标签后问题彻底解决。4. 前端 Vue 实现与页面交互细节4.1 前端项目结构与路由设计前端用 Vue CLI 搭建采用标准 Vue 2.x 结构。页面路由用 vue-router 管理分为用户端和管理端两个独立的布局组件。用户端路由包括首页、景点列表、景点详情、线路页面、订单列表、个人中心管理端路由包括仪表盘、景点管理、订单管理、用户管理、公告管理。根据用户角色做路由守卫非管理员访问管理端页面时直接跳转到首页。路由懒加载是通过动态 import 实现的const ScenicDetail () import(/views/scenic/ScenicDetail.vue)。这样首次加载只打包首页相关的代码点击进入详情页时才加载对应组件首屏加载速度能提升明显。我在实测时发现不做懒加载的情况下打包产物接近 3MB配置了懒加载之后首屏请求量减少了 40% 左右。4.2 Axios 请求封装与拦截器前端所有接口请求都封装在一个统一的 request.js 文件中基于 axios 二次封装。这么做的好处有三个第一统一设置基础路径和超时时间不用在每个组件里重复配置第二通过请求拦截器自动附加 token避免漏传第三响应拦截器统一处理错误码后端返回 401 时自动跳转到登录页弹错提示也不用每个页面都写一遍。import axios from axios import { Message } from element-ui import router from /router const service axios.create({ baseURL: process.env.VUE_APP_BASE_API, timeout: 10000 }) 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) { return res } else if (res.code 401) { localStorage.removeItem(token) router.push(/login) return Promise.reject(new Error(登录状态已过期)) } else { Message.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } }, error { Message.error(error.message || 网络异常) return Promise.reject(error) } ) export default service超时时间设置成 10 秒是基于实际网络环境的考虑。太短了用户弱网环境下经常请求失败太长了接口挂起时前端一直处于加载状态体验也很差。10 秒是一个比较均衡的默认值特殊情况比如导出报表可以在调用时单独覆盖 timeout 参数。4.3 Element UI 组件在实际页面中的落地管理端页面大量使用 Element UI这里重点说几个实际使用中的经验。表格组件el-table搭配分页组件el-pagination是管理端页面最常见组合。分页参数包括 currentPage、pageSize、total 三个字段。后端接口接收 pageNum 和 pageSize 参数使用 PageHelper 插件自动完成分页查询返回数据中带上 total 总数。这里需要注意 PageHelper 的使用细节它通过拦截器自动在 SQL 语句后面拼接 LIMIT 关键字但必须确保 PageHelper.startPage() 方法后面紧跟的第一条 SQL 就是需要分页的查询语句。景点图片上传用的是el-upload组件关键的坑在于后端接口接收文件的方式。前端默认上传的是 FormData 格式后端要用RequestParam(file) MultipartFile file接收不能直接用 JSON 格式。文件上传后我选择存储到服务器的 upload 目录下数据库中只保存相对路径如/upload/image20240101120000.jpg。这样做的好处是数据库表体积不会因为图片而膨胀前端可以直接拼接域名访问静态资源。4.4 用户端页面的交互细节与体验优化用户端首页是门面设计上参考了主流旅游平台的布局顶部导航栏包含 logo、搜索框、导航菜单、登录按钮中间是轮播图展示热门景点下面是按分类展示的景点卡片网格。搜索功能用防抖处理是提升性能的关键点。用户在搜索框输入“兵马”两个字如果每输入一个字符就发一次搜索请求前后端压力都会很大。我在实现时用 lodash 的 debounce 函数做 300 毫秒防抖用户停止输入后才真正发起请求。实测体验是搜索结果几乎无感更新但请求次数减少了 60% 以上。景点详情页的图片预览用的是el-image组件配preview-src-list属性用户点击小图可以放大到全屏预览对于展示风景类照片非常重要。线路选择、日期选择、票价计算这些联动逻辑统一用计算属性 computed 处理代码比 watch 监听多个变量简洁得多。5. 系统部署、环境配置与项目启动指南5.1 本地环境准备与版本选择开发这个项目时我的环境配置如下JDK 1.8、Maven 3.6、MySQL 5.7、Node.js 14。这里强调一下版本兼容性问题SpringBoot 2.7.0 版本对应 JDK 8 没有问题但如果选 SpringBoot 3.x 就必须用 JDK 17。很多同学照着网上的教程配置项目结果启动直接报错大部分都是版本不匹配造成的。Maven 仓库地址建议配置为阿里云镜像否则下载依赖的速度会让你怀疑人生。在 maven 的 settings.xml 中添加镜像配置下载速度能从几分钟提升到几秒钟。Node 依赖安装同理使用 npm 配置淘宝镜像源install 时间能缩短 80% 左右。这个项目初始依赖数量大概是后端 30 多个 jar 包、前端 200 多个 npm 包没有镜像加速的话光拉取依赖就要半天。5.2 后端启动的具体步骤第一步导入 sql 脚本。使用 Navicat 或者命令行执行项目根目录下的 travel.sql 文件它会自动创建数据库和数据表同时插入一部分初始数据。数据库名建议统一为 travel_system如果改成其他名称需要同步修改 application.yml 中的连接配置。第二步修改 application.yml 中的数据库连接信息主要检查 url、username、password 三项。spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/travel_system?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456url 参数中几个容易忽略的细节characterEncodingutf8 保证中文不乱码useSSLfalse 跳过证书验证本地开发不配置这一项会报警告日志serverTimezoneAsia/Shanghai 解决时区问题不配这个的话数据库时间会比当前时间少 8 小时。第三步配置静态资源映射。因为图片上传是相对路径存储需要让 SpringBoot 能将 /upload/** 的请求映射到实际存储目录Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath /); } }第四步启动项目。在 IDEA 中直接运行主启动类看到Started Application in x.xx seconds日志即启动成功默认端口 8081。访问http://localhost:8081/api/hello做连通性测试。5.3 前端启动与前后端联调配置前端项目安装依赖后运行npm run serve默认端口是 8080。如果同时启动前后端需要在前端项目根目录创建.env.development文件配置接口地址指向后端VUE_APP_BASE_APIhttp://localhost:8081/api配置好后前端 axios 的 baseURL 会自动拼接这个地址所有接口请求都能正确代理到后端服务。这里要提醒一个常见问题跨域。前端端口是 8080后端端口是 8081端口不同就存在跨域问题。解决方案是后端配置全局 CORS 映射允许所有来源跨域访问Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }开发阶段直接放开所有跨域限制是最省事的方案。生产环境如果前后端部署在同一 Nginx 服务下通过反向代理就不存在跨域问题这个配置可以收紧。6. 实际开发中的踩坑记录与问题排查6.1 时区问题导致的时间字段错乱这个问题几乎所有人都会遇到。数据表中存的 create_time 是正常的但从前端传过来的时间参数总是差了 8 个小时。排查发现是 JDBC 连接串中 serverTimezone 参数没设置MySQL 使用了系统默认时区而本机系统是 UTC 时区。解决办法就是在数据库连接 url 中加上serverTimezoneAsia/Shanghai。已经出现的时间数据不用慌用一条 SQL 就能把历史数据修复回来UPDATE orders SET create_time DATE_ADD(create_time, INTERVAL 8 HOUR) WHERE create_time IS NOT NULL;6.2 MyBatis 返回值为 null 的排查思路系统上线后用户反馈订单详情页面部分字段显示为空排查后发现是实体类属性和表字段命名不一致。订单表中order_no字段对应实体类orderNo属性如果 mybatis-config.xml 中没开启mapUnderscoreToCamelCase查询结果就无法自动映射到这个属性。排查顺序建议遵循三步走的思路第一步到数据库执行 SQL看数据是否存在排除数据问题第二步看控制台打印的 SQL 和查询结果确认 MyBatis 是否执行了正确的 SQL第三步检查实体类属性映射重点核对驼峰命名配置。这里面最常见的坑就是数据有、SQL 正确、但属性映射失败只在实体类中添加了JsonProperty注解却没有配置驼峰映射规则。6.3 文件上传失败的权限问题景点图片上传功能在本地开发环境一切正常但部署到服务器后上传的文件提示保存失败。最终发现是服务器上 tomcat 运行用户对上传目录没有写权限。在服务器上执行chmod 777 upload临时解决但更规范的做法是创建一个专用目录并把目录所有者改为 tomcat 用户。还有一个容易忽略的细节是图片上传大小限制。SpringBoot 默认单文件上传最大限制是 1MB超过这个大小接口会直接抛 MaxUploadSizeExceededException。如果景点图片都是手机拍摄的高清照片1MB 很容易超限。需要在配置文件中调整spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB配置之后前端也要同步检查Element UI 上传组件的limit属性和before-upload钩子函数里限制的文件类型、大小以及 baseURL 都要保持一致。我遇到过前端限制了图片类型为 jpg/png 但没限制大小用户选了 5MB 的照片上传后报错体验很不友好。6.4 前后端联调时的网络错误排查手册首页数据加载不出来打开浏览器控制台看 Network 面板发现请求状态是 CORS error。这基本都是后端跨域配置的问题。检查配置类是否正确加载、拦截器是否拦截了 OPTIONS 预检请求。JWT 拦截器如果没放行 OPTIONS 请求浏览器发送预检请求时直接被拦截返回 401前端就报跨域错误。这个问题非常隐蔽因为后端控制台根本看不到任何异常日志我排查了很久才定位到。遇到接口返回 404 时先看控制台请求 URL 是否拼写正确很多情况是 VUE_APP_BASE_API 配置了/api前缀后端 Controller 的 RequestMapping 也有/api前缀结果实际请求变成了/api/api/scenic/list除非后端也配置了/api/api才能访问到接口否则必然 404。接口请求正常但返回 500优先看后端控制台异常日志。一般会有明确的堆栈信息比如 SQL 语法错误、空指针异常、数据库连接失败等。如果日志中提示Connection refused检查 MySQL 服务是不是关了、账号密码是否正确、端口是不是 3306。这几个问题按出现频率排序登录认证问题排第一其次是端口占用最后才是数据库账号权限。6.5 启动报错的常见场景速查报错信息可能原因解决方案Port 8081 was already in use端口被占用杀掉占用端口的进程或修改application.yml中端口号Failed to configure a DataSource数据库连接配置有问题核查用户名密码、url 连通性确认 mysql 服务已启动java.lang.IllegalArgumentException: Cannot find cache namedRedis 或缓存配置缺失检查是否引入了不必要的缓存依赖未使用就移除No qualifying bean of type注入的 Service/Mapper 未被 Spring 管理检查类是否标注了Service、Mapper注解以及扫描包路径npm ERR! ERESOLVE unable to resolve dependency treeNode 版本过高或依赖冲突使用项目指定的 Node 14 版本删除 node_modules 重新 installUnknown database travel_system数据库未创建或名称拼写错误确认数据库名或在 SQL 文件中先执行 create database排错的通用心法就一句话先看后端日志再看前端请求。后端日志能看到异常堆栈和 SQL 执行情况前端控制台能看到请求 URL、请求方式、请求头、响应状态码。前后端各自日志比对90% 的问题都能手到擒来。7. 项目扩展方向与二次开发建议这个系统做完基础版本之后后续可以扩展的空间还很大。如果要做成商业级产品至少可以在下面几个方向发力第一个方向是引入 Redis 缓存。景点详情、公告列表这些热点数据访问频率极高每次都查数据库会有不必要的磁盘 IO。加一层 Redis 缓存后热点数据查询响应时间能从 50ms 降到 5ms 以内。同时可以把 JWT 的 token 存在 Redis 中实现主动登出功能解决 JWT 无法主动失效的痛点。第二个方向是增加支付能力。对接微信支付或者支付宝支付用户在订单模块提交订单后跳转支付页面支付回调通知订单状态变更。这一块涉及签名验证、回调幂等处理、对账逻辑等知识点都是面试中非常加分的内容。第三个方向是数据分析功能。根据订单数据统计热门景点排行、游客来源地分布、月度收入趋势生成可视化图表。管理端仪表盘页面用 ECharts 做数据可视化展示后端提供统计接口按时段聚合查询数据。第四个方向是移动端适配。目前系统的用户端页面在手机浏览器上虽然能用但体验一般。可以基于同一套后端接口开发一个小程序端或者做一套响应式适配使用uni-app或跨平台框架实现一套代码多端运行后端接口完全复用不冲突。我个人在实际开发这个项目过程中的体会是旅游类管理系统的难点不在技术本身而在业务逻辑的严谨性和细节的完整性。订单金额的计算、状态流转的边界条件、用户操作权限的控制这些问题没想清楚就急着写代码后面返工的代价非常大。建议拿到需求后先花几天时间把业务流程捋顺画清楚状态流转图再开始建表写接口。另外一定要注重代码规范的养成统一返回类型、统一异常处理、统一命名风格哪怕项目规模不大这些习惯都会在以后的工作中带来巨大收益。如果你准备拿这个项目作为毕业设计或者简历项目别只停留在“能跑”的程度花点时间把其中一个模块做深做透。比如订单模块引入分布式锁处理超卖问题或者在缓存层面把数据一致性问题讲清楚这些亮点比堆砌十张表更有说服力。项目源码本身只是起点把每个设计决策背后的为什么想明白才是真正能把项目变成自己作品的关键。