线上旅游体验系统这个题目，这几年在不少课程设计和毕业设计里都能看到。我最近刚好完整实现了一个基于Java+SSM+Flask的版本，从数据库设计到后端接口再到前端页面全部自己搭，前后折腾了大概三周。简单说，这套系统把景点展示、线路规划、虚拟体验、在线预订、订单管理这些功能串在一起，用户可以像逛旅行平台一样浏览目的地、看全景素材、收藏线路，然后直接下单。对正在做相关项目的同学来说，这套组合尤其值得参考：SSM负责核心业务，Flask负责推荐和虚拟体验接口，两种技术栈在一个项目里协同工作，既能体现Java后端的扎实，又能展现Python生态的灵活。
1. 项目整体思路与功能拆解
1.1 为什么做线上旅游体验系统
线上旅游体验系统解决的问题很实在：用户在下单前，往往只能通过几张图片和一段介绍来判断目的地，决策成本高，实际到了现场又容易“图片与实物不符”。把旅游体验搬到线上，本质上是给用户提供一个更加立体的“前置感知层”。
我在设计时，把整个链路拆成“决策-体验-预订-服务”四个环节。决策环节靠景点检索和线路推荐，体验环节靠全景素材和短视频，预订环节靠标准的订单流程，服务环节靠评论和售后状态管理。这四个环节不是孤立的，而是共享同一套用户账号体系和数据库。比如用户看了某个景点的虚拟体验视频并标记“想去”，系统就会记录这个行为标签，后续做线路推荐时优先展示相似主题的线路。
这次项目的核心目标，并不是做一个纯展示类的旅游信息网站，而是做成一个具备交易闭环的业务系统。所以功能上既要有内容展示，也要有下单和订单管理，管理员要有审核和统计后台。整体看下来，这套系统可以覆盖旅游平台最基础的业务形态，后续做商业项目也能直接迁移。
1.2 功能模块全景
用户端和管理端的功能划分，我建议在动手前就写清楚，不要边做边加。
用户端核心功能包括：
- 注册登录：手机号或用户名注册，登录后进入个人中心。
- 景点浏览与检索：按城市、分类、关键词、价格区间筛选景点。
- 线路推荐：首页展示热门线路，推荐接口根据用户兴趣动态调整。
- 虚拟体验：景点关联全景图片、短视频、语音讲解，用户可在线体验。
- 收藏管理：收藏景点或线路，方便后续查看。
- 在线预订：选择线路、填写联系人信息、选择出游人数，模拟支付。
- 订单管理：查看订单状态，取消未支付订单，确认收货或申请退款。
- 评论评分：下单并完成行程后，对景点和线路进行评价。
管理端核心功能包括：
- 景点管理：新增、编辑、上下架景点，维护图片视频素材。
- 线路管理：组合景点、设置行程天数与价格、调整推荐权重。
- 订单管理：查看所有订单，处理退款申请，调整订单状态。
- 用户管理：启用或禁用账号，查看用户行为记录。
- 数据统计：统计景点浏览量、订单量、热门目的地排行。
这个模块清单看起来不少，但实际落地时每块都不算特别复杂。关键是表结构要先设计好，否则做到后面容易返工。
1.3 为什么选SSM+Flask双后端
标题里有Java+SSM，又有Flask，这不是为了堆技术栈，而是有实际分工考虑的。SSM最适合写强业务逻辑：用户、订单、库存、支付状态机，这些都需要明确的事务边界和类型约束。Spring管理Bean和事务，SpringMVC处理路由分发，MyBatis和数据库打交道，每个层次职责都很清楚，排查问题相对容易。
Flask则适合做灵活度高的辅助服务。比如我的推荐模块，需要读取用户行为数据，计算标签相似度，输出候选线路。用Python写一个简单的协同过滤，代码量只有Java版本的三分之一左右。虚拟体验模块也需要频繁处理JSON格式的体验日志，Python处理字典和JSON非常顺手。
所以最终架构就定成“主业务在SSM，推荐和体验服务在Flask”。两个后端之间通过HTTP接口通信，SSM是主入口，Flask相当于一个独立微服务。这样的结构还有一个好处：以后想换推荐算法、或者把Flask替换成其他Python服务，都不影响主流程。
2. 技术栈与核心架构解析
2.1 SSM端的组成与分工
SSM可以说是JavaWeb领域最经典的组合之一。Spring负责把业务对象纳入容器管理，同时提供声明式事务；SpringMVC接收浏览器请求，通过HandlerMapping找到对应的Controller；MyBatis把Mapper接口和SQL语句映射起来，返回实体对象。
我在实际编码时，会把代码分成四个层次：Controller只做参数接收和结果包装，Service放业务判断和事务控制，Mapper做数据库操作，Entity对应表结构。比如下单这个操作，Controller接收userId和lineId，Service里面依次做参数校验、线路库存检查、生成订单号、插入订单记录、扣减库存，任何一步失败整个事务回滚。
Spring和SpringMVC的配置我习惯用JavaConfig和XML混合的方式。Spring管理数据源、事务管理器、Mapper扫描，SpringMVC管理控制器、视图解析器、静态资源。其实项目中前后端以接口为主，视图解析器用得很少，返回体统一用Result对象包装，前端拿到code和data再处理。
2.2 Flask端扮演的角色
Flask在这个项目里主要承担三件事。第一，提供推荐接口。它从数据库读取用户最近的浏览和收藏记录，计算与线路标签的相似度，把TopN结果返回。第二，提供虚拟体验素材聚合接口。景点关联了全景图、视频、音频讲解，Flask读取配置后一次性返回给前端。第三，接收体验日志，比如用户看了多长时间、对哪些景点感兴趣，这类数据写入体验日志表，为推荐提供原始素材。
下面是我在Flask端最核心的一个推荐接口，代码非常简单：
from flask import Flask, request, jsonify import recommend app = Flask(__name__) @app.route('/api/recommend', methods=['POST']) def recommend_lines(): data = request.get_json() user_id = data.get('userId', 0) result = recommend.recommend_by_tags(user_id) return jsonify({'code': 0, 'data': result})这段代码的作用就是把HTTP请求参数转换成用户ID，然后调用纯Python实现的推荐函数，返回JSON列表。它不关心订单事务，也不管权限校验，所以逻辑足够轻量。把这种非核心且变化频繁的逻辑放进Flask，SSM端就不会被算法代码拖累。
2.3 前后端数据交互方式
前端我采用Vue + Element Plus开发，管理端和用户端共用一套工程，通过路由区分。开发环境有两个代理：一个把/api转发到SSM的8080端口，另一个把/flask转发到Flask的5000端口。
// vite.config.js export default { server: { proxy: { '/api': 'http://localhost:8080', '/flask': 'http://localhost:5000' } } }为什么要在开发环境做代理而不是直接跨域请求？因为直接访问不同端口会触发浏览器的CORS限制，每次都要在Java端写跨域配置，麻烦且不安全。开发时用代理，生产时用Nginx统一转发，可以让前后端域名保持一致。
生产环境我建议在Nginx层做路由：/api开头的请求转发给Java服务，/flask开头的请求转发给gunicorn启动的Python服务，静态资源由Nginx直接托管。这样对外只暴露一个入口，浏览器不会发生跨域，安全性也更好控制。
3. 数据库设计与核心表结构
3.1 用户与权限设计
用户表是所有业务的基础，我设计时会避免把角色字段直接存成user.role这种单字段模式。因为系统后续很可能出现普通用户、管理员、导游、商家等多种角色，单字段扩展性太差。这次项目采用经典的多对多角色模型：user表存用户基本信息，role表存角色，user_role表存关联关系。
用户表核心字段包括：
id：主键，自增。username：登录名，唯一索引。password：加密后的密码。salt：加密盐值。nickname：昵称。avatar：头像地址。phone：手机号。email：邮箱。status：账号状态，1正常，0禁用。create_time：注册时间。
密码字段必须使用加盐哈希，不要存明文，也不要只做一次简单MD5。用户可以注册成功，但是密码字段绝对不能裸奔。我在项目里用SHA-256加随机盐，虽然不算最强，但作为课程项目足够示范安全思路。
3.2 景点与线路数据模型
景点表设计的关键点在于素材字段的规划。一个景点往往有主图、短视频、全景图、语音讲解等多个素材，可以都放景点表里，也可以单独拆素材表。规模不大时直接放在景点表更直观。
CREATE TABLE `spot` ( `id` int NOT NULL AUTO_INCREMENT, `name` varchar(100) NOT NULL, `city` varchar(50) DEFAULT '', `category` varchar(50) DEFAULT '', `summary` text, `cover_url` varchar(255) DEFAULT '', `video_url` varchar(255) DEFAULT '', `panorama_url` varchar(255) DEFAULT '', `price` decimal(10,2) DEFAULT 0, `status` int DEFAULT 1, `create_time` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;线路表用于组合多个景点。最简单的做法是用一个spot_ids字段，把景点ID用逗号拼起来，比如“1,3,7”。这种设计适合演示项目，查询时在Java端拆分成数组再逐条查景点信息。如果线路数量很大、景点关联关系复杂，还是建议拆成line_spot中间表。
3.3 订单与评论体系
订单表是交易环节的核心，状态字段最需要谨慎设计。我使用status表示订单状态，整数定义状态机：
- 0：待支付
- 1：已支付
- 2：已完成
- 3：已取消
- 4：已退款
金额字段使用decimal(10,2)，Java端对应BigDecimal，不要用double或float。金额精度问题是很多项目里反复出现的典型坑。一次订单包含联系人、手机号、出游人数、总金额、下单时间、支付时间，字段不多，但中间状态一定要想清楚。
评论表则关联用户、景点、订单三张表。同一个用户对同一个景点只能评论一次，可以通过order_id和user_id建立唯一约束来实现。评分字段我设计为1到5的整数，简单直观，统计均分也方便。
4. 核心模块实现要点
4.1 登录鉴权与会话管理
SSM端登录鉴权，我没有引入Spring Security这种重框架，而是用拦截器加Session的方案。用户登录成功后，把用户ID和用户名放进Session，同时更新最近登录时间。拦截器里写一个HandlerInterceptor，对于需要登录的路径检查Session是否有用户信息，没有就跳转到登录接口并返回未登录提示。
简单Session方案在单机部署下完全够用。不过我还是建议在这一步加入JWT的思路：登录成功后由后端签发一个token，前端存到LocalStorage，请求头里带Authorization字段。服务端通过过滤器解析token，获取用户信息。这样以后做小程序或移动端接口时，直接复用同一套鉴权逻辑。
token里只放用户ID、昵称、过期时间这些必要信息，千万别放密码。我见过有人直接把整个用户对象塞进token，这是完全没有必要的风险。过期时间建议设置短一些，比如30分钟，用户操作时再续期，安全性更高。
4.2 景点检索与线路推荐
景点检索接口要考虑多条件组合。城市、分类、关键词、价格区间都可能为空，MyBatis里用动态SQL来实现：
<select id="searchSpots" resultType="Spot"> select * from spot <where> <if test="city != null and city != ''"> and city = #{city} </if> <if test="category != null and category != ''"> and category = #{category} </if> <if test="keyword != null and keyword != ''"> and (name like concat('%', #{keyword}, '%') or summary like concat('%', #{keyword}, '%')) </if> <if test="minPrice != null"> and price >= #{minPrice} </if> <if test="maxPrice != null"> and price <= #{maxPrice} </if> </where> order by create_time desc </select>线路推荐我放在Flask端实现。思路是将景点的分类和标签转化为特征向量，用户在浏览、收藏、体验过程中产生行为记录，系统把这些行为映射成用户的兴趣向量，再计算兴趣向量与线路向量的余弦相似度。没有行为数据的用户，直接按照销量和评分排序做热门兜底，保证接口一定有返回结果。第一次实现时不要贪多，先做“相似度+热门兜底”就够展示了。
4.3 线上虚拟体验模块实现
虚拟体验模块是这个项目最有辨识度的功能。我采用“全景图+短视频+语音讲解”三种素材配合的方式。用户进入景点详情页后，可以观看全景图，也可以直接播放景点宣传短视频。体验结束后，前端会提交一条体验记录，包含用户ID、景点ID、观看时长、是否点“想去”。
Flask端接收体验记录后，把数据写入experience_log表，同时更新用户的兴趣标签权重。比如用户多次观看“古镇”类景点，那么古镇标签的权重就会增加。这些数据后续喂给推荐接口，就能让推荐结果越来越接近用户的真实偏好。
虚拟体验模块的另一个作用是收集用户的决策信息：哪个景点的视频完播率高，哪个景点的全景图浏览时间长，哪个景点的“想去”按钮点击次数多。这些统计指标对于管理员调整景点排序很有参考价值。所以千万不要把虚拟体验做成一个静态的视频播放页面，它应该是整个推荐逻辑的数据入口。
4.4 预订与支付流程
由于项目不接入真实第三方支付，我实现了模拟支付流程。用户选择线路后创建订单，订单状态为“待支付”。在订单详情页点击“模拟支付”，后端校验订单归属和状态后，将状态改成“已支付”，同时生成一条支付流水记录，支付时间写入订单表。
这个流程的关键在于事务控制。创建订单时要在一个事务里完成：校验线路是否存在、校验库存、生成订单号、插入订单、扣减库存。任何一个环节失败都要整体回滚。
最常出问题的是并发扣库存。线下场景里多个人同时下单，很容易超卖。解决方案是扣减库存时使用UPDATE ... WHERE stock > 0这样的条件更新，而不是一条普通UPDATE。这样数据库行锁会保证同一时刻只有一个事务能成功扣减，避免库存变成负数。
5. 调试与部署中的常见问题
5.1 环境版本冲突
我这次使用的环境组合是：JDK 8、Maven 3.6、Tomcat 9、MySQL 5.7、Python 3.8。这个组合非常稳定，网上相关资料也最多，不建议一上来就追求JDK 17和最新Tomcat，容易遇到兼容性问题。
Maven依赖里，Lombok版本和JDK版本不兼容是最常见的坑。表现为编译时突然找不到getter/setter方法，或者提示Unknown tag。解决办法是固定Spring Boot或Spring版本，使用配套的Lombok版本。Flask这边依赖文件一定要用requirements.txt锁版本，否则不同机器下载到不同版本，行为可能完全不一样。
5.2 跨域与接口联调
前后端分开部署后，跨域问题是一定要面对的。开发环境我使用Vite代理，生产和测试环境使用Nginx。这样做的最大好处是浏览器看到的所有请求都指向同一个域名，不会产生跨域问题。
如果确实需要临时在Java端配置跨域，可以使用一个简单的Filter，在响应头里添加：
Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, POST, PUT, DELETE Access-Control-Allow-Headers: Content-Type, Authorization但要注意，生产环境用*开放所有来源并不安全，最好限定到自己的前端域名。更多时候我们其实不需要Java端开CORS，Nginx转发才是更干净的方案。
5.3 静态资源与上传路径
景点图片和视频的管理是很容易被忽略的部分。很多新手会把上传的文件保存到项目目录下，比如webapp/uploads，结果重启之后文件丢失，或者部署到服务器后发现路径拿不到。正确做法是把上传目录配置成磁盘绝对路径，比如Linux下的/data/tour/uploads，然后通过SpringMVC的静态资源映射让URL能访问到这个目录。
Windows和Linux的路径分隔符不一样，不要硬编码\或者/。用File.separator或者Paths.get()拼接路径。我遇到过本地Windows测试正常，放到Linux服务器上图片全部加载失败，排查半天就是路径分隔符写死的问题。
5.4 常见异常速查表
| 异常现象 | 可能原因 | 解决方法 |
|---|---|---|
| 数据库中文乱码 | 连接URL缺少编码参数 | 在JDBC URL后加characterEncoding=utf8，数据库和表也使用utf8mb4 |
| 接口返回404 | 请求路径与Controller不匹配 | 检查@RequestMapping路径和前端请求地址是否完全一致 |
| 上传图片无法访问 | 静态资源映射未配置 | SpringMVC中配置虚拟路径映射到上传磁盘目录 |
| 跨域请求被拦截 | 前端端口与后端不一致 | 使用Nginx反向代理或Vite代理转发 |
| Flask接口连接失败 | 服务未启动或端口占用 | 检查app.run端口，使用lsof或netstat查看 |
| 下单库存变负数 | 并发未控制 | 扣库存使用条件更新UPDATE spot SET stock=stock-1 WHERE stock>0 |
这张表我建议直接放进调试文档里。很多问题不是代码逻辑难，而是环境问题反复出现，记录下来能省很多时间。
6. 调试文档与二次开发建议
6.1 调试文档该怎么写
调试文档的意义，是让一个完全没有接触过这个项目的人，能在一台新电脑上30分钟内把服务跑起来。不是简单写一句“先运行后端再运行前端”，而是要把环境、步骤、配置和测试数据都写清楚。
我习惯把调试文档分成五块：运行环境版本、数据库初始化脚本、需要修改的配置文件、启动顺序、测试账号。其中启动顺序特别重要，我见过有人不先启动MySQL就启动后端，报错之后以为是代码问题。文档里写清楚“先启动MySQL，再启动SSM，再启动Flask，最后启动前端”，能避免大量无效沟通。
测试账号至少准备两类：一个普通用户，一个管理员。普通用户能看景点、下单；管理员能进后台管理。每个模块记录对应的接口调用方式和预期返回结果，这个文档越细，调试越轻松。
6.2 源码结构讲解
SSM端采用标准Maven结构：controller存放接口层，service存放业务逻辑，mapper存放MyBatis接口和XML，entity存放数据库实体。工具类和常量放到util，配置信息放到resources。
Flask端的目录不需要太复杂，我建议一个app.py负责路由和启动，一个recommend.py负责推荐算法，一个db_helper.py封装数据库连接和查询，数据配置放config.py。不要把几百行代码堆进一个文件，虽然Flask允许，但后期维护会很痛苦。
数据库连接信息建议用环境变量或外部配置文件方式读取，不要硬编码在源码里。尤其是Flask端的配置，源码一旦提交到仓库，密码就泄露了。虽然课程项目可能不涉及公网部署，但养成这种习惯对商业项目非常重要。
6.3 后续扩展方向
这套系统扩展性很好。比较实用的方向包括：接入地图Web API，把景点位置标注在地图上，用户浏览时可以看到线路的地理走向；加入拼团和优惠券功能，让预订模块具备更强的营销能力；把推荐模块升级为实时协同过滤，使用Redis缓存热门线路和相似度矩阵；虚拟体验模块还可以接入全景播放器甚至WebVR设备，让线上体验的沉浸感更强。
每次扩展都建议做成独立小模块。现有SSM+Flask的架构不用推翻，主业务继续跑在SSM上，新功能如果能用Python快速实现就放进Flask，如果涉及核心交易状态就放进Java端。两边通过接口协作，开发边界清晰，测试也方便。
最后说点个人体会。这套系统真正难的地方不在于某个类怎么写，而在于把Java和Python两条技术链路缝进同一条业务流程。我第一次做的时候也纠结过要不要全部用Spring写完，后来发现两边分开写反而更顺畅。希望这篇内容能帮你少踩一些我踩过的坑。
