旅游管理系统这个选题在Java全栈项目里算是出现频率最高的那一档了。我帮人做技术评审的时候见过不少类似的系统一个很典型的通病是SpringBootVue的架子搭得很完整但业务做得很虚——线路管理就是一张表的增删改查订单模块只有个空壳收藏和评论功能干脆没有用户登录以后除了改密码什么也干不了。问题从来不在技术上而在需求拆解上。这篇文章想聊的是一套按实际业务流转设计的旅游管理系统覆盖线路、订单、收藏、评论、后台统计的完整闭环后端用SpringBootMyBatisMySQL前端用Vue整套源码结构和关键实现思路都会摊开来讲。无论你是准备课程设计、毕业设计还是纯粹想找个全栈练手项目应该都能直接从里面抄作业。1. 功能需求拆解旅游管理系统到底该管什么先说一个我见过很多次的翻车场景。有人拿到旅游管理系统这个题目第一反应就是先建一张景点表然后开始写增删改查接口。等写到订单的时候发现做不下去了——因为订单要关联用户、关联线路、记录支付状态、处理取消逻辑这些前置设计一开始没想清楚后面全是补丁。所以我一直觉得做这种系统第一件事不是写代码而是把业务边界画出来。1.1 从用户视角推演出来的核心流程做需求拆解有一个比较实用的方法把自己当成用户把一次完整的旅游消费行为从头走一遍。用户第一次访问这个系统大概率是路过看一眼有什么线路。此时用户处于游客状态可以浏览线路列表、看线路详情页、阅读其他用户的评价。看到心仪的线路之后如果要下单就必须登录或注册。登录之后可以收藏线路、下单购买、对去过的线路发表评论。管理员这边登录后台之后要能维护线路分类、发布和修改线路信息、处理用户的订单确认、取消、完成、管理用户状态、看基本的运营数据。把这条流程走下来系统的核心模块就自然浮现了用户模块、线路模块、订单模块、评论模块、收藏模块、后台管理模块。没有哪个功能是拍脑袋想出来的都是业务流转中真实需要的环节。1.2 功能清单具体落到模块划分梳理完流程之后我习惯再用一张表格把功能清单沉淀下来后面做数据库、写接口、画页面全都是按照这张表来走。模块用户端功能管理端功能用户管理注册、登录、个人信息查看与修改用户列表、状态启停用线路分类按分类浏览线路分类的增删改查旅游线路线路列表分页查询、关键字搜索、线路详情查看线路发布、编辑、上下架、删除订单管理创建订单、我的订单列表、取消订单订单列表、订单状态变更收藏管理添加收藏、取消收藏、收藏列表查看收藏数据评论管理发表评论、查看线路评论列表评论审核、删除违规评论统计看板无线路数量、订单量、销售额等基础统计这里面的关键点在于评论和收藏往往是很多初做项目的人会漏掉的部分。但从业务完整度来看这两个模块恰恰是旅游类系统区别于普通商品系统的标志之一——用户决策高度依赖他人的体验分享收藏列表则是典型的先存着以后再看的消费心理。把这两个模块加进去整个项目无论从功能完整度还是从最终评分角度都会上一个台阶。2. 技术选型逻辑SpringBootVueMyBatis这套组合为什么顺手技术选型这块我不太喜欢因为流行所以选的说法。做项目选型看的是三个维度组织成本低、学习曲线友好、生态资料足够多。SpringBootVueMyBatis这套组合在这三个维度上的表现都相当均衡。2.1 SpringBoot解决的痛点和MyBatis的真实优势先讲后端。SpringBoot最核心的价值是约定优于配置——内嵌Tomcat应用打包成jar直接启动不用再像传统SSH时代那样部署到外部容器。SpringMVC负责HTTP层的路由和参数绑定Spring容器管理对象依赖这整套机制对单体业务系统来说组织成本已经压到了很低的水平。MyBatis在这套组合里的角色更微妙。有些人觉得MyBatis是过时的半自动ORM但在旅游管理系统这种多条件组合查询非常频繁的场景里MyBatis的动态SQL反而是最大的优势。线路列表要支持按分类筛选、按关键字模糊搜索、按价格区间和出发城市过滤如果在JPA里写这种多条件查询要么用Specification写出一大串代码要么直接拼原生SQL可读性都不理想。MyBatis的XML文件里用where配合if标签几行代码就解决了一个完整的动态查询问题而且SQL是显式可见的方便针对性优化。2.2 Vue在前端扮演的角色前端选Vue核心理由是组件化和响应式带来的开发效率。旅游管理系统的用户端页面虽有列表、详情、下单、个人中心等多个页面但页面结构有一定相似性——比如线路卡片和评论列表抽象成组件之后可以在多个页面复用。Vue的单文件组件机制让模板、脚本、样式集中在同一个文件里对于单人开发这种规模的项目来说心智负担是最小的。另外补充一点版本上的建议。现在Vue3已经非常稳定Element Plus组件库也足够成熟新项目直接用Vue3是没问题的。但如果你的参考资料和已有代码大多基于Vue2Element UI继续用Vue2也不算错关键是要把版本锁死别混用。我自己做的版本是Vue3Element PlusVite下面讲前端的时候都按这个版本来说。2.3 为什么不碰微服务和更复杂的架构顺带回答一个很多新人会纠结的问题旅游管理系统这种量级的项目为什么不拆微服务、不引入Redis、不用消息队列答案很直接——架构的复杂度必须和业务的复杂度匹配。微服务解决的是多团队协作、独立部署、弹性伸缩的问题单体应用里这些需求根本不存在。Redis缓存和MQ同理如果系统规模到不了那个量级引入这些组件只会增加部署和排错的成本。但这不意味着这些技术不能碰。一个比较务实的做法是在系统里预留缓存位置和接口扩展点比如首页的热门线路接口内部先走数据库查询但接口设计上留出加缓存的余地。这样既能保证当前项目的可完成性又能体现技术视野。3. 数据库设计旅游业务的数据模型是怎么一步步建出来的数据库设计是整个项目里最不能图快的一部分。表结构一旦定下来后面的实体类、Mapper、接口、页面全都跟着它走中途返工的成本非常高。我做这套系统的时候表结构前后调整了三版核心的几个设计要点整理在下面。3.1 六张核心表的结构设计与字段说明完整系统里我一共设计了七张表除了下面列出来的六张核心表之外还有一张管理员表。这里的核心表分别是用户表、线路分类表、旅游线路表、订单表、收藏表、评论表。以旅游线路表为例字段设计最能体现旅游业务的特殊性。旅游线路和普通商品有一个很大的区别——它的属性维度非常多。目的地、出发城市、行程天数、价格、成团人数上限、线路封面图、线路详情描述这些字段涵盖了一个旅游产品最核心的信息。CREATE TABLE t_route ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT 线路ID, category_id INT NOT NULL COMMENT 所属分类ID, route_name VARCHAR(100) NOT NULL COMMENT 线路名称, depart_city VARCHAR(50) NOT NULL COMMENT 出发城市, destination VARCHAR(100) NOT NULL COMMENT 目的地, days INT NOT NULL COMMENT 行程天数, price DECIMAL(10,2) NOT NULL COMMENT 价格, max_people INT DEFAULT 20 COMMENT 成团人数上限, cover_image VARCHAR(255) COMMENT 封面图URL, description TEXT COMMENT 线路详情描述, status TINYINT DEFAULT 1 COMMENT 状态1上架 0下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );几个字段设计的思路要单独说一下。价格字段用DECIMAL(10,2)而不是DOUBLE或FLOAT是因为浮点数在金额计算中存在精度丢失问题订单金额累加、统计销售额时会出现莫名其妙的误差这是钱相关字段的硬性规范没有什么好讨论的。max_people这个字段代表了旅游线路成团人数的属性这个字段在后面订单校验里会起到关键作用不能省略。3.2 订单表的状态流转设计订单表是整个系统里关联关系最复杂的表。它既要关联用户又要关联线路还承载了金额、状态、下单时间、出行时间这些业务字段。CREATE TABLE t_order ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 订单编号, user_id INT NOT NULL COMMENT 下单用户ID, route_id INT NOT NULL COMMENT 线路ID, price DECIMAL(10,2) NOT NULL COMMENT 下单时线路价格, person_count INT DEFAULT 1 COMMENT 出行人数, total_price DECIMAL(10,2) NOT NULL COMMENT 总金额, status TINYINT DEFAULT 0 COMMENT 状态0待确认 1已确认 2已完成 3已取消, travel_date DATE COMMENT 出行日期, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );这里有两个容易被忽视的设计细节。第一个是order_no字段订单编号要求唯一通常用时间戳加随机数的策略生成这么做是为了后续可能对接支付平台时保证外部系统的幂等性要求。第二个是price字段存的是下单时线路的价格而不是实时关联查询线路表的价格。为什么要冗余这个字段因为线路价格随时可能调整如果用户下单之后线路涨价了订单里存的应该是用户下单那一刻的约定价格而不是查询时的最新价格。这种历史快照的设计思路在电商系统里叫冗余存储属于非常基础的订单设计规范。3.3 外键约束能不用就不用还有一点是我的个人实践建议表之间的关联关系在逻辑上通过字段去关联但物理上尽量不建外键约束。比如t_order表里的user_id和route_id设计上它们一定指向t_user.id和t_route.id但我不会在DDL里加FOREIGN KEY。原因也很简单。外键约束会影响插入和更新的性能更重要的是会限制业务操作的灵活性。比如管理员要物理删除一条违规线路时如果这条线路下已经存在历史订单外键约束会直接报错阻止删除这时候你还得先想办法处理订单数据才能删。业务代码里自己保证引用完整性比数据库层面的强约束在实际项目中更灵活。这个思路在互联网公司的实际开发中也是主流做法。4. 后端核心链路从Controller到Mapper的完整实现后端这部分我按一条完整的请求链路来讲——一次前端请求进来Controller层接收参数Service层处理业务逻辑Mapper层操作数据库。把这个链路打通了整个后端框架就立起来了。4.1 统一返回结构和全局异常处理后端接口设计的第一件事是定义前后端交互的数据格式。如果每个接口返回的JSON结构都不一样前端联调的时候就得为每个接口单独处理数据格式极其痛苦。我定义一个统一的返回类Result所有接口都返回这个结构。Data public class ResultT { private Integer code; // 200成功其他为失败 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可以把校验异常、业务异常、未知异常分别映射到不同的返回结果。这么做的好处是整个Controller层非常干净不需要在每个方法里写try-catch。4.2 基于JWT的用户登录鉴权设计旅游管理系统的部分接口是需要登录才能访问的比如创建订单、查看个人订单、发表评论。我的方案是在用户登录成功后签发一个JWT令牌前端把令牌存在本地每次请求在Header里带上后端用一个拦截器统一校验。登录接口的Service层逻辑大致是根据用户名查询用户比对密码时先用MD5对原始密码做哈希再与数据库中的值比对。密码明文存储是绝对不可取的哪怕只是一个课程设计项目也要从一开始就养成安全写入的习惯。JWT令牌里只放用户ID和用户名不涉及敏感信息有效期为24小时过期之后前端会收到401状态码自动跳转登录页。Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token ! null token.startsWith(Bearer )) { token token.substring(7); // 解析、校验token从中获取userId存入request属性 Claims claims JwtUtil.parseToken(token); request.setAttribute(userId, claims.get(userId)); return true; } response.setStatus(401); return false; } }拦截器里对白名单路径放行比如登录注册接口、线路列表查询接口、线路详情接口都是无需鉴权的。只需要在WebMvcConfigurer里配置addInterceptors并指定excludePathPatterns就可以实现不需要在每个Controller方法上单独写注解。4.3 线路分页查询MyBatis动态SQL的实际运用前面选型的时候说MyBatis的最大优势是动态SQL这里落到代码上看一下。线路列表查询接口要支持按分类筛选、按关键字搜索、按价格区间过滤、按出发城市过滤还要分页参数组合方式非常多。Service层对应的查询方法Override public PageResultRouteVO getRoutePage(RouteQuery query) { // query中包含当前页pageNum、每页条数pageSize、分类ID、关键字、最低价、最高价 ListRouteVO list routeMapper.selectRoutePage(query); Long total routeMapper.countRoutePage(query); return PageResult.of(list, total); }Mapper的XML实现select idselectRoutePage resultTypecom.xxx.vo.RouteVO SELECT r.*, c.category_name FROM t_route r LEFT JOIN t_category c ON r.category_id c.id where r.status 1 if testcategoryId ! null AND r.category_id #{categoryId} /if if testkeyword ! null and keyword ! AND (r.route_name LIKE CONCAT(%, #{keyword}, %) OR r.destination LIKE CONCAT(%, #{keyword}, %)) /if if testminPrice ! null AND r.price gt; #{minPrice} /if if testmaxPrice ! null AND r.price lt; #{maxPrice} /if if testdepartCity ! null and departCity ! AND r.depart_city #{departCity} /if /where ORDER BY r.create_time DESC LIMIT #{offset}, #{pageSize} /select注意XML中的if标签会自动拼接条件where标签会自动处理掉第一个条件前面多余的AND。这个特性非常实用几个条件任意组合无论传不传参数生成的SQL都是合法的。gt;和lt;是XML中大于等于和小于等于的转义写法初学者经常因为这个报错我在这里先打个预防针。分页这里没有引入PageHelper插件而是直接手写LIMIT。原因很简单——查询参数里带上offset和pageSizeController层根据页码计算偏移量总共就两行代码的事。PageHelper在多表查询、动态SQL组合时偶尔会出现COUNT语句异常为了一个分页功能引入一个插件反而增加了不确定性。4.4 订单创建事务、库存校验与幂等处理订单创建是后端最核心的业务方法因为它涉及多个数据操作必须保证原子性——要么全部成功要么全部失败。Spring的Transactional就是干这个的。Transactional(rollbackFor Exception.class) Override public OrderVO createOrder(OrderCreateDTO dto, Long userId) { // 1. 校验线路是否存在且已上架 Route route routeMapper.selectById(dto.getRouteId()); if (route null || route.getStatus() ! 1) { throw new BizException(线路不存在或已下架); } // 2. 生成订单编号并计算金额 String orderNo TOUR System.currentTimeMillis() RandomUtil.randomNumbers(4); BigDecimal totalPrice route.getPrice() .multiply(BigDecimal.valueOf(dto.getPersonCount())); // 3. 插入订单记录 Order order new Order(); order.setOrderNo(orderNo); order.setUserId(userId); order.setRouteId(route.getId()); order.setPrice(route.getPrice()); order.setPersonCount(dto.getPersonCount()); order.setTotalPrice(totalPrice); order.setStatus(0); order.setTravelDate(dto.getTravelDate()); orderMapper.insert(order); return OrderVO.from(order); }这个方法的三个关键点值得单独说明。事务注解上一定要写rollbackFor Exception.class因为Spring事务默认只对RuntimeException回滚如果业务代码里抛出的是自定义的受检异常不加这个参数事务就不会回滚这是一个非常经典的坑。库存校验这里因为旅游线路不像实物商品有严格的扣减库存操作但max_people这个字段可以用于校验出行人数是否超过上限。更精细的并发控制可以通过对订单表按线路维度加锁实现课程设计级别做到这里已经够用。幂等性方面前端在用户点击下单时做了按钮防重复提交后端通过order_no的唯一索引兜底同样一个请求如果因为网络重发而执行两次第二次会因唯一键冲突报错由全局异常处理器返回友好的提示信息。5. Vue前端的关键设计页面组织与接口对接前端部分我这套系统用的是Vue3Element Plus工程结构按Vite标准模板来组织。下面挑几个对整体架构影响最大的点来讲。5.1 前端项目的目录结构与路由设计src/ ├── api/ # 接口请求统一封装 │ ├── auth.js # 登录注册相关接口 │ ├── route.js # 线路相关接口 │ └── order.js # 订单相关接口 ├── components/ # 通用组件 │ ├── RouteCard.vue # 线路卡片组件 │ └── CommentList.vue ├── router/ # 路由配置 ├── store/ # Pinia状态管理 ├── views/ # 页面组件 │ ├── homepage/ # 首页 │ ├── route/ # 线路列表和详情 │ ├── order/ # 订单相关页面 │ ├── user/ # 个人中心 │ └── admin/ # 后台管理页面 └── utils/ # 工具函数、axios实例路由这块有一个设计细节用户端和管理端我用路由守卫做了权限隔离。管理端的所有路由都配置了meta: { requiresAdmin: true }在全局前置守卫里读取本地存储的管理员标识没有权限的直接重定向到登录页。用户端页面则是登录后可以访问未登录的用户点击下单按钮时前端弹出提示并引导到登录页。5.2 Axios封装与登录态管理前后端分离架构下前端请求的封装直接决定了联调效率。我在utils/request.js里创建了一个axios实例统一配置了baseURL和请求头。import axios from axios const request axios.create({ baseURL: /api, timeout: 10000 }) // 请求拦截器自动携带token request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) // 响应拦截器统一处理返回码 request.interceptors.response.use( response { const res response.data if (res.code 200) { return res } if (res.code 401) { // token过期清除并跳转登录 localStorage.removeItem(token) router.push(/login) } ElMessage.error(res.message) return Promise.reject(new Error(res.message)) }, error { ElMessage.error(网络请求异常) return Promise.reject(error) } )开发环境下这里有一个非常关键的配置Vite的proxy代理。前端请求地址写成/api开头开发服务器把/api开头的请求代理转发到后端的http://localhost:8080这样就完美绕过了跨域限制。// vite.config.js server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }联调阶段的跨域问题九成都能通过这个代理配置解决不需要在后端写CORS跨域配置。等到生产部署时前端打包成静态文件由后端同一个服务托管也就完全没有跨域问题了。5.3 线路列表页与详情页的实现思路线路列表页的数据流是典型的页面加载就请求接口模式。在onMounted生命周期里调用getRoutePage接口拿到分页数据后渲染线路卡片列表用户选择分类、输入搜索关键字或切换分页时把参数更新到查询条件对象中重新调用接口。一个值得注意的细节是搜索防抖。用户在线路列表页的搜索框里输入关键字时如果没有防抖处理每敲一个字符就会触发一次请求既浪费带宽又给数据库造成压力。我用lodash的debounce方法包了一层输入停顿500毫秒后才会真正发请求体验和性能都能兼顾到。线路详情页的逻辑稍微复杂一点要在onMounted时根据路由参数拿到线路ID并行请求线路详情和该线路的评论列表。页面底部是评论组件用户登录后可以提交评论提交成功后刷新评论列表。收藏按钮的状态则需要根据当前用户是否已收藏该线路来展示这里我在后端接口上做了处理——登录用户访问线路详情接口时会额外返回一个favorited字段标识收藏状态。5.4 管理端页面表格、表单与弹窗的通用模式管理端页面的实现套路非常固定可以说所有的管理页面都是同一个模板的变体。页面结构是顶部搜索区中间表格区底部翻页条操作用弹窗表单来完成。以线路管理页面为例顶部是分类下拉选择、关键字输入框和新增线路按钮。中间表格展示线路的封面、名称、目的地、价格、状态状态列用el-tag来染色上架显示绿色下架显示灰色。操作列放编辑上架/下架删除三个按钮。新增和编辑共用同一个弹窗表单组件内部根据传入的routeId判断是新增还是编辑模式。提交之前先做表单校验比如线路名称不能为空、价格必须是正数校验通过后调用对应的接口。这里最大的收益点在于把表单弹窗抽成独立组件后新增和编辑这两种场景的代码量几乎减半后端功能扩展时前端也容易同步。6. 联调、部署与源码运行指南系统做完了压轴的部分是把整套东西跑起来。前端启动Vite开发服务器后端启动SpringBoot应用各自身边跑得挺欢但真正联调和生产部署阶段有不少坑。我把这些天踩过的坑按出现频率从高到低排个序。6.1 跨域问题在联调阶段的两种处理方式联调阶段最常见的就是跨域报错。前端请求后端接口浏览器的同源策略直接拦截控制台报Access-Control-Allow-Origin相关错误。开发环境我用的是Vite代理方案上文已经提到过。还有一种方式是后端加CORS配置通过CrossOrigin注解或者全局CorsFilter来处理。两种方案各有利弊Vite代理在前端配置开发环境好用但换一个前端框架就得重新配置后端CORS配置对前端透明但生产环境如果前后端同源部署这段配置就失去了意义。我的建议是开发环境优先用前端代理生产环境用同源部署。前后端分离只是一种开发模式不代表生产环境必须分成两个服务来跑。6.2 MyBatis实践中踩过的真实坑第一个是动态SQL的if中test条件的字段名要和Java实体类属性名一致而不是和数据库列名一致。比如数据库列名是route_name实体类属性是routeName那么在test里应该写routeName ! null但SQL片段里用的是#{routeName}对应的列。如果你在test里写了route_name ! null运行时会直接报反射异常。这个问题排查起来非常隐蔽因为错误信息不会精确提示到到底是哪个标签出了问题。第二个是批量插入或者批量更新时MySQL连接串上要加allowMultiQueriestrue参数否则MyBatis的foreach标签生成的多条SQL会被MySQL直接拒绝。如果系统里要做收藏列表的批量删除这个参数是必须的。第三个是日期类型。Java的LocalDateTime与MySQL的DATETIME类型直接映射没问题但如果数据库字段用的是TIMESTAMP且MySQL版本为5.7以上插入时会受time_zone配置影响出现差8小时的情况。最简单的方案是统一用DATETIMEJava侧统一用LocalDateTime从项目一开始就把这个规范定下来后续不会有任何时区相关的幺蛾子。6.3 生产部署的最小可行方案生产环境部署这套项目最省事的方案是把前端构建产物交给后端托管。前端执行npm run build生成dist目录把dist目录整体复制到SpringBoot项目的src/main/resources/static下然后重新打包后端。SpringBoot内嵌Tomcat会自动把static目录下的内容当作静态资源提供给外部访问这样生产环境只有一个jar包一个进程部署成本最低。后端打包有一点提醒MyBatis的XML文件虽然写在src/main/resources/mapper目录下但如果你把Mapper接口和XML文件放到了同一个包目录下即src/main/java下打包时要检查pom.xml的build配置里是否包含了**/*.xml资源否则SpringBoot jar包里的mapper XML不会被打进去运行时会报Invalid bound statement (not found)错误。6.4 拿到完整源码后的启动顺序与配置检查项如果你拿到的源码整体结构和我描述的这套一致启动步骤基本就三步。第一步是准备环境安装JDK、Maven、MySQL、Node.js。JDK版本建议用1.8或11SpringBoot版本如果是2.x系列JDK8完全够用如果SpringBoot是3.xJDK17才能跑起来这个一定要看清。第二步是初始化数据库。在MySQL中创建数据库执行项目里提供的init.sql脚本把表结构和基础数据建出来。然后修改后端application.yml中的数据库连接信息把用户名、密码改成你自己的。第三步是分别启动前后端。前端需要先执行npm install安装依赖再执行npm run dev启动开发服务器。后端用IDEA打开Maven项目等待依赖下载完成后直接运行主类。两个服务都起来之后前端访问本地服务端口登录页面能正常跳转说明整套系统已经跑通了。结尾跑完一遍之后的个人体会这套旅游管理系统做完之后我的一个很深的体会是所谓完整源码真正的价值其实不在代码本身而在代码背后的那一串决策过程。为什么订单表要冗余线路价格为什么外键约束能不用就不用为什么动态SQL比拼接字符串更可靠为什么前端请求要统一走拦截器——这些决策如果只是照着代码敲一遍是体会不到的。把它们逐条理清楚哪怕后面换一个完全不同领域的项目这套设计思路照样能复用。最后再分享一个小技巧。如果后续想给这个系统做扩展优先考虑加一个攻略文章模块或者评分细化功能这两类功能对旅游系统的用户粘性提升很明显而且技术难度都控制在现有架构能承受的范围内。表结构上无非就是再增加一张攻略表或者给评论表加几个评分子段后端接口、前端页面直接复用现有的模式迭代成本很低。一个项目做到能低成本扩展的状态才算是真正收尾了。