作为一名计算机专业的学生毕业设计是检验学习成果的重要一环。我选择了“旅游网站”这个既有实际应用场景又充满挑战的课题。在实践过程中我发现很多同学的项目都存在一些共性问题比如代码结构混乱、前后端职责不清、缺乏基本的安全意识等。今天我就把自己从零开始构建一个高可用前后端分离架构旅游网站的技术实践过程记录下来希望能给正在或即将做类似项目的同学一些启发。1. 背景与常见痛点分析为什么你的项目看起来“不专业”在开始动手之前我们先来审视一下学生项目中普遍存在的几个“痛点”。这些问题往往导致项目虽然功能实现了但代码质量、可维护性和安全性都堪忧。硬编码与配置混乱数据库连接字符串、API密钥、文件上传路径等敏感或易变信息直接写在代码里。这导致环境切换开发、测试、生产极其麻烦且存在安全风险。缺乏分页与性能考量在查询景点列表或订单历史时一次性从数据库拉取全部数据当数据量稍大时页面加载缓慢甚至导致服务器内存溢出。SQL注入风险在后端接口中直接使用字符串拼接的方式来构造SQL语句这是非常危险的做法攻击者可以轻易篡改数据库。前后端高度耦合JSP、Thymeleaf等模板引擎虽然能快速出页面但前后端逻辑交织不利于团队协作和后期维护也无法适应多端Web、小程序、App的需求。无状态管理与认证薄弱用户登录状态用Session存储在服务器内存难以扩展或者简单判断用户名密码后就认为登录成功缺乏Token机制无法实现安全的API调用。认识到这些问题是迈向“工程化”开发的第一步。我的目标就是构建一个能规避这些痛点、结构清晰、易于扩展的原型系统。2. 技术选型没有最好只有最适合技术选型是项目的基石。我的核心原则是生态成熟、学习曲线平缓、社区活跃。以下是我的对比与选择前端框架Vue 3 vs ReactVue 3我最终选择了Vue 3。其组合式APIComposition API逻辑组织更灵活尤其适合复杂组件的开发。单文件组件.vue将模板、逻辑、样式集中管理直观清晰。对于从jQuery或原生JS过渡的同学来说Vue的模板语法更易上手。配合Vite构建工具开发时的冷启动速度极快体验非常好。生态方面Vue Router、Pinia状态管理、Element PlusUI库构成了完整的开发套件。React功能强大生态极其繁荣但JSX语法和函数式编程的思想可能需要更长的适应时间。对于追求极致灵活性和大型应用架构的同学React是更优选择。后端框架Spring Boot vs DjangoSpring Boot我选择了Java生态的Spring Boot。理由是其“约定大于配置”的理念极大地简化了Spring应用的初始搭建和开发过程。它拥有无与伦比的企业级开发生态从数据访问Spring Data JPA/MyBatis、安全Spring Security、缓存到消息队列都有成熟的解决方案。这对于需要体现技术深度的毕业设计来说是个加分项。DjangoPython的Django是“开箱即用”的典范自带Admin后台、ORM、用户认证等开发效率极高。如果团队更熟悉Python或者项目对开发速度要求极高Django是很好的选择。数据库MySQL vs MongoDBMySQL作为成熟的关系型数据库我选择了MySQL来存储用户、景点、订单这类关联性强、需要事务支持如创建订单时扣减库存、更新用户余额的核心数据。其ACID特性保证了数据的一致性。MongoDB对于景点详情中可能存在的富文本描述、多图列表、不规则的用户评论等非结构化或半结构化数据文档型数据库MongoDB更有优势。但在本次原型中为了简化架构我选择用MySQL的TEXT或JSON类型字段来应对未来可考虑引入MongoDB作为补充。最终技术栈Vue 3 Vite Pinia Element Plus (前端) / Spring Boot Spring Security JWT MyBatis-Plus MySQL Redis (后端)。3. 核心实现细节拆解确定了技术栈接下来就是核心功能的实现。我着重设计了三个有代表性的模块。1. 用户认证与授权JWT实践为了避免Session扩展性问题采用无状态的JWTJSON Web Token方案。用户登录时后端验证用户名密码后使用密钥务必从配置文件中读取不要硬编码生成一个JWT Token其中包含用户ID、角色等信息。将Token返回给前端前端将其存储在localStorage或Cookie中需注意XSS和CSRF防护。前端在后续请求的Authorizationheader中携带此Token。后端通过Spring Security的过滤器链拦截需要认证的请求验证Token的签名和有效期并从中提取用户信息存入SecurityContext供后续业务逻辑使用。 这样实现了前后端的完全解耦后端服务可以轻松横向扩展。2. 景点分页查询MyBatis-Plus助力这是解决“一次性拉取所有数据”痛点的关键。我使用MyBatis-Plus的内置分页插件非常简洁。前端请求参数包含pageNum当前页码和pageSize每页条数。后端Controller接收参数构造一个Page对象。在Service层调用MyBatis-Plus的page(page, queryWrapper)方法其中queryWrapper可以动态添加查询条件如按城市、景点类型筛选。返回的Page对象不仅包含当前页的数据列表还有总记录数、总页数等信息前端可以据此渲染分页器。3. 订单状态机设计保证业务逻辑清晰订单的生命周期如待支付、已支付、已取消、已完成是业务核心。我采用状态模式State Pattern的思想来设计。在数据库中订单有一个status字段。在代码中我定义了一个OrderStatusEnum枚举明确所有状态。更重要的是我定义了一个OrderService的方法如cancelOrder(orderId)在这个方法内部会校验当前订单状态是否允许取消例如已支付的订单可能需要走退款流程才能取消而不能直接取消。所有状态变更都必须通过这些明确的Service方法而不是随意地直接更新数据库字段。这有效防止了状态混乱是处理业务逻辑中并发竞争比如用户同时点击取消和支付的基础。4. 关键代码示例遵循Clean Code这里展示后端用户登录和景点分页查询的核心代码片段注重可读性和简洁性。用户登录Controller与Service// AuthController.java RestController RequestMapping(/api/auth) public class AuthController { Autowired private AuthService authService; PostMapping(/login) public ResultVOString login(Valid RequestBody LoginDTO loginDTO) { // Valid 注解自动校验LoginDTO的约束如NotBlank String token authService.login(loginDTO.getUsername(), loginDTO.getPassword()); return ResultVO.success(登录成功, token); // 统一封装返回结果 } } // AuthService.java Service public class AuthService { Autowired private UserMapper userMapper; Autowired private PasswordEncoder passwordEncoder; // Spring Security的密码加密器 Autowired private JwtTokenProvider jwtTokenProvider; // 自定义的JWT工具类 public String login(String username, String rawPassword) { // 1. 根据用户名查询用户 User user userMapper.selectOne(new QueryWrapperUser().eq(username, username)); if (user null) { throw new BusinessException(用户名或密码错误); // 自定义业务异常 } // 2. 校验密码数据库存储的是加密后的密码 if (!passwordEncoder.matches(rawPassword, user.getPassword())) { throw new BusinessException(用户名或密码错误); } // 3. 生成JWT Token return jwtTokenProvider.generateToken(user.getId(), user.getRole()); } }景点分页查询Controller与Service// ScenicSpotController.java RestController RequestMapping(/api/scenic-spots) public class ScenicSpotController { Autowired private ScenicSpotService scenicSpotService; GetMapping public ResultVOPageVOScenicSpotVO listSpots( RequestParam(defaultValue 1) Integer pageNum, RequestParam(defaultValue 10) Integer pageSize, RequestParam(required false) String city) { PageVOScenicSpotVO page scenicSpotService.getSpotsByPage(pageNum, pageSize, city); return ResultVO.success(page); } } // ScenicSpotServiceImpl.java Service public class ScenicSpotServiceImpl implements ScenicSpotService { Autowired private ScenicSpotMapper scenicSpotMapper; Override public PageVOScenicSpotVO getSpotsByPage(Integer pageNum, Integer pageSize, String city) { // 1. 构建分页对象 PageScenicSpot page new Page(pageNum, pageSize); // 2. 构建查询条件 QueryWrapperScenicSpot queryWrapper new QueryWrapper(); queryWrapper.eq(is_deleted, 0); // 逻辑删除过滤 if (StringUtils.hasText(city)) { queryWrapper.like(city, city); // 城市模糊查询 } queryWrapper.orderByDesc(create_time); // 按创建时间倒序 // 3. 执行分页查询 PageScenicSpot spotPage scenicSpotMapper.selectPage(page, queryWrapper); // 4. 将实体Page转换为包含VO的PageVO进行数据脱敏或格式化 return PageVO.convert(spotPage, this::convertToVO); } private ScenicSpotVO convertToVO(ScenicSpot spot) { // 将ScenicSpot实体转换为前端需要的ScenicSpotVO例如处理图片URL等 ScenicSpotVO vo new ScenicSpotVO(); BeanUtils.copyProperties(spot, vo); // ... 其他转换逻辑 return vo; } }5. 性能与安全考量让项目更健壮实现功能只是第一步让项目健壮、安全、高效同样重要。接口幂等性处理对于创建订单、支付回调等关键接口必须防止用户重复提交。我采用的方案是前端在提交时禁用按钮后端利用Redis实现Token机制。提交前先从后端获取一个唯一Token提交时连同业务参数一起发送后端校验该Token是否存在且未使用校验成功后删除Token确保同一Token只能成功请求一次。XSS防护用户输入的景点评论、个人简介等内容如果直接输出到HTML页面存在XSS风险。我的处理是后端在存储时进行校验和过滤可以使用Jsoup等库前端在Vue中默认的数据绑定{{ }}和v-html指令也会进行转义。对于确实需要富文本的场景严格限定白名单标签。JWT安全配置密钥强度使用足够长且复杂的密钥并存储在环境变量或配置中心。有效期设置合理的Token过期时间如2小时并搭配Refresh Token机制实现无感刷新。存储安全前端避免将Token放在容易被XSS攻击获取的localStorage可以考虑放在HttpOnly的Cookie中但需处理好CSRF防护。注销问题由于JWT无状态服务端无法直接使其失效。我采用“黑名单”策略将需要提前注销的Token ID存入Redis并设置短于Token有效期的过期时间在验证Token时额外检查黑名单。6. 生产环境避坑指南从本地开发到部署上线还有不少坑要跨过。环境差异使用application.yml配合spring.profiles.active来管理不同环境dev, test, prod的配置。数据库地址、Redis连接、文件存储路径等全部配置化。可以使用Docker统一开发、测试、生产环境。静态资源缓存Vite打包后的CSS、JS文件带有哈希值可以配置Web服务器如Nginx对这些文件设置长期缓存如1年。同时要为index.html设置no-cache或较短的缓存时间以确保用户能获取到最新的页面入口。日志记录规范不要再用System.out.println()了。使用SLF4J Logback通过Slf4j注解记录日志。区分日志级别ERROR, WARN, INFO, DEBUG在application.yml中按环境配置输出级别和格式。关键业务节点如用户登录、订单创建成功/失败务必记录INFO日志异常处必须记录ERROR日志并打印堆栈方便线上排查。数据库连接池默认的HikariCP配置可能不适合生产环境。需要根据实际并发量调整maximum-pool-size、connection-timeout等参数。前端路由History模式Vue Router使用history模式时需要后端配置如Spring Boot中配置ErrorController将所有非API请求转发到index.html否则刷新页面会出现404。总结与思考通过这样一个从零开始的实践我不仅完成了一个功能完整的旅游网站毕业设计更重要的是初步建立了工程化、系统化的开发思维。从需求分析、技术选型、模块设计、编码实现到性能安全优化每一步都加深了对现代Web开发全流程的理解。这个单体架构的原型已经具备了清晰的分层和模块化。那么如何将它演进为一个更强大、更灵活的系统呢一个自然的思考方向是微服务架构。例如当网站需要接入多个独立的旅行社或景点供应商时服务拆分可以将“用户中心”、“景点服务”、“订单服务”、“支付服务”拆分为独立的微服务。API网关引入Gateway作为统一入口处理路由、认证、限流、监控。服务通信服务间通过REST API或轻量级RPC如gRPC、Dubbo进行通信。配置与注册中心使用Nacos或Consul来管理服务发现和动态配置。数据一致性跨服务的订单创建涉及“景点服务”库存和“订单服务”需要引入分布式事务解决方案如Seata或最终一致性模式如基于消息队列。这将是另一个充满挑战但也极具价值的学习方向。希望我的这份实践笔记能为你点亮毕业设计路上的一盏小灯。