智旅旅行

一句话定位

智旅旅行是覆盖路线推荐、酒店和门票预订、订单管理、地图及旅游问答的 Java Web 演示系统。它把出行前的规划与预订放在同一条体验路径中，并提供管理员维护入口。

用户与问题

游客需要根据目的地、预算、天数和兴趣看路线及费用，再查看景点位置、选择住宿或门票并管理订单。管理员需要维护前台展示的资源和订单。项目的产品价值是演示从发现到下单的完整流程，不是证明真实旅游业务的转化效果。

范围选择

当前范围	对用户的结果	明确边界
路线和地图	查看每日安排、预算拆分和景点位置	没有高德 Key 时使用点位列表
酒店、门票和订单	创建、取消、模拟支付、评价	不连接资金渠道或履约系统
旅游问答	基于站内资料检索回答	外部模型默认关闭
后台管理	维护资源和查看订单	不含多商家入驻与结算

当前完成度

游客端、管理员端与本地部署材料已在仓库中。门票库存采用带条件的更新约束下单数量；酒店房态还需考虑入住日期区间。订单显示“已支付”仅表示本地模拟状态变化，不代表真实付款或退款。仓库没有自动测试目录，也没有真实用户行为数据，当前定位为教学和作品集演示项目。

演示路径：推荐到订单回查

我使用独立 MySQL 演示库和 Tomcat，沿同一条旅程完成路线选择、酒店预订、订单创建与本地模拟支付。图片来自实际运行的页面；未接入真实支付、高德地图 Key 或外部模型。

01 输入条件并比较路线

操作：输入厦门到上海、预算 1588 元、3 天及“美食夜景”。核查：页面给出两种预算的路线，拆出交通、住宿、景点门票及预留费用，用户可继续进入商品页。

02 选房并核对价格

操作：进入酒店预订，选中目标房型与入住区间。核查：房态、入住日期和预计价格在提交前可见。

03 比较景点和票种

操作：按城市查询景点，进入门票入口。核查：查询返回上海景点及票种，供行程预算比较；本次订单选择酒店，没有创建门票订单。

04 创建订单

操作：提交选中的酒店房型。核查：我的订单出现酒店订单 #1，金额 1456 元，状态为“待支付”。

05 执行本地模拟支付

操作：点击支付订单。核查：同一订单 #1 变为“已支付”；这是数据库状态变更，没有真实资金流。

06 后台回查同一记录

操作：管理员进入订单管理。核查：后台查到酒店订单 #1，用户、酒店、金额和已支付状态与前台一致。本次只查看后台，未再次修改订单状态。

异常路径与边界

库存不足、取消后库存恢复和并发防超卖仍需专门的连续操作与数据核验，本页截图只展示成功路径。未配置高德 Key 时可查看点位列表；外部模型关闭时问答走本地检索。支付为模拟状态变更，不能当作真实支付集成成果。

场景与目标

智旅旅行把路线、住宿、门票和订单放在同一套演示系统中。游客从目的地、预算、天数和兴趣出发，查看每日行程和费用拆分，选择酒店或门票后创建订单；管理员维护可展示和可预订的资源。

用户	需要完成的任务	系统反馈
游客	找到路线与景点	日程、预算、地图位置或点位列表
预订用户	选择房型或票种并下单	价格、库存或房态、订单状态
管理员	维护景点、路线、酒店、门票和订单	列表、编辑结果和订单状态

核心流程

路线推荐展示游玩顺序、每日安排和费用拆分；酒店与门票选择会带入下单信息。新订单初始为 CREATED，可取消或执行本地模拟支付，模拟支付后为 PAID，已支付订单可评价。页面上的“支付”不连接真实资金渠道。

关键规则

• 门票库存不足时不得创建成功订单；库存扣减使用带库存条件的更新，取消时要恢复相应库存。
• 酒店房态取决于入住日期区间，不能用单一库存数字代替日期占用检查。
• 地图依赖高德 Key；未配置时仍应提供点位列表。旅游问答默认基于本地项目资料检索，外部模型是可选配置。
• 后台资源维护与前台展示需要保持一致；本项目不处理商家结算、真实支付退款和履约客服。

验收与限制

用一组演示数据贯通路线查看、门票或酒店下单、模拟支付、订单查询和管理员查看。另用库存为 1 的票种展示售罄与取消后恢复。仓库没有自动测试目录，当前只可依据源码、部署材料和手工演示说明判断功能范围；没有真实用户转化或高并发验证。

比较范围

智旅旅行是教学与作品集演示项目。这里比较三类旅游产品形态的用户任务，不对具体 OTA 或规划产品的现行功能做未经实测的断言。

形态	用户主要任务	对本项目的启发	本项目当前差距
在线旅游预订平台	比较商品、下单和管理行程	订单状态、库存和后台资源应连贯	无真实支付、履约、客服及商家结算
行程规划工具	根据目的地和偏好安排行程	每日计划和预算要能解释推荐结果	未验证推荐质量和个性化效果
旅游问答工具	快速查目的地或订单规则	回答应连接站内路线与商品信息	本地资料覆盖有限，没有真实问答质量评测

本项目的定位

项目把三类任务放在一条可演示的路径里：先规划，再查看地图和商品，最后管理订单。这有利于展示前后台数据流和业务边界，但功能覆盖广不等于已经具备真实平台的供给、服务与交易能力。

下一步验证

若要走向真实产品，应先验证用户能否从推荐结果理解预算与路线、能否准确判断房态和票种、下单失败时是否知道原因，再补支付、履约和客服规则。当前没有同场景用户测试或竞品实测数据，不作优劣排名。

技术结构

系统采用 Spring、Spring MVC、MyBatis、JSP、MySQL 和 Tomcat 9。Controller 接收前台与后台请求，Service 处理认证、路线、预订、订单和问答，Mapper 访问数据库；Maven 构建 WAR。配置通过环境变量注入数据库、地图和外部模型参数，本地示例脚本负责打包和部署。

订单与库存

门票下单时，TicketMapper.xml 使用 UPDATE ticket SET stock = stock - quantity WHERE id = ... AND stock >= quantity；Service 检查受影响行数，并在同一事务中写入订单。酒店房型也有条件扣减，入住日期区间的房态还需要参考重叠订单。取消订单时状态变化和库存恢复应在事务内完成，避免只取消订单却不返还可售数量。

模拟支付将符合条件的订单由待支付状态改为已支付，不调用第三方支付接口。当前没有支付回调验签、资金对账、真实退款或超时关单的验证，因此代码中的 PAID 只代表本地业务状态。订单状态与数据库事务的实现不能替代真实支付链路。

地图与问答

地图使用高德 Web JavaScript API，缺少 Key 时页面显示降级提示并保留点位列表。AI 行程助手默认从本地旅游资料检索，外部大模型由环境变量显式启用。两类外部依赖都不应成为本地演示主流程的硬前提。

验证与限制

仓库有游客端、管理员端、部署说明与演示账号，但当前没有 src/test 自动测试目录。条件更新和事务说明了实现意图，尚缺并发争抢最后一张票、重复支付/取消、事务回滚和酒店跨日期预订的集成测试；也没有真实支付或生产负载验收。适合作为业务流程演示，不能据此声明生产级预订能力。

已确认的取舍

系统把“推荐、预订、模拟支付、评价、后台维护”放在同一套 SSM 应用里，便于展示数据如何贯穿业务流程。这个范围覆盖了主要页面与订单状态，却没有真实支付渠道及其回调、退款对账。页面上的“支付成功”是本地订单状态变化，不能解释为资金已结算。

门票扣减使用带 stock >= quantity 条件的单条更新，并把扣减与订单插入置于事务中。它解决了这条写入路径上“先读库存、随后被其他请求抢走”的问题；酒店房态还涉及入住日期区间与已锁定订单，不能直接套用单日门票的库存模型。

最需要补的证据

仓库目前没有自动测试目录。尤其缺少两个并发请求争抢最后一张票、重复支付/取消、事务中途失败后库存回滚，以及酒店跨日期库存的集成测试。因此文档只能说明代码采用了哪些保护措施，不能宣称已经完成压力或故障验收。

如果继续维护，第一步是在临时 MySQL 上给订单服务补集成测试，固定库存、订单与状态的不变量。第二步再加入超时关单和外部支付回调的幂等处理；没有支付网关前，仍明确标注“模拟支付”。