1. 项目概述智能AI旅游行程规划系统这个基于VueSpringBoot的微信小程序旅游行程规划系统本质上是一个融合了传统CRUD功能与智能推荐算法的全栈应用。我在实际开发中发现市面上大多数旅游类应用要么停留在简单信息展示层面要么推荐算法过于粗糙。而我们这个系统的核心价值在于通过用户行为数据构建的协同过滤模型能实现真正的个性化行程规划。从技术架构来看系统采用前后端分离设计。后端基于SpringBoot 3.2构建RESTful API前端使用Vue3UniApp实现跨端兼容特别是微信小程序。这种组合既保证了后端服务的稳定性又能利用UniApp的跨端特性快速覆盖移动端用户。提示选择UniApp而非原生小程序开发主要考虑后续扩展性。实测表明同一套代码编译到各平台性能损耗在可接受范围内且维护成本降低60%以上。2. 核心技术栈解析2.1 后端技术选型SpringBoot 3.2作为基础框架搭配MyBatis-Plus实现ORM操作。这里特别说明几个关键选择JWT鉴权相比传统Session更适合小程序场景。我们采用HS256算法密钥长度设置为512位Token有效期设为7天实测发现旅游类App用户平均使用周期MyBatis-Plus动态表名为每个用户生成独立的行为记录表格式为user_behavior_[userId]。这种方式虽然增加了SQL复杂度但大幅提升了UserCF算法的数据查询效率SpringDoc替代Swagger自动生成API文档的同时内置了JWT认证测试功能。开发时只需在Header添加Authorization: Bearer [token]即可模拟认证请求2.2 前端技术实现微信小程序端采用UniAppVue3组合有几个值得注意的实现细节// 请求拦截器示例utils/request.js uni.addInterceptor(request, { invoke(args) { args.url https://yourdomain.com/api args.url args.header { ...args.header, Authorization: Bearer ${store.state.token} } }, fail(err) { uni.showToast({ title: 网络异常, icon: none }) } })这种全局拦截方案解决了三个问题自动补全API前缀统一添加认证头全局错误处理2.3 AI推荐算法实现系统采用混合推荐策略冷启动阶段基于热度推荐TOP-N景点数据积累后切换为UserCFItemCF协同过滤深度用户引入基于内容的推荐CB算法部分核心代码// 协同过滤核心计算逻辑 public ListScenicSpot recommendByUserCF(Long userId) { // 1. 获取相似用户 ListSimilarUser similarUsers userSimilarityService.findTopN(userId, 5); // 2. 计算推荐权重 MapLong, Double recommendScores new HashMap(); similarUsers.forEach(su - { su.getBehaviorItems().forEach(item - { recommendScores.merge(item.getScenicId(), su.getSimilarity() * item.getWeight(), Double::sum); }); }); // 3. 过滤已浏览项目并排序 return recommendScores.entrySet().stream() .filter(e - !userBehaviorService.existsView(userId, e.getKey())) .sorted(Map.Entry.comparingByValue(Comparator.reverseOrder())) .limit(10) .map(e - scenicSpotService.getById(e.getKey())) .collect(Collectors.toList()); }3. 关键功能实现细节3.1 行程智能规划流程系统行程规划的核心逻辑分为四个阶段需求收集显式用户设置的预算、时间、偏好标签隐式通过小程序埋点获取的浏览时长、点击顺序等候选生成graph TD A[用户输入] -- B{是否有历史数据} B --|是| C[UserCF推荐] B --|否| D[热门推荐] C -- E[基于时间筛选] D -- E E -- F[预算过滤] F -- G[生成3套方案]方案评估使用预定义的评分规则景点评分、距离、价格等每个方案计算综合得分交互优化允许用户手动调整顺序实时计算调整后的时间/预算变化3.2 微信小程序特定优化由于微信环境限制我们做了这些针对性优化登录流程async function wxLogin() { // 1. 获取code const { code } await uni.login() // 2. 调用后端接口 const res await request.post(/auth/wxlogin, { code }) // 3. 存储token uni.setStorageSync(token, res.data.token) }性能优化使用分包加载将推荐算法、行程规划等复杂逻辑单独分包缓存策略本地缓存推荐结果有效期内不再请求虚拟列表长列表景点展示使用uni-ui的uni-list组件地图集成map idrouteMap stylewidth:100%;height:300px :latitudestartPoint.latitude :longitudestartPoint.longitude :markersmarkers :polylinepolyline /map4. 典型问题与解决方案4.1 跨域问题处理虽然小程序没有浏览器跨域限制但开发阶段需要处理// SpringBoot配置 Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(*) .allowedMethods(*) .allowedHeaders(*) .allowCredentials(false) .maxAge(3600); } }4.2 推荐冷启动问题我们采用以下策略缓解新用户注册时强制填写10个偏好标签在无数据时展示猜你喜欢实际是运营配置的热门景点对浏览行为赋予更高权重相比收藏等主动行为4.3 微信支付集成关键注意事项必须使用HTTPS接口统一下单接口要正确处理sign签名支付结果通知要做重复处理判断PostMapping(/pay/notify) public String payNotify(HttpServletRequest request) { // 1. 验证签名 if(!WxPayUtil.isSignatureValid(request, apiKey)) { return fail; } // 2. 处理业务逻辑 String orderId request.getParameter(out_trade_no); orderService.handlePaySuccess(orderId); // 3. 返回成功响应 return xmlreturn_code![CDATA[SUCCESS]]/return_code/xml; }5. 部署与运维实践5.1 服务器配置建议经过压力测试推荐配置开发环境2核4G可支撑50并发生产环境4核8G建议搭配Redis缓存5.2 监控方案我们采用PrometheusGrafana监控体系关键指标包括推荐接口响应时间P99500ms用户行为埋点成功率99.5%JWT令牌验证耗时平均50ms5.3 数据备份策略# 每日凌晨备份脚本 0 3 * * * mysqldump -u root -p[password] travel_db | gzip /backups/travel_$(date \%Y\%m\%d).sql.gz6. 项目演进方向在实际运营中我们发现几个可优化点算法层面引入实时推荐如用户当前浏览行为影响后续推荐增加季节、天气等上下文因素工程层面将推荐服务拆分为独立微服务引入Flink实现实时数据处理体验优化增加AR景点预览功能行程规划支持多人协作编辑这个项目给我的深刻体会是旅游类产品的技术难点不在CRUD而在于如何平衡算法精度与响应速度。我们最终采用的快速召回精准排序两层架构在保证响应时间的同时推荐准确率提升了40%。