基于Spring Boot和Vue 3的智慧旅游网站：住宿预订、行程规划与千问接入

旅游网站里的景点列表很直观，真正需要设计的是列表之后的流程：用户连续住两晚，系统如何确认每晚都有房；计划调整以后，预算和时间是否还成立；订单完成后，谁有资格评价。「山海之间·智慧旅游」围绕这些问题，将资源搜索、门票与住宿预订、商家履约和智慧辅助连接起来。

如果你希望了解这套项目的源码、运行说明和配套论文如何交付，可以先看蓝象毕设工作室官网。咨询注明「山海之间·智慧旅游」，并说明想保留或改造的功能，便于按实际项目范围沟通。

从一个用户的旅行过程看功能

用户先搜索景点或住宿，通过城市、分类、价格等条件缩小范围，进入详情确认服务内容。预订住宿时选择入住、离店日期和房型；预订门票时选择产品与服务日期。订单创建后可以进行教学模拟支付，随后由商家核销门票，或办理住宿入住和退房。完成后的订单进入可评价状态，评价与真实的站内订单关联。

上图是用户侧景点搜索页。筛选区域与资源卡片同时呈现，用户可以从条件选择直接进入详情。它体现前台的搜索入口与展示效果；卡片背后的可售产品、日期库存和订单约束，则由后端继续处理。

除了正常完成，系统还处理取消、待支付过期与符合规则的退款申请。商家在工作台处理自己的资源和订单，管理员维护平台规则并审核攻略。角色区别落实到后端的数据归属校验，不只体现在菜单有没有显示。

角色	主要操作	需要守住的边界
用户	搜索、收藏、预订、行程编辑、评价与攻略	自己的订单、行程与内容
商家	产品与日期库存、订单履约、退款处理	所属资源和订单
管理员	平台审核、规则与资源管理	管理权限仍需遵守业务状态

技术结构与数据组织

系统采用Spring Boot、Vue 3和MySQL。前端负责路由、表单、结果展示和状态反馈；后端集中处理身份、归属、事务、计算和千问访问；数据库保存资源、产品、日期库存、订单及智慧模块数据。旅游业务中的数据访问主要使用JdbcTemplate与参数化SQL，不能简单把工程底座的依赖列表当成每个模块的实际实现。

架构图依据项目代码绘制。模型调用被放在后端适配服务中，凭证不需要下发给浏览器；订单与智慧计算仍有独立职责，外部服务异常不会改变库存校验应该在哪里执行。

数据设计中，需要区分三个层次：资源是景点或住宿，产品是票型或房型，日期库存是某个产品某天的价格与可售量。如果只在酒店表里放一个"剩余房间数"，就无法准确回答"今天有房、明天售罄"的连续住宿问题。

住宿预订为什么需要事务

假设用户预订10月10日入住、10月12日离店的一间房，需要占用10日和11日两晚。后端逐晚读取可售数量并形成价格快照，离店日不计入住宿夜晚。如果其中一晚不足，整个订单创建过程回滚，不能留下"没有订单却占了第一晚房间"的数据。

用户在上图右侧选择日期与房间条件。界面将住宿介绍与预订操作放在一起，后台则把一次提交展开为多个服务日的库存检查。页面的连贯体验，依赖服务端把这些跨日期操作统一处理。

库存区分容量、预占和已售：待支付订单先增加预占；模拟支付成功后，将对应数量从预占转为已售；取消和过期释放预占；批准退款后恢复已售数量。请求键用于识别重复创建，金额由后端重新计算。按钮禁用可以改善操作体验，事务和幂等才覆盖网络重试等情况。

订单还保存重要事件，用于解释状态何时发生变化。评价检查订单是否属于当前用户、是否已经完成，并限制每个订单只评价一次。这些关联规则比单独增加几个管理表单更能体现工程工作量。

智慧规划如何产生可检查的结果

推荐先排除日期、库存、开放时间或容量不满足的候选，再按兴趣、预算适配、评分和热度组合排序，返回对应理由。行程规划采用受约束的贪心插入，并做有限的日内交换尝试减少绕行。用户可以调顺序、增删景点和单日重排，但修改后必须重新校验。

这张图来自项目已有智慧模块验收素材，展示条件表单、门票住宿合计、预算余量以及逐站时间线。它是算法结果页的运行证据，与后面加入千问入口的界面属于不同阶段素材。图中1306元对应当次浏览器条件，不应与另一组隔离测试输入得到的1366元混为一组实验。

当前预算只统计门票与住宿；交通使用坐标距离和固定速度估算，不是实时地图导航。保存行程不锁定库存，进入具体产品预订时还要检查当前可售情况。把这些边界说清楚，用户才能理解一个计划与一笔有效订单的差别。

千问接在哪里

千问有两个主要入口。对于旅行需求，模型提取城市、日期、人数、预算和偏好，后端检查后交给原有行程服务计算。对于站内攻略问题，后端先检索已发布资源和攻略，把有限来源交给模型组织回答，并检查引用编号是否属于本次资料。

上图保留千问功能的完整区域，包括输入、回答和站内来源。它展示了模型已经真实响应，并能给出资料回查入口。当前检索使用关键词与SQL，没有训练专用模型或部署向量数据库；来源编号检查也不等于每句话都已被机器证明准确。

自然语言入口和普通表单共享行程服务，因此不会出现一套由表单检查预算、另一套让模型直接决定成交的规则。云端配置或调用异常时，用户仍可使用结构化条件规划。

如何运行和验证

运行顺序是MySQL、后端、前端。新环境按项目启动文档初始化数据库并执行智慧增量迁移；已有数据库先确认用途，不能重复覆盖。配置数据库连接和后端模型凭证后，可在后端目录使用Maven Wrapper启动开发服务：

powershell 复制代码

cd backend-java-springboot
.\mvnw.cmd spring-boot:run

依赖按锁文件安装后，在另一个终端的前端目录运行：

powershell 复制代码

cd frontend-vue3-vben-lite
npm run dev -- --host 127.0.0.1 --port 5178

本项目开发入口为 http://127.0.0.1:5178/travel，后端端口为8088。千问配置属于服务端部署项，源码、文章和前端代码中不应包含实际凭证。

验收记录包含26项核心业务、1项真实过期调度与23项智慧规则检查，合计50项，覆盖失败回滚、最后一份库存竞争、角色隔离、行程约束和提醒去重等。这个数量不包含后续千问集成测试，也不是压力测试。

配套资料与改造方向

当前项目已有源码、SQL、启动和业务文档、90秒横屏演示，以及可编辑Word论文。论文有效正文约2.17万字，包含数据库、订单事务、推荐与规划算法、千问接入和真实测试结果。具体使用者的学校封面、纸型和目录格式可按模板继续适配。

想了解交付方式，可以在官网咨询「山海之间·智慧旅游」。建议带着想改的需求沟通，例如接入真实支付、使用地图路线、支持不同日期更换酒店，先区分现有能力与扩展工作。

这套实现适合从旅游服务、日期库存、订单状态和AI辅助决策几个方向继续研究。当前提供的是教学模拟支付和演示资源，地图、支付对账、大规模压力与问答质量评测仍属于进一步完善的范围。