SpringBoot+微信小程序旅游系统全栈开发实战指南

做旅游类小程序开发，尤其是一套带后台管理的完整系统时，很多人一开始会觉得无从下手。Java后端该怎么搭？小程序端怎么和SpringBoot对接？景点、路线、酒店、美食这些模块要拆到什么粒度才够用？我把这套基于微信小程序的旅游系统的完整实现思路、技术选型和代码细节整理了一份，从需求分析到数据库设计再到核心接口实现，把能踩的坑都提前标了出来，希望给你省点时间。

这个项目本身是个标准的"小程序端 + 后台管理端 + Java后端服务"三层结构。小程序端负责用户浏览、预订、收藏、评论等操作；后台管理端负责内容发布、订单处理、数据统计；SpringBoot后端把这两端串起来，提供RESTful API，做业务逻辑处理和数据库交互。适合正在做毕业设计、课设，或者刚开始接触小程序开发想系统走一遍完整流程的朋友参考。

1. 系统设计思路：为什么是SpringBoot和微信小程序这个组合

1.1 技术选型背后的逻辑

先说后端。SpringBoot在这个项目里几乎是"标准答案"级别的选择。它内嵌Tomcat，不用单独部署Web容器，一键启动；自动装配机制让配置量大幅缩减，一个spring-boot-starter-web依赖就能把Web层拉起来；再加上Spring家族天然的事务管理能力，做旅游这类涉及订单、支付状态的业务时，保证数据一致性会顺手很多。

有些朋友会纠结用不用SpringCloud那一套微服务，或者引入Redis做缓存。我的建议是：除非你的项目描述里明确写了"高并发""分布式"这类字眼，否则不要画蛇添足。一个单体SpringBoot应用配合MySQL，性能完全够用，而且把精力集中在业务逻辑上，代码可维护性反而更高——毕设答辩时老师问起来，你也能讲得更扎实。我在这个项目里做的就是最朴素的单体架构，但它足够稳定，也足够向别人展示你对SpringBoot的掌握程度。

再说前端。微信小程序这个选择有很现实的考虑：开发成本低，一套代码同时跑在iOS和Android上，不需要单独适配；微信生态自带用户体系，登录授权直接调用wx.login就能拿到openid，省去了自己搭建账号系统的麻烦；对用户来说，扫一扫就能进应用，没有下载安装的门槛，和旅游这种低频、即时性的消费场景天然匹配。

1.2 三端角色梳理

整套系统跑起来之后，交互的主体是三类人，对应三种不同的使用视角：

• 普通游客：通过微信小程序浏览景点、旅游路线、美食推荐、酒店信息，搜索感兴趣的内容，查看详情和用户评价，收藏喜欢的项目，下单预订酒店或路线。
• 后台管理员：登录管理端（我用的是浏览器访问的Vue页面），维护景点、美食、酒店、路线等基础数据，处理用户的预订订单，发布公告和资讯，查看系统的数据统计。
• 系统运维者：也就是你自己，负责后端服务的部署和维护，数据库的备份，以及小程序端上线前在微信公众平台的各种配置。

这三类角色的需求逻辑是上下游关系：管理员在后台录入数据，用户在小程序端消费内容并产生订单，订单数据最终回流到后台供管理员处理和统计分析。顺着这条主线去设计功能模块，思路会非常清晰。

1.3 从零理解SpringBoot自动装配对项目的影响

前面提到SpringBoot的自动装配是这个项目能轻装上阵的关键，这里稍微展开讲一下，面试和答辩时这是高频考点，写代码时理解了它也能少踩很多坑。

SpringBoot启动类上的@SpringBootApplication注解，拆开来看是@SpringBootConfiguration（表示这是一个配置类）、@EnableAutoConfiguration（开启自动装配）和@ComponentScan（扫描本包及子包下的组件）三个注解的组合。核心在@EnableAutoConfiguration，它会扫描所有依赖包里的META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件，读取里面列出的自动配置类。

举个例子，当你引入spring-boot-starter-data-redis后，自动装配会检测到RedisTemplate相关的类，并自动配置连接工厂、模板对象。如果你什么都没配，它会用默认的localhost地址去连接；你一旦在application.yml里配置了spring.redis.host，配置属性绑定机制就会覆盖默认值。这就是"约定优于配置"的底层逻辑。

2. 功能模块拆解与数据库设计

2.1 用户端功能清单

小程序端的用户操作逻辑，我按"浏览-决策-预订-反馈"这条行为路径来设计，每个环节都有对应的功能支撑：

• 首页：顶部搜索框支持按景点名称、城市等关键词搜索；轮播图展示平台精选的推荐活动和热门景点；下方是快捷入口，分别指向景点、美食、酒店、路线四个核心分类模块。
• 景点模块：展示景点列表，支持按城市、评分、浏览量排序筛选；详情页包括景点图片、文字介绍、开放时间、门票价格、位置地图，以及用户评论列表。用户可以收藏景点，也可以对景点发表评论。
• 美食模块：展示美食店铺和特色菜品，支持分类浏览（地方菜、小吃、火锅等）；详情页包含店铺地址、联系电话、人均消费、用户评价；支持电话拨号和位置导航跳转。
• 酒店模块：酒店列表支持按价格区间、星级筛选；详情页展示房型、设施服务、价格日历；用户选择入住和退房日期、房间数量后，提交预订订单。
• 旅游路线模块：路线通常以"2日游""3日游"的形式出现，包含行程安排、路线亮点、费用说明；用户可查看路线详情，选择出发日期和人数进行预订。
• 个人中心：微信授权登录后展示用户头像、昵称；我的收藏、我的订单、我的评论都在这里管理。
• 通用模块：公告列表、意见反馈、关于我们。

2.2 后台管理端功能清单

后台管理端的核心职责是内容管理和交易管理，我把功能分层这样安排：

• 系统管理：管理员账号管理、角色权限分配（超级管理员、运营、编辑）、系统日志查看。
• 内容管理：景点管理、美食管理、酒店管理、路线管理，均支持增删改查，图片上传采用本地存储方式，管理员上传后自动生成访问路径；公告和资讯发布也在这里完成。
• 订单管理：按订单状态（待支付、已支付、已取消、已完成）分类查看，支持订单详情查看、发货/核销操作、订单删除。
• 数据统计：展示总用户数、今日订单量、总交易金额等核心指标，配合简单的图表展示趋势。

2.3 数据库表结构设计的核心考量

数据库设计是这类项目最容易忽略却又最影响后续开发的部分。我设计的是8张核心业务表，用一张结构逻辑图来展示它们之间的关系。

核心表的字段设计和业务含义：

用户表（user）

用户表存储小程序授权登录后的基本用户信息。主键id自增；openid字段保存微信用户的唯一标识，设置唯一索引防止重复绑定；nickname和avatar分别存昵称和头像地址。新增用户时通过create_time记录注册时间，status字段控制账号是否可用。

景点表（scenic）

景点表是内容型表的核心。name字段存景点名称；cover存封面图URL；images用JSON格式存储多张图片地址（我在Java端用List<String>接收，JSON序列化后存入VARCHAR类型的字段）；description存详细文字介绍；province、city、address三个字段组合成完整的地理位置信息，方便前端的区域筛选和搜索；price存成人票价格；open_time保存开放时间描述；ticket_info存购票须知；view_count在用户点击详情时自增，用于热门推荐排序。

美食表（food） 和酒店表（hotel）

这两个表的结构类似，都包含名称、封面、介绍、联系电话、详细地址、人均消费/参考价格、评分这些基本信息。酒店表额外多出facility（设施服务，逗号分隔或JSON格式）和room_info（JSON格式的房型列表）。所有地理位置相关的表我都建议单独存经度longitude和纬度latitude字段，方便后续对接微信小程序的地图组件，在详情页直接展示位置标记。

旅游路线表（route）

路线表包含title（路线标题）、days（行程天数）、cover、images、price（每人价格）、trip_content（用JSON或长文本存储每天的行程详情）、fee_include（费用包含）、fee_uninclude（费用不含）、notes（注意事项）这几个关键字段。路线是旅游系统的特色模块，行程安排的展示逻辑比较复杂，所以我在设计之初就决定用结构化的JSON来存，小程序端拿到后按天循环渲染，比存大段富文本再拼字符串要清晰得多。

预订订单表（order）

订单表是交易链路的核心。order_no（订单编号）用时间戳加随机数生成，给用户展示和后续查询用；user_id关联用户表；order_type区分订单类型（景点门票、酒店、路线）；item_id存具体的商品ID；item_name冗余存商品名称，防止商品被删除后订单页显示空白；price存下单时的单价，count存数量，total_amount存总价；status用0-待支付、1-已支付、2-已取消、3-已完成这几个状态值；remark给用户填写备注。这里有一个比较关键的取舍：为什么不直接做外键关联，而是用逻辑外键加冗余字段？

外键约束在项目规模小的时候确实方便，可以保证数据的完整性。但实际开发中，外键会带来一些操作上的限制，比如删除商品时必须先确认没有关联订单，在后台管理系统里操作会显得比较麻烦。所以我选用了逻辑外键的方式：表结构里只保存关联的ID，在Java代码层用join查询或者二次查询来组装数据。这样做的好处是删除逻辑更灵活（比如删除商品时，我用逻辑删除标记，而非物理删除），对性能也有一定帮助。

收藏表（favorite） 和评论表（comment）

这两个表的结构类似。收藏表存user_id、item_type（收藏的对象类型：景点、美食、酒店、路线）、item_id，加一个唯一索引uk_user_item（user_id + item_type + item_id），防止重复收藏。评论表除了用户、对象类型和对象ID外，还有content（评论内容）、score（评分，1-5星）、reply（管理员回复，可空）。

还有一张管理员表（admin), 存后台登录账号密码（BCrypt加密）、角色、最近登录时间。

2.4 数据库初始化脚本和数据类型选择的经验

写完建表SQL之后，有几个经验可以分享：

• 金额字段一律用Decimal，不要用Float或Double。Float和Double在计算机中是以二进制浮点数存储的，0.1 + 0.2 的结果在小数点后十几位会出现精度误差，这在涉及金额计算的业务中是不能接受的。我在Java实体类中对应的字段也是BigDecimal类型。
• 文本字段长度要留够余量。景点介绍、路线的行程安排、费用说明这些字段最少要设成TEXT类型，不要因为偷懒全部用VARCHAR和VARCHAR(255)。实际录入数据时你会发现，一段完整的路线介绍轻松超过1000字，VARCHAR(255)根本塞不下。
• 每个表都要有create_time和update_time字段，在开发调试和数据分析阶段都能用上——比如统计系统就是按创建时间分组统计的。

3. 核心功能实现与关键代码拆解

3.1 微信小程序登录流程的实现（含失败的常见原因）

登录是整个小程序端最前置的环节，这里把完整流程和容易踩的坑都写清楚。核心逻辑是：小程序端用wx.login拿到临时凭证code，发送到后端；后端拿着code加小程序的AppId和AppSecret去微信的接口服务换取openid和session_key；拿到openid后，后端查询用户表，存在则直接返回登录成功，不存在则自动注册一个新用户。

后端Controller层代码：

java复制@RestController
@RequestMapping("/api/user")
public class UserController {

    @Autowired
    private UserService userService;

    @PostMapping("/login")
    public Result login(@RequestBody LoginRequest request) {
        // 1. 调用微信接口，用 code 换 openid
        String openid = userService.getOpenidByCode(request.getCode());
        if (StringUtils.isEmpty(openid)) {
            return Result.error("登录失败，无法获取用户身份");
        }
        // 2. 查询用户，不存在则自动注册
        User user = userService.findOrCreateUser(openid, request.getNickname(), request.getAvatar());
        // 3. 生成自定义登录态 token（可以是 UUID，正式项目用 JWT）
        String token = userService.generateToken(user.getId());
        return Result.success(new LoginResponse(token, user));
    }
}

这里容易出问题的地方有两处。第一处是wx.login返回的code是一次性的，有效期只有5分钟，而且只能使用一次。如果你在测试接口时反复调用同一个code，第二次就会报invalid code错误。第二处是换取openid的接口jscode2session返回的格式：正常情况下返回{"openid":"xxx","session_key":"xxx"}，但也有可能返回{"errcode":40013,"errmsg":"invalid appid"}，这说明你在微信公众平台配置的AppId和AppSecret有问题，需要去核对一下。还有就是，请求微信接口时需要使用RestTemplate或者HttpClient，不要自己手动拼接 HTTP 请求，SpringBoot 提供的RestTemplate足够用了。

3.2 后端接口的通用返回体包装与统一异常处理

我习惯在项目中先定义一个统一的返回值类，这样前端处理逻辑会轻松很多：

java复制public class Result<T> {
    private int code;       // 200 成功，其他为失败
    private String message; // 提示信息
    private T data;         // 数据体

    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.code = 200;
        result.message = "success";
        result.data = data;
        return result;
    }

    public static <T> Result<T> error(String message) {
        Result<T> result = new Result<>();
        result.code = 500;
        result.message = message;
        return result;
    }
}

对应地，在Controller里所有成功返回都调Result.success(data)，失败则抛出业务异常，由@RestControllerAdvice统一捕获处理，返回Result.error(message)。这样小程序端在wx.request的成功回调里就能直接判断res.data.code === 200，不用每个页面都写一套容错逻辑。

3.3 景点列表分页接口的完整实现

景点列表是用户打开小程序后高频访问的接口，必须做分页和筛选参数。我给出的Controller层代码和Service层实现如下：

java复制@RestController
@RequestMapping("/api/scenic")
public class ScenicController {

    @Autowired
    private ScenicService scenicService;

    @GetMapping("/list")
    public Result<PageResult<ScenicVO>> list(
            @RequestParam(defaultValue = "1") Integer pageNum,
            @RequestParam(defaultValue = "10") Integer pageSize,
            @RequestParam(required = false) String city,
            @RequestParam(required = false) String keyword) {
        return Result.success(scenicService.queryPage(pageNum, pageSize, city, keyword));
    }
}

Service层采用MyBatis-Plus的LambdaQueryWrapper来构造查询条件，代码非常简洁：

java复制@Override
public PageResult<ScenicVO> queryPage(Integer pageNum, Integer pageSize, String city, String keyword) {
    LambdaQueryWrapper<Scenic> wrapper = new LambdaQueryWrapper<>();
    // 城市筛选
    if (StringUtils.hasText(city)) {
        wrapper.eq(Scenic::getCity, city);
    }
    // 关键字搜索，name 或 address like
    if (StringUtils.hasText(keyword)) {
        wrapper.and(w -> w.like(Scenic::getName, keyword)
                          .or().like(Scenic::getAddress, keyword));
    }
    // 按浏览量倒序展示，相当于做了个简单的热门排序
    wrapper.orderByDesc(Scenic::getViewCount);
    
    Page<Scenic> page = new Page<>(pageNum, pageSize);
    scenicMapper.selectPage(page, wrapper);
    
    // 组装分页结果
    PageResult<ScenicVO> result = new PageResult<>();
    result.setTotal(page.getTotal());
    result.setList(page.getRecords().stream().map(this::convertToVO).collect(Collectors.toList()));
    return result;
}

PageResult是手动封装的分页对象，包含total（总条数）和list（当前页数据）两个字段。前端小程序在onPullDownRefresh时请求第一页并重置列表，在onReachBottom时页码加1请求下一页并追加数据，这是小程序端最标准的上拉加载更多逻辑。

3.4 酒店预订与订单状态流转的实现

酒店预订涉及修改库存和生成订单两个操作，这里直接用数据库事务保证原子性——要么两个操作都成功，要么都失败回滚。Service层的核心方法如下：

java复制@Transactional(rollbackFor = Exception.class)
@Override
public Order createHotelOrder(Long userId, Long hotelId, Date checkIn, Date checkOut, Integer roomCount) {
    Hotel hotel = hotelMapper.selectById(hotelId);
    if (hotel == null) {
        throw new BusinessException("酒店不存在");
    }
    // 计算入住天数，注意跨天和分钟级溢出问题
    long days = (checkOut.getTime() - checkIn.getTime()) / (1000 * 60 * 60 * 24);
    if (days <= 0) {
        throw new BusinessException("离店日期必须晚于入住日期");
    }
    
    // 生成订单
    Order order = new Order();
    order.setOrderNo(generateOrderNo()); // 时间戳 + 随机数，保证唯一性
    order.setUserId(userId);
    order.setOrderType(2); // 2 表示酒店
    order.setItemId(hotelId);
    order.setItemName(hotel.getName());
    order.setPrice(hotel.getPrice());
    order.setCount(roomCount);
    order.setTotalAmount(hotel.getPrice().multiply(new BigDecimal(roomCount)).multiply(new BigDecimal(days)));
    order.setStatus(0); // 待支付
    order.setRemark("入住：" + DateUtil.formatDate(checkIn) + " 至 " + DateUtil.formatDate(checkOut));
    orderMapper.insert(order);
    
    return order;
}

@Transactional注解是Spring声明式事务的入口。在这里，roomCount对应酒店房间数量，在实际项目中还需要有一张房间库存表来校验余量，这里简化为不校验。生成订单号的方法我用了System.currentTimeMillis()加三位随机数，再加上两个用户ID拼接，确保高并发下也不会重复。

3.5 微信小程序端的页面与组件实现

小程序端的目录结构我大体按功能模块划分：

code复制miniprogram/
├── pages/
│   ├── index/          // 首页
│   ├── scenic/         // 景点列表 + 详情
│   ├── food/           // 美食列表 + 详情
│   ├── hotel/          // 酒店列表 + 详情
│   ├── route/          // 旅游路线列表 + 详情
│   ├── order/          // 订单列表 + 订单确认页
│   ├── favorite/       // 我的收藏
│   ├── comment/        // 评论
│   └── user/           // 个人中心
├── utils/
│   ├── request.js      // wx.request 封装
│   └── util.js         // 时间格式化等工具函数
├── components/
│   ├── star-rating/    // 评分组件
│   ├── empty-view/     // 空状态占位
│   └── price-tag/      // 价格展示
└── app.json

request.js封装是整个小程序端的基础设施，核心是把公共的baseUrl、登录态token、错误提示统一处理。这个文件比想象的重要，后续所有页面的数据请求都走这个封装，调试和改配置都只改动一处：

javascript复制const request = (url, method = 'GET', data = {}) => {
  return new Promise((resolve, reject) => {
    wx.request({
      url: baseUrl + url,
      method,
      data,
      header: {
        'Content-Type': 'application/json',
        'token': wx.getStorageSync('token')
      },
      success: (res) => {
        if (res.statusCode === 200 && res.data.code === 200) {
          resolve(res.data.data);
        } else if (res.statusCode === 401) {
          // 登录态失效，跳转登录
          wx.navigateTo({ url: '/pages/login/index' });
          reject(res);
        } else {
          wx.showToast({ title: res.data.message || '请求失败', icon: 'none' });
          reject(res);
        }
      },
      fail: (err) => {
        wx.showToast({ title: '网络异常，请稍后重试', icon: 'none' });
        reject(err);
      }
    });
  });
};

酒店列表页的数据渲染，我在onShow生命周期中调用接口获取数据，用data里的hotelList驱动视图层。通过wx:for循环渲染卡片，点击跳转到详情页并带上id参数。

首页轮播图用小程序自带的swiper组件，列表页的图片使用lazy-load懒加载属性，可以优化首屏加载速度。个人中心页需要在onShow时获取最新的用户信息——如果提前判断本地没有token，就直接跳转授权登录页。

4. 从零搭建项目的完整实战流程

4.1 环境准备和工程初始化

搭这个项目，我建议的本地环境是：JDK 8（考虑到很多学校机房和老项目都在用，这个兼容性最好，也能规避后面会提到的版本坑）、Maven 3.6+、MySQL 5.7或8.0、微信开发者工具稳定版。如果你本机已经装了JDK 17，也不要慌，后面我会专门说版本匹配的问题。

后端工程直接去Spring Initializr生成，或者用IDEA自带的初始化向导。关键依赖勾选下面这几个：

• Spring Web（提供REST接口能力）
• Spring Boot DevTools（热部署，改完代码自动重启，调试效率翻倍）
• MyBatis Framework（数据访问层）
• MySQL Driver（数据库驱动）
• Lombok（开发效率工具，自动生成getter/setter）

4.2 编写配置文件和启动类

application.yml是后端最核心的配置文件，它的内容决定了项目能不能跑起来。我常用的配置如下：

yaml复制server:
  port: 8080

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/travel_system?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
    username: root
    password: 123456
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

主要强调两点。一是数据库连接串上一定加上useSSL=false和serverTimezone=Asia/Shanghai，否则高版本的MySQL连接会报SSL异常或者时区错误。二是Jackson的日期格式化配置加上后，后端返回的时间字段就会是yyyy-MM-dd HH:mm:ss格式，小程序端不用额外做字符串转Date的处理。MyBatis-Plus的逻辑删除配置给了deleted字段全局生效，删除操作变成自动更新deleted=1，查询自动带上deleted=0条件，这样用户误删数据还能在数据库里捞回来。

启动类很简单，就是一个标准的@SpringBootApplication加main方法。注意启动类必须放在所有包的最外层，否则@ComponentScan扫描不到Controller和Service，启动后会报404。

4.3 数据库初始化

建库建表直接用我前面提到的8张核心表的SQL脚本执行。表建完后顺手插入几条测试数据——比如一个景点、一家酒店、一条路线、几个管理员账号。这一步非常建议做，因为后面联调接口时如果没有数据，整个页面看起来都是空的，很难判断是接口报错了还是数据库查不到数据。

4.4 创建小程序项目并配置

微信开发者工具导入项目后，需要在app.json中配置页面路径、窗口样式和底部TabBar。我这里有一个四栏的TabBar设计：首页、分类、订单、我的。需要注意的是，TabBar的图标需要准备81px*81px的PNG图片，不要在TabBar里嵌套太深的页面跳转逻辑，否则容易出导航栈超过10层的警告。

调试时还有一个关键配置：在微信开发者工具"详情-本地设置"里勾选"不校验合法域名"。否则开发模式下你的真机手机访问不了http://localhost:8080，只会报request失败。不过这只限于开发阶段，正式上线前还是要配置合法域名并启用HTTPS。

4.5 前后端联调的完整流程

联调是实现整条业务链路的关键阶段。我的经验是，先打通"用户登录 - 景点列表 - 景点详情"这条主线，再扩展其他功能模块。登录接口通了，token就能存到本地，后续所有请求都会自动带上；景点列表通了，分页组件的样式和数据绑定逻辑就验证了，后面做美食、酒店、路线列表几乎就是复制粘贴改改字段。

一个实用的联调技巧：在Service层的关键方法里加日志输出，用MyBatis-Plus自带的SQL日志功能把每次执行的SQL打出来。联调时前端请求一个接口，后端控制台立刻能看到SQL语句和参数，排查"为什么查不到数据""为什么多查了一条"这类问题效率极高。

5. 版本兼容、部署与常见问题排查实录

5.1 SpringBoot版本太高导致的JDK编译问题

写这个项目时，一个绕不开的现实问题就是SpringBoot版本和JDK版本的匹配。现在的Spring Initializr默认推荐的SpringBoot版本已经走得很靠前了，如果你用初始化工具直接生成，很可能拿到一个要求JDK 17甚至JDK 21的工程，而本机装的是JDK 8，编译直接报错；或者反过来，项目自动生成时用了高版本的SpringBoot，你打包时发现源发行版 17 需要目标发行版 17之类的编译失败提示。

我的建议是：在pom.xml中显式指定你熟悉的SpringBoot版本，比如2.7.18。这是SpringBoot 2.x的最后一个版本，修复了大量已知问题，同时完全兼容JDK 8，也兼容后来JDK 8升级到JDK 11的需求。如果一定要用SpringBoot 3.x（不推荐课设和毕设项目冒这个险），那就必须使用JDK 17，并且注意javax.servlet包名变成了jakarta.servlet，原生引入的@Resource等注解包名也会变化。

5.2 小程序真机调试报net::ERR_CONNECTION_RESET

这个错误非常典型：模拟器里一切正常，但真机一调接口就报net::ERR_CONNECTION_RESET或者request:fail。原因很简单，你手机和电脑不在同一个局域网，手机访问不到你电脑上localhost的SpringBoot服务。

解决办法有两个。第一，把SpringBoot的启动地址改为0.0.0.0，即server.address=0.0.0.0；第二，电脑和手机连同一个Wi-Fi，手机访问时把baseUrl从http://localhost:8080改成你电脑的局域网IP，比如http://192.168.1.5:8080。Windows电脑用ipconfig查IP，Mac用ifconfig查IP。注意，手机连的Wi-Fi和电脑连的必须在同一个路由器下，公司网络或校园网做了AP隔离的话，这种办法就行不通了，只能退回去用模拟器调试。

5.3 小程序获取登录后的微信用户失败

不少朋友在开发时会遇到这种情况：wx.login能正常拿到code，后端也调通了微信接口，但用户昵称头像获取失败。原因大概率是你在开发阶段没有做完整授权。新版的小程序获取用户信息必须用button组件的open-type="getUserProfile"方式，让用户主动点击触发授权弹窗，而不是在页面的onLoad生命周期里直接调用wx.getUserInfo。这是微信官方对用户隐私保护收紧后的强制要求。

还有一个相关经验：2022年后微信对头像昵称填写能力做了改版，现在大部分项目不再强行依赖微信的授权返回头像昵称，而是在个人中心提供一个"点击设置头像昵称"的入口，用户填完保存到自己的数据库。这套方案更稳定，因为它不依赖微信的授权弹窗是否弹出。

5.4 SpringBoot项目打包部署

项目开发完成后，部署到服务器的大致流程是：本地执行mvn clean package -DskipTests命令，打包成travel-system-0.0.1-SNAPSHOT.jar。通过java -jar travel-system-0.0.1-SNAPSHOT.jar启动，指定端口和数据源地址。如果是部署到Docker容器里，重点是把MySQL的连接地址从localhost改成容器网络内可访问的地址，并且需要将SpringBoot服务的端口映射到宿主机的对应端口。用java:8基础镜像构建最省事，前提是项目编译用的JDK版本和运行环境一致。

5.5 常见问题速查表

我把开发过程中容易踩的坑整理成表格，方便快速定位问题：

5.6 代码版本管理与项目备份建议

这套项目带了源码、文档、运行视频和讲解视频，交付前最好全部核对一遍。在实际协作开发时，我强烈建议用Git做版本管理，每完成一个功能模块就提交一次，提交信息写清楚改了什么（比如feat: 酒店预订订单接口）。遇到改崩了的情况，一条git revert就回滚了，比手动复制文件备份高效太多。

6. 讲深一层：项目答辩和面试中被高频追问的问题

平时帮人看毕设项目，我发现老师爱问的问题，和面试官问的技术问题高度重叠。提前准备好这几类的回答，能让你少慌张：

• 为什么选用SpringBoot而不是SpringMVC？ 回答思路：SpringBoot是SpringMVC的进一步封装，自动装配省去大量XML配置，内嵌Tomcat简化部署，开箱即用。这句话重点体现你对自动化配置原理的理解。
• MyBatis-Plus和MyBatis有什么区别？ 回答思路：MyBatis-Plus是MyBatis的增强工具，提供了通用Mapper（BaseMapper）、条件构造器（LambdaQueryWrapper）、分页插件等现成能力，单表CRUD不用手写SQL，开发效率大幅提升。
• 微信登录的流程完整叙述一遍。 从wx.login拿code，到后端用jscode2session换openid，再到查询或创建用户、签发token，这条链路要能脱稿说出来。
• 项目的难点或者Bug是什么？ 不要说自己没有难点。可以讲你在实现酒店预订时遇到的事务问题——比如并发下订单重复插入、房间超卖，通过@Transactional加数据库唯一约束解决；或者讲你在真机调试时遇到的网络配置问题，最终通过改局域网访问地址解决。

还有一类问题是关于项目扩展的："如果用户量很大，你怎么改造这个系统？"我的建议是抓住两个要点回答：数据库层面增加Redis缓存热点数据（景点列表、首页轮播），减少数据库压力；服务层面把文件上传和静态资源迁移到对象存储，通过CDN加速访问。这样回答既体现思考，又不至于自己把坑越挖越深。

写到最后再分享一点个人经验和体会。做这种全栈项目，最大的感受是不要把精力花在纠结技术上，而是要花在把业务场景想透上。技术选型这部分，SpringBoot和微信小程序都是成熟方案，照着官方文档搭很快；但你一旦把景点、路线、酒店、美食这几个模块的字段设计、状态流转、前后端交互方式理顺，后面的开发就是体力活，能顺畅很多。我做这套项目的时候，前后改动最多的地方其实是数据库表结构，因为一开始没想清楚订单和商品的关系，做到一半又回头加字段。所以建议你动手写代码前，一定先把表结构画一遍，把关键业务链路（比如从下单到支付到核销）的状态图画出来，这一步省下的时间，远超你规划时花掉的时间。后续如果你打算把它扩展成真正能商用的系统，可以考虑引入Redis缓存热门景点数据、集成微信支付和地图导航、增加管理端的图表可视化报表。

另外，SpringBoot的Banner（启动时控制台打印的ASCII art图案）是个有意思的小细节，网上有在线的banner生成器，把你的项目名生成一个大大的ASCII字母，启动时打印出来，整个项目质感立刻不一样，答辩演示的时候也是一个不错的小亮点。这个项目我自测跑完所有流程，最舒服的还是调试时打开MyBatis-Plus的SQL日志，配合前端页面一个个接口调通，那种"画面在手机端动起来"的感觉，就是你这一天写码值回票价的时刻。