SpringBoot+Vue+MyBatis+MySQL旅游出行管理系统开发实战

做了几年的Java全栈开发，前后端分离的项目也接过不少。这次用SpringBoot + Vue + MyBatis + MySQL这套组合做了一个旅游出行指南管理系统，整个项目从数据库设计到前后端联调花了三周左右，中间踩了不少坑，也沉淀了一些比较实用的经验。如果你正准备做类似的课程设计、毕业设计或者企业内部的小型信息管理系统，这篇文章应该能帮你少走很多弯路。

这个系统本身的目标很明确：把旅游出行的核心信息管起来，包括景点管理、旅游路线规划、用户收藏、出行笔记、后台数据维护等。它解决的是传统人工记录和Excel管理在实时性、关联性、检索效率上的痛点，同时给前端用户一个直观的浏览和互动界面。系统采用前后端分离架构，后端提供RESTful接口，前端用Vue构建单页应用，数据库用MySQL存储业务数据，MyBatis负责数据库访问层。

整套项目麻雀虽小五脏俱全，涉及JWT登录鉴权、文件上传、多条件组合查询、分页搜索、图表统计这些在实际开发中非常高频的技术点。无论你是刚学完SpringBoot和Vue想练手的学生，还是准备把类似管理系统快速落地的开发者，这篇文章里讲到的设计与实现思路都可以直接参考。

1. 整体设计思路与技术选型分析

1.1 为什么还是选了SpringBoot + Vue这套组合

很多人觉得SpringBoot + Vue已经做到烂大街了，但说实话，针对这种旅游出行指南类的管理系统，这套组合仍然是最稳的选择，没有之一。

后端用SpringBoot，核心优势在于自动配置和生态完善。你不需要像传统SSM那样手动配一堆XML文件，一个spring-boot-starter-web依赖就能把内嵌Tomcat、Spring MVC、JSON序列化全部搞定。配合spring-boot-starter-validation做参数校验、spring-boot-starter-aop处理日志，开发效率比十年前高太多了。

前端用Vue，核心优势在于组件化和响应式数据绑定。旅游出行指南这种业务天然适合拆分成组件：景点卡片、路线列表、收藏按钮、评论区域，每个功能都是独立组件。页面状态（比如用户是否登录、当前筛选条件）由Vue的响应式系统自动管理，不需要像jQuery那样手动操作DOM，代码可维护性好很多。

数据库用MySQL，原因更简单：数据量在百万级别以内，MySQL性能和稳定性完全够用，而且它的事务支持、索引机制、备份恢复方案都非常成熟。配合Navicat或者命令行工具做日常管理，开发体验很顺畅。

1.2 项目模块划分与管理后台设计

这个系统大体上拆成两个子端：前台用户端和后台管理端。前端用户端给普通用户使用，核心功能包括景点浏览、路线推荐、收藏互动、出行笔记；后台管理端给系统运营人员使用，核心功能包括景点信息的增删改查、路线上架下架、用户管理、数据统计。

标题里提到的“ms ()abo管理系统”，我理解下来的意思是“管理后台管理系统”，对应英文Management System的缩写。在实际落地时，我把它统一收敛为后台管理模块（Admin），在代码里单独维护一个admin包，和前台模块（web）隔离，避免业务逻辑混在一起。

数据库层面，我设计了7张核心表：系统用户表（sys_user）、景点信息表（scenic_spot）、旅游路线表（travel_route）、路线景点关联表（route_spot_rel）、用户收藏表（user_favorite）、出行笔记表（travel_note）、评论表（travel_comment）。这个表结构覆盖了用户从浏览到收藏再到分享的完整链路，后续扩展酒店预订、机票查询等功能也方便加表。

2. 数据库设计后端初始化配置详解

2.1 核心表结构与建表SQL实例

数据库设计是最需要想清楚的一环，这个环节出了问题，后续所有业务代码都要跟着返工。我设计表结构时是围绕“游览链路”来思考的：用户登录后先看景点列表，点进详情看到景点介绍，再查看关联的旅游路线，收藏喜欢的景点，最后还能写一篇出行笔记分享体验。

以最关键的两张表为例。景点信息表主要负责存景点基础属性，字段包括景点名称、所在城市、门票价格、开放时间、景点介绍、封面图片地址、评分、状态等。核心建表语句是这样的：

sql复制CREATE TABLE scenic_spot (
  id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT '主键ID',
  spot_name VARCHAR(100) NOT NULL COMMENT '景点名称',
  city VARCHAR(50) NOT NULL COMMENT '所在城市',
  address VARCHAR(200) COMMENT '详细地址',
  ticket_price DECIMAL(10,2) DEFAULT 0.00 COMMENT '门票价格',
  open_time VARCHAR(50) COMMENT '开放时间',
  description TEXT COMMENT '景点介绍',
  cover_image VARCHAR(255) COMMENT '封面图片URL',
  score DECIMAL(2,1) DEFAULT 5.0 COMMENT '评分',
  status TINYINT DEFAULT 1 COMMENT '状态 1上架 0下架',
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  KEY idx_city (city),
  KEY idx_status (status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='景点信息表';

这里有几个细节值得说明。一是ticket_price用DECIMAL而不是FLOAT，因为浮点数在金额计算上会丢失精度，这在涉及支付、票价统计的场景是大忌。二是城市和状态字段都建了索引，因为查询时按城市筛选是最高频的操作，不加索引后期数据量大了SQL会明显变慢。三是所有表统一用utf8mb4字符集，不光是支持中文，还有emoji表情，用户写出行笔记时可能会加表情符号，用utf8mb4才存得进去。

用户收藏表和出行笔记表相对简单。收藏表是一个典型的多对多关系中间表，记录用户ID和景点ID的对应关系，设置唯一联合索引防止重复收藏。出行笔记表则冗余存储了景点名称和用户名，避免每次查询笔记列表都要关联两张表，以空间换时间提升列表接口的响应速度。

2.2 SpringBoot核心配置与MyBatis整合

SpringBoot的配置集中在application.yml文件里，看起来简单，但有三个地方容易踩坑。第一个是数据源配置，MySQL 8.0以上版本必须显式加上serverTimezone=Asia/Shanghai，不然连接数据库时会报时区错误。第二个是MyBatis的驼峰映射，如果不开启map-underscore-to-camel-case: true，数据库的spot_name字段就映射不上spotName属性。第三个是JSON序列化时的时间格式，SpringBoot默认把Date序列化成时间戳，前端拿到的是长数字，很不友好，需要配置jackson的date-format。

我最终的配置核心片段如下：

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

mybatis:
  mapper-locations: classpath:mapper/*.xml
  type-aliases-package: com.travel.entity
  configuration:
    map-underscore-to-camel-case: true
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

mapper-locations决定了MyBatis去哪里找XML文件，type-aliases-package让实体类可以省略全限定名，log-impl配成StdOutImpl后控制台会直接打印SQL语句，开发阶段排查问题极其方便。项目上线时记得把log-impl去掉，不然打印大量日志会影响性能。

2.3 分页插件与通用返回结构

列表查询几乎一定需要分页，最常用的方案是PageHelper。这个插件的原理是拦截MyBatis的Executor，在执行查询前自动拼接LIMIT语句，同时执行一条COUNT查询统计总数，使用体验非常顺滑。引入依赖后只需要在查询方法前调用PageHelper.startPage(pageNum, pageSize)，紧跟其后的第一条查询就会自动分页。

java复制public PageResult<ScenicSpotVO> getSpotPage(int pageNum, int pageSize, String keyword, String city) {
    PageHelper.startPage(pageNum, pageSize);
    List<ScenicSpotVO> list = scenicSpotMapper.selectByCondition(keyword, city);
    PageInfo<ScenicSpotVO> pageInfo = new PageInfo<>(list);
    return PageResult.success(pageInfo.getList(), pageInfo.getTotal());
}

这里要注意PageHelper的分页是线程绑定的，startPage之后如果跟着多条查询语句，只有第一条会被分页。还有一种隐含风险是startPage没有匹配到查询接口就直接返回了，会让ThreadLocal里的分页参数残留，导致下一个请求出现意外的分页效果。我的做法是把分页参数包装在PageQuery对象里，由PageInterceptor统一处理，避免手动调用startPage带来的隐患。除了PageHelper，MyBatis-Plus也自带PaginationInnerInterceptor，如果你用的是Plus版本，用它自己的分页拦截器更合适，不需要再混用PageHelper。

3. 后端业务功能与核心接口实现

3.1 基于JWT的用户登录鉴权

系统分了普通用户和管理员，所以登录鉴权是必需的一环。没有鉴权，任何人都能调用后台接口把景点数据删光。我选用JWT（JSON Web Token）做无状态鉴权，相比传统Session方案，后端不需要维护会话状态，接口天然支持跨域和水平扩展。

登录流程是这样的：用户提交用户名密码，后端校验通过后生成一个JWT字符串返回给前端。JWT中包含用户ID、用户名、角色等关键信息，用HMAC-SHA256算法加上密钥签名。前端拿到Token后存在localStorage里，每次发请求都在Authorization请求头带上Bearer token。

拦截器负责统一放行白名单接口，其他接口全部校验Token。白名单包括登录接口、注册接口、景点列表查询接口、景点详情接口。校验通过后把用户信息放到ThreadLocal里，后续业务代码直接用UserContext.getUserId()就能拿到当前登录用户。

java复制public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
    if (request.getMethod().equals("OPTIONS")) {
        return true;
    }
    String token = request.getHeader("Authorization");
    if (StringUtils.hasText(token) && token.startsWith("Bearer ")) {
        token = token.substring(7);
        try {
            Claims claims = Jwts.parser().setSigningKey(secretKey).parseClaimsJws(token).getBody();
            UserContext.set(claims);
            return true;
        } catch (Exception e) {
            throw new BusinessException(401, "登录已过期，请重新登录");
        }
    }
    throw new BusinessException(401, "未登录或Token为空");
}

这个拦截器核心就做三件事：放行OPTIONS预检请求（否则跨域请求会被挡下来）、校验Token是否有效、解析Token内容并保存用户上下文。很多初学者会把业务逻辑塞进拦截器里，这是不对的，拦截器只做鉴权，具体操作权限的判断要在Service层里做。

3.2 动态SQL实现景点多条件组合查询

景点列表是系统最核心的查询场景，需要支持按关键词模糊搜索、按城市筛选、按价格区间筛选，同时按评分排序。这种不确定用户会传入哪些参数的场景，就是MyBatis动态SQL最适合发挥的地方。

我用XML方式写了一个selectByCondition，用<where>标签配合<if>标签实现动态拼接条件。这个写法看起来简单，但避免了在Java代码里手动拼接SQL的繁琐和SQL注入风险。

xml复制<select id="selectByCondition" resultType="com.travel.entity.ScenicSpot">
    SELECT * FROM scenic_spot
    <where>
        <if test="keyword != null and keyword != ''">
            AND spot_name LIKE CONCAT('%', #{keyword}, '%')
        </if>
        <if test="city != null and city != ''">
            AND city = #{city}
        </if>
        <if test="minPrice != null">
            AND ticket_price &gt;= #{minPrice}
        </if>
        <if test="maxPrice != null">
            AND ticket_price &lt;= #{maxPrice}
        </if>
        AND status = 1
    </where>
    ORDER BY 
    <choose>
        <when test="sortField == 'score'">score DESC</when>
        <otherwise>create_time DESC</otherwise>
    </choose>
</select>

这里有几个非常值得注意的细节。第一是<where>标签会自动去掉第一个AND，所以不需要担心条件拼接时多出AND导致SQL语法错误。第二是>=和<=这种转义写法，XML里面直接写大于号小于号会解析报错，必须转义。第三是ORDER BY部分不能像WHERE条件那样用#{}占位，因为MySQL的ORDER BY子句不能参数化列名，只能用<choose>判断后拼接固定字符串，防止SQL注入。

3.3 MyBatis缓存机制与数据一致性

MyBatis自带一级缓存和二级缓存，这两个缓存机制如果不了解，很容易遇到“改了数据库却查不出新数据”的诡异问题。

一级缓存默认开启，作用范围是一个SqlSession，也就是一次数据库会话内。问题在于Spring整合MyBatis后，每次Mapper查询都在独立SqlSession中执行，一级缓存基本处于“形同虚设”的状态。更麻烦的是，如果你在同一个事务里执行了两次相同的查询，MyBatis会走缓存返回相同的结果，但此时另一个线程改了这条记录，第二次查询拿到的还是旧数据。解决这个问题最直接的方式是：需要实时数据查询的地方不要开事务，或者使用MyBatis-Plus的@Transactional时注意查询与更新不要混在同一个事务里。

二级缓存默认关闭，作用范围是Mapper命名空间。我建议这种管理系统直接关闭二级缓存，因为景点数据、路线数据都属于相对高频更新的数据，开启缓存后要么频繁清理缓存，要么面临各查询之间数据不一致的风险，收益远小于维护成本。如果确实需要缓存热点数据，比如首页景点推荐列表，更推荐在Service层用Redis做一层显式缓存，可控性更强。

3.4 文件上传与图片访问配置

旅游景点必须有图片，所以文件上传功能必不可少。我把文件上传设计成本地磁盘存储方式，上传接口接收MultipartFile，校验文件类型和后缀名，生成UUID作为新文件名避免重名冲突，然后存储到配置好的目录里。

图片访问是本项目踩坑比较多的地方。SpringBoot默认只暴露/static目录下的静态资源，上传到磁盘自定义目录的图片没办法直接通过URL访问。我的处理方案是自定义资源映射：

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/upload/**")
                .addResourceHandler("file:" + uploadPath + "/");
    }
}

这样前端就能通过http://localhost:8080/upload/xxx.jpg访问上传的图片了。还有一个细节是上传文件大小限制，SpringBoot默认单个文件最大只能传1MB，图片稍微大点就报错。需要在配置里把限制调大，我设置成了20MB，普通旅游图片完全够用。

4. Vue前端工程搭建与核心模块实现

4.1 Vue环境配置与工程结构

前端我用的Vue CLI构建工程，虽然Vite现在更快，但Vue CLI生态更成熟，各种教程资料也更多，对刚入门的开发者更友好。创建好工程后，核心依赖包括vue-router、axios、element-ui、vuex。

工程目录结构遵循了标准的按功能模块组织的方式：

text复制src/
├── api/               # 接口请求封装
├── assets/            # 静态资源
├── components/        # 公共组件
├── router/            # 路由配置
├── store/             # Vuex状态管理
├── views/
│   ├── admin/         # 后台管理页面
│   ├── spot/          # 景点相关页面
│   ├── user/          # 个人中心页面
│   └── Login.vue      # 登录页

Vue环境配置中容易出问题的是依赖版本不一致。Vue CLI默认创建的是Vue 3工程，Element UI却是配合Vue 2使用，这时你需要安装Element Plus而非Element UI。我一开始装成了element-ui，运行就报错，排查了半天发现是版本兼容问题。建议先确定Vue大版本，再匹配对应的UI库：Vue 2配Element UI，Vue 3配Element Plus。

4.2 路由设计与参数传递

旅游出行指南系统的页面结构不算复杂，但路由参数传递用得很频繁。景点列表页点击某个景点卡片跳转到详情页，这是典型的用query方式传参的场景，详情页URL看起来是/spot/detail?id=18，刷新页面参数不会丢。

javascript复制// 列表页跳转详情
this.$router.push({
  path: '/spot/detail',
  query: { id: row.id }
})

// 详情页接收参数
const id = this.$route.query.id

除了query传参，路由守卫是另一个重要的点。后台管理页面必须在登录状态下才能访问，通过全局前置守卫统一判断：

javascript复制router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token')
  if (to.meta.requiresAuth && !token) {
    next({ path: '/login', query: { redirect: to.fullPath } })
  } else {
    next()
  }
})

这样设置的好处是，登录成功后可以跳转到用户原本想访问的页面，而不是固定跳回首页。

4.3 Axios封装与前后端联调

axios在项目中都要做一层统一封装，不然每个请求都写一遍完整配置，出了错也不知道去哪查。我的封装思路是：创建axios实例设置基础URL和超时时间，请求拦截器里给所有请求自动带上Token，响应拦截器统一处理返回结构。后端接口统一返回{ code, message, data }结构，code为200代表成功，401代表未登录，500代表服务器异常。

javascript复制const service = axios.create({
  baseURL: '/api',
  timeout: 10000
})

service.interceptors.request.use(config => {
  const token = localStorage.getItem('token')
  if (token) {
    config.headers['Authorization'] = 'Bearer ' + token
  }
  return config
})

service.interceptors.response.use(
  response => {
    const res = response.data
    if (res.code === 200) {
      return res
    } else if (res.code === 401) {
      localStorage.removeItem('token')
      router.push('/login')
      return Promise.reject(new Error('未登录'))
    } else {
      Message.error(res.message)
      return Promise.reject(new Error(res.message))
    }
  },
  error => {
    Message.error('网络异常，请稍后重试')
    return Promise.reject(error)
  }
)

前后端联调时最常遇到的就是跨域问题。前端开发服务器跑在8080端口，后端跑在8088端口，浏览器会拦截跨域请求。解决方式有两种：后端加CORS配置，或者前端配置代理。我选择了前端代理方案，在vue.config.js里配置：

javascript复制module.exports = {
  devServer: {
    proxy: {
      '/api': {
        target: 'http://localhost:8088',
        changeOrigin: true,
        pathRewrite: { '^/api': '' }
      }
    }
  }
}

这样前端请求/api/spot/list会被代理转发到后端/spot/list，浏览器看到的是同源请求，不会触发跨域限制。

4.4 景点列表与详情页面的组件化实现

景点列表页面是前台的核心页面。我设计了几个关键组件：SearchBar负责条件筛选、SpotCard负责单个景点展示、PaginationBar负责分页。父组件管理筛选条件和分页状态，子组件通过$emit事件把用户操作反馈给父组件。

景点卡片组件接收spot对象作为props，展示景点封面图、名称、城市、门票价格和评分。评分用Element Plus的el-rate组件展示，价格部分做了空值兜底，ticket_price为0时显示“免费”。

景点详情页则是一个信息组合页面，上半部分是图片轮播和景点基本信息，下半部分是出行笔记、评论列表。这里用到了v-if和v-loading配合处理异步加载状态，数据还没返回时展示loading动画，返回后渲染内容，拦截器捕获到401时自动跳转登录页。

5. 核心功能模块与业务场景落地

5.1 用户收藏与“我的足迹”功能

收藏功能的链路比较长：用户在景点详情页点击收藏按钮，前端携带景点ID和当前用户ID调用后端收藏接口，后端先检查是否已收藏，未收藏则插入记录，已收藏则给出提示或执行取消收藏。

我的后端实现思路是提供了一个toggleFavorite接口，用一条SQL完成“插入或删除”的判断逻辑。具体做法是先用select count查是否已存在记录，存在则delete，不存在则insert。这个接口在高并发场景下其实有并发问题，两个请求同时进来都判断未收藏，就会插入两条重复记录。解决方法是靠数据库的唯一索引兜底，插入重复时捕获DuplicateKeyException，给用户返回“已收藏”。

“我的足迹”页面本质上是当前用户的收藏列表，核心SQL是一个联表查询：user_favorite关联scenic_spot，按收藏时间倒序。加上分页和实时删除功能后，和普通列表页的实现思路一致。

5.2 后台管理端的数据维护功能

后台管理端的功能比较标准，围绕数据维护展开。管理员登录后进入管理首页，左侧菜单有景点管理、路线管理、笔记管理、用户管理、数据统计五个模块。

景点管理页面用了Element Plus的el-table展示数据，每行提供编辑和删除按钮，顶部是搜索框和“新增景点”按钮。弹窗表单用el-dialog和el-form实现，表单校验规则用rules属性配置，比如景点名称必填、门票价格不能为负数。图片上传则用el-upload组件，把文件先传后拿URL，再和其他字段一起提交。

数据统计页面是系统中比较出彩的部分，用ECharts展示各城市景点数量分布饼图和用户收藏趋势折线图。后端提供统计接口，一条group by city的SQL就能拿到各城市的景点数量，再一条按日期统计收藏数量的SQL，前端拿到数据后直接渲染成图，整个过程很顺。

5.3 数据统计报表的SQL实现

统计接口是后台管理系统中比较考查SQL基本功的地方。比如统计各城市的景点数量，一条分组查询就能搞定：

sql复制SELECT city, COUNT(*) AS spotCount 
FROM scenic_spot 
WHERE status = 1 
GROUP BY city 
ORDER BY spotCount DESC

统计用户收藏趋势则要稍微绕一下，收藏表里记录了收藏时间，只需要按日期分组：

sql复制SELECT DATE(create_time) AS collectDate, COUNT(*) AS collectCount
FROM user_favorite
WHERE create_time >= #{startDate}
GROUP BY DATE(create_time)
ORDER BY collectDate ASC

这类统计接口千万不要在Java代码里循环查询数据库，能一条SQL出的就一条SQL出，不然接口响应时间会随着数据量增长变得越来越慢。

6. 常见问题与排查技巧实录

整个项目开发过程中，我遇到了不少让人头疼的问题，下面把其中最具代表性的几个整理成速查表，再挑几个典型的展开讲讲。

先说一个比较隐蔽又常见的坑。MyBatis控制台打印SQL显示查询出了数据，但前端看到接口返回的total只有10，翻到第2页就没有数据了。排查后发现问题出在PageHelper startPage和查询之间隔了其他逻辑，导致分页被应用到了不正确的SELECT上。比如下面这种写法就很危险：

java复制Map<String, Object> map = new HashMap<>();
list = mapper.selectList(map);  // 这条查询先执行了，占用了分页
PageHelper.startPage(1, 10);
List<Spot> spots = mapper.selectByCondition(condition);  // 这条反而没分页

解决方法是把PageHelper.startPage放在目标查询的前一行，中间不要插入任何查询逻辑，这样分页参数才能准确作用于目标SQL。

再说一个关于MyBatis @Update 执行慢的问题。有阵子笔记的浏览量更新接口响应非常慢，排查发现这条UPDATE语句没有走索引，WHERE条件是用户ID，而这个字段在表里没有建索引。每次更新都要全表扫描，数据量一上去性能就崩了。给用户ID加上普通索引后，耗时从700ms降到了10ms以内，效果立竿见影。这也提醒我，表设计阶段就要考虑WHERE条件里出现频率高的字段，提前建好索引。

还有就是在开发初期，景点列表接口的响应速度还能接受，但在导入了2000条测试数据后明显变慢。用EXPLAIN SELECT * FROM scenic_spot WHERE city='杭州'查看执行计划，发现type是ALL，说明是全表扫描。原因就是建表时漏了city索引。这种问题用EXPLAIN一眼就能看出执行计划的问题，强烈建议每位开发者养成分析慢SQL时先跑一遍EXPLAIN的习惯。

7. 项目优化方向与个人经验总结

系统完工后我又做了一轮优化，主要从性能和体验两方面入手。

性能层面，景点详情接口增加了Redis缓存，以景点ID为key缓存热点数据，缓存命中时直接返回，大大减轻了数据库压力。列表查询的SQL也做了优化，把原先的SELECT *改成只查询列表页需要的字段，减少了网络传输量。后台管理端的统计接口在数据量变大后改用定时任务提前聚合，避免用户打开统计页时现算导致接口超时。

体验层面，前台页面做了响应式适配，手机上访问也能正常展示。景点列表的加载做成了触底加载更多的方式，比传统的点击翻页在移动端体验更好。另外增加了全局404页面和统一异常提示，用户操作出错时能看到具体的提示文案，而不是白屏或者浏览器默认的错误信息。

根据我个人实际操作中的体会，做这类管理系统最大的收获不是某个技术点本身，而是掌握了从需求分析到落地实现的全流程能力。比如用户说“要一个旅游指南”，你得能拆解出景点管理、路线规划、收藏互动、后台统计这些具体功能；数据库设计时要想清楚表之间怎么关联，哪些字段适合建索引；接口设计时要考虑返回结构是否统一、异常怎么处理。这些能力是代码之外更重要的东西。

最后再分享一个小技巧。前后端联调阶段不要等全部接口写完了再开始，最好后端先跑通最核心的三个接口（景点列表、景点详情、登录），前端马上就开始对接，联调中发现的接口字段问题、状态码问题越早暴露越好处理。这套项目的源码和解压后的部署包我都整理好了，跟着本文的步骤和代码思路，你也可以完整地把这个旅游出行指南管理系统从零搭起来。