企业官网建设流程全解析

这段时间帮某同学调了一个基于SpringBoot+Vue的文旅网站管理系统，项目名挂的正是“七彩云南文化旅游网站管理系统”，后端Java+SpringBoot+MySQL+MyBatis，前端Vue全家桶。把源码从头到尾梳理、跑通、修完bug，前后花了一周多。说实话，这类项目在高校毕设里出现频率极高，因为它的业务链路完整、技术覆盖面广、代码量又控制在合理范围，非常适合用来展示全栈开发能力。

本文不打算只贴一段“源码已上传”就完事，而是把整个项目从选题逻辑、技术选型、数据库设计、后端接口、前端页面到部署排查讲清楚。无论你是准备拿它当毕业设计，还是想通过一个完整项目练手Java全栈，又或者接手了一套类似的源码不知道怎么快速上手，都可以按这篇文章的思路走一遍。很多坑我在调试时已经踩过了，你照着我总结的路径来，能省下大量无谓的排查时间。

1. 项目定位与整体技术架构

1.1 这个选题为什么值得做，以及功能边界怎么划

很多同学一开始就想做电商系统，但电商涉及支付回调、复杂库存、多级分销等内容，作为个人项目很难在限定时间内做深做透，答辩时反而容易暴露短板。文旅网站管理系统不一样，它的业务主链路非常清晰：用户浏览目的地内容，查看旅游线路和酒店美食，登录后下单并发布评论；管理员在后台维护资源、处理订单、审核评论。整条链路涉及“用户端+管理端”双端结构，既能体现前端页面组织能力，又能覆盖后端常见业务逻辑。

更重要的原因是数据模型高度自然。用户、景点、线路、酒店、美食、订单、评论这些实体之间的关联关系是现成的，不需要硬造业务场景。你在设计表结构时，每一步都能用业务逻辑解释清楚，比如订单为什么要存资源名称和价格快照，评论为什么要设置审核状态，这些都是答辩时的高频提问点。

功能边界上我建议控制好范围，不要一上来就规划十几个模块。核心功能可以锁定为七个：用户注册登录、首页展示、资源列表与搜索、资源详情、下单管理、个人中心、后台管理。其余像收藏、统计报表、评论审核这些属于加分项，等主链路跑通后再逐步补。项目迭代的顺序应该是“能跑通主链路”优先于“功能数量多”。

1.2 技术栈选型：SpringBoot、Vue、MySQL、MyBatis各自承担什么

SpringBoot在这个项目里主要负责后端服务落地。它内嵌Tomcat、自动完成大量Spring配置，通过Starter机制引入web、事务、参数校验等能力，让开发者把精力集中在业务代码上。相比传统的SSH或者手写Servlet，SpringBoot的开发效率和排错成本都友好太多，尤其适合周期有限的个人项目。

MyBatis则负责数据访问层。选择MyBatis而不是完全用JPA，核心原因是动态SQL非常灵活。文旅网站的资源列表页通常需要多条件组合筛选，按关键词、分类、价格区间、热度排序，这些SQL用注解写会很别扭，但放进MyBatis的XML里用<where>和<if>标签配合，逻辑非常直观。同时手写SQL也能让你对每一条查询语句都心中有数，答辩时能讲出细节。

前端Vue承担用户端和管理端的页面交互。组件化开发让页面结构清晰，Element UI组件库可以快速搞定表格、表单、弹窗、轮播这些常见元素。MySQL则承载业务数据，InnoDB引擎在订单和事务操作上足够可靠，对于单项目规模来说完全够用。整套技术栈没有冗余，每个环节都是当前中小型全栈项目的主流配置。

为什么不推荐前后端不分离的模板方案？因为现代开发和部署习惯越来越倾向前后端分离，管理端和用户端可以独立演进、独立部署。即便只是毕设，采用前后端分离也能让项目看起来更接近真实工程。

1.3 用户端、管理端与角色权限怎么划分

角色划分是这类系统最先要明确的事，我建议把角色分为三类：未登录游客、登录用户、后台管理员。

游客可以访问首页、资源列表、资源详情，可以搜索和筛选，但不能下单、不能评论。登录用户可以补充头像昵称、下单、查看自己的订单、发布评论、收藏内容。管理员则有一套独立后台，可以维护景点、线路、酒店、美食等资源数据，处理订单状态，审核评论和用户管理。

管理端的实现有两种常见方式：一种是单独构建一个admin项目，另一种是在同一个Vue项目里按路由区分用户端和管理端。考虑到毕设的代码量和部署成本，更推荐后者。路由层面用不同的目录区分views/client和views/admin，后端接口统一放在/api前缀下，管理端接口放在/api/admin前缀下，通过后端拦截器针对不同路径做权限校验。这样既节省一套工程的维护成本，又能清晰表达权限边界。

权限控制的细节会在第三章展开，这里先提一个容易忽略的点：管理端接口不能只靠前端隐藏入口来保护，后端必须对/admin/**路径做角色校验，否则任何人直接拼接接口地址就能操作数据。

2. 数据库设计：表结构、字段与关联关系

2.1 核心表清单与整体ER关系

我先列一套经过实际项目验证的表清单，共10张核心表：

这套表设计的核心思路叫“业务动作驱动”。不是按照页面有多少个版块就建多少张表，而是根据核心业务动作来建模：用户要下单，就需要订单表；用户要发表评价，就需要评论表；管理员要维护展示内容，就需要资源表。轮播图管理放一张独立表，是因为首页展示位需要随时上下架和排序，把它从普通资源表中拆出来更灵活。

资源表虽然分为景点、线路、酒店、美食四张，它们之间也有关联。例如一条旅游线路通常包含多个景点，酒店和美食可以作为线路行程的一部分被推荐。如果项目周期充裕，可以增加关联表表达“线路-景点”多对多关系；如果周期紧张，在线路表的行程字段中用逗号或JSON保存景点引用也是一个可选方案。前期建议先不做复杂关联，把主流程打通再考虑扩展。

2.2 用户类表：密码安全与登录凭证

user表和admin表建议分开设计，不要共用一个表再通过角色字段区分。分开设计能让管理端的权限校验更简单，也避免把两类不同性质的数据混在一起。user表核心字段如下：

• id：主键，自增
• username：登录账号，唯一索引
• password：加密后的密码串
• nickname：昵称
• phone：手机号
• avatar：头像相对路径
• create_time：注册时间
• delete_flag：逻辑删除标记

密码存储是一个高频答辩问题。实际项目中绝不能把明文密码放进数据库，否则数据库一旦泄露所有账号全部暴露。常用做法是使用BCrypt或者加盐MD5。我用的是Md5加盐方案：注册时将密码加固定盐（或者用户相关盐）后进行多次摘要计算，登录时用相同规则计算后比对。之所以不用Session保存登录态，是因为前后端分离场景下Session的跨域和集群支持比较麻烦，后面会改用JWT方式。

admin表可以简单一些，字段包括id、username、password、create_time。初始化时准备一条默认管理员账号即可，不需要做复杂的注册入口。注意管理员密码也需要加密存储，不要因为“本机自己用”就放松警惕。

2.3 目的地资源表：景点、线路、酒店、美食

资源表是整个网站的“货架”，游客所有的浏览行为最终都落在这些数据上。四张表的字段有共性，也各有差异。以scenic景点表为例：

• id：主键
• name：景点名称
• cover_image：封面图相对路径
• detail_images：详情图集合，使用JSON数组或逗号分隔路径
• intro：一句话简介
• content：图文详情正文
• tags：标签，如“自然风光”“人文历史”，多个标签逗号分隔
• price：参考价格或门票价格
• heat：热度值，用于热门推荐排序
• status：上下架状态，1上架0下架
• create_time：创建时间

travel_line线路表需要额外增加day_count天数、trip_schedule行程安排、line_price线路价格等字段。hotel表要加address位置、room_price房价、facility设施服务。food表要加cuisine_type菜系、per_capita_price人均消费。四张表都保留status字段，只有status为1时才会出现在前端列表，避免下架内容被游客访问。

这里有一个常见的表设计误区：为每张资源表都建一张图片子表。从规范化的角度看这确实更标准，但实际项目中处理起来很繁琐，前端要多发多次请求拼接图片列表，管理端上传图片的逻辑也会复杂很多。如果每张资源表的图片数量是固定的、有限的，直接在资源表里存图片集合会更实用。搜索结果页和详情页都能一次查询拿到需要的数据，性能也更好。

2.4 订单表：状态流转与快照设计

订单表是整个系统里业务逻辑最集中的地方，设计时需要同时考虑状态管理、数据可靠性和查询效率。核心字段如下：

• id：主键
• order_no：订单编号，唯一索引
• user_id：下单用户ID
• resource_type：资源类型，如scenic、travel_line、hotel、food
• resource_id：对应资源ID
• resource_name：资源名称冗余字段
• resource_image：资源封面冗余字段
• price：下单时单价
• num：购买数量
• total_price：总价
• status：订单状态，0待支付、1已支付、2已完成、3已取消
• create_time：下单时间
• pay_time：支付时间

特别说明一下“冗余”的意图。订单表里保存resource_name和price，目的是保留下单瞬间的用户所见信息。如果这些字段不从资源表冗余进来，那么景点改名、价格调整或资源删除后，历史订单显示就会出错。这是电商系统里非常典型的快照设计思想，也是面试官常问的一个点。

订单状态的流转需要遵循顺序，不能从待支付直接跳到已完成。最简单可靠的实现方式是后端Service层里定义状态更新方法，每次更新前校验当前状态是否允许走到目标状态。不需要引入复杂状态机框架，但状态判断逻辑必须集中管理，不要散落在各个Controller里。

2.5 评论、收藏与轮播图表

评论表结构相对简单，但仍要处理好“一对多”的关联关系。字段包括id、user_id、resource_type、resource_id、content、rating、status、create_time。其中status用于审核控制，默认0待审核，管理员在后台审核后置为1可见，违规内容可置为2隐藏。这个字段让管理端多了一个可操作的业务动作，也给答辩增加了讨论点。

收藏表favorite记录用户收藏行为，字段为id、user_id、resource_type、resource_id、create_time，并在user_id和resource_type、resource_id上建立唯一索引来防止重复收藏。banner轮播图表保存首页轮播位置、图片路径、跳转链接、排序值和状态。如果不想维护banner管理功能，也可以在前端写死轮播数据，但从系统完整性的角度，建议保留后台配置能力，这也算一个管理端功能点。

2.6 索引策略与常见设计误区

数据库表建好后，一定要根据查询场景补索引，否则数据量上来后接口响应会很慢。我梳理了项目里最重要的几个索引：

• user表的username唯一索引
• orders表的order_no唯一索引
• orders表的user_id索引
• orders表的status索引
• comment表的resource_type和resource_id联合索引
• scenic表的heat索引，用于热门推荐排序

物理外键我建议不加。在早期开发阶段，物理外键会影响批量删改数据，也会造成驱动层不必要的约束开销。表之间的关联关系通过代码逻辑和索引来维护，逻辑外键足够满足项目需要。

另一个常见误区是逻辑删除字段的处理。用户数据和资源数据不要用物理删除，加一个delete_flag字段，默认0，执行删除时改为1，查询条件统一加上delete_flag = 0。这样即使误删也能恢复数据，这个习惯能让你在项目上线后省下很多麻烦。

3. 后端SpringBoot+MyBatis：核心接口与关键机制

3.1 工程结构与依赖清单

后端工程我建议按标准分层结构组织，区分entity、mapper、service、controller、config、utils这些包。这样做的好处是职责清晰：Controller层只负责参数接收和响应封装，Service层存放业务规则，Mapper层只做数据访问。哪怕是一个小项目，这样的分层也能在很大程度上避免代码失控。

pom.xml里需要引入的核心依赖大致如下：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.0</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency>

分页插件用的是PageHelper，引入pagehelper-spring-boot-starter后在Service层调用PageHelper.startPage(pageNum, pageSize)即可完成分页。application.yml中需要配置数据库连接、MyBatis的mapper位置以及相关参数：

spring: datasource: url: jdbc:mysql://localhost:3306/travel_web?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai username: root password: yourpassword mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.travel.entity

数据库连接串里一定要加上characterEncoding和serverTimezone，否则中文乱码和时区问题会折磨你半天。

3.2 登录认证：JWT、拦截器与密码加密

前后端分离项目最常用的登录认证方案是JWT，原因在于它天然无状态。用户登录成功后，后端生成一个包含用户信息的Token返回给前端；前端在后续请求的请求头中携带Token；后端通过拦截器校验Token的合法性并解析出当前用户身份。不需要Session，不需要在服务端保存登录状态，天然适配前后端分离和水平扩展场景。

JWT的核心代码可以封装成一个工具类，生成和解析Token的逻辑集中在同一个地方：

public class JwtUtil { private static final String SECRET = "your-secret-key"; private static final long EXPIRE_TIME = 7 * 24 * 60 * 60 * 1000; public static String createToken(Integer userId, String role) { return Jwts.builder() .claim("userId", userId) .claim("role", role) .setExpiration(new Date(System.currentTimeMillis() + EXPIRE_TIME)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser().setSigningKey(SECRET).parseClaimsJws(token).getBody(); } }

拦截器要解决两个问题：哪些路径需要登录，哪些路径需要管理员权限。我通常的做法是创建两个拦截器，一个校验用户Token是否有效，另一个在校验用户基础上额外校验role是否为admin。注册拦截器时把放行路径显式配置出来，例如登录、注册、首页、资源列表、资源详情都不需要登录，下单、评论、个人中心需要登录，/admin/**全部需要管理员权限。

密码加密在注册时处理。用户提交明文密码后，后端使用加密工具类生成摘要存入数据库；登录时对输入密码做相同处理，再与数据库比对。账号密码验证通过后签发Token，前端保存Token用于后续身份认证。

3.3 列表分页与多条件筛选：动态SQL实战

资源列表页是网站最核心的展示页面，它同时要处理分页、关键词搜索、分类筛选、价格区间筛选、排序规则，是最能体现MyBatis动态SQL能力的地方。以景点列表查询为例，Mapper XML的核心实现如下：

<select id="selectScenicPage" resultType="com.example.travel.entity.Scenic"> select * from scenic <where> delete_flag = 0 and status = 1 <if test="keyword != null and keyword != ''"> and (name like concat('%', #{keyword}, '%') or tags like concat('%', #{keyword}, '%')) </if> <if test="category != null and category != ''"> and tags like concat('%', #{category}, '%') </if> <if test="minPrice != null"> and price &gt;= #{minPrice} </if> <if test="maxPrice != null"> and price &lt;= #{maxPrice} </if> </where> <choose> <when test="sort == 'heat'"> order by heat desc </when> <otherwise> order by create_time desc </otherwise> </choose> </select>

这样设计的好处是查询参数可组合、可扩展。用户不输入任何条件时，SQL自动退化为普通分页查询；输入关键词后，查询条件自动拼接；传了价格区间，查询条件也自动加入。<choose>标签用于处理多种排序规则的切换。

分页使用PageHelper插件后再注意一点：PageHelper.startPage()必须紧跟第一条查询语句，中间不要插入其他查询，否则分页参数会作用到错误的位置。查询完数据后用PageInfo包装结果再返回给前端，里面已经包含总记录数和分页信息，不需要自己写count语句。

3.4 下单流程：事务、库存扣减与重复提交

下单接口是最容易出bug的地方，需要同时考虑事务一致性和并发安全。一次完整的下单流程包含：校验用户登录状态，根据resource_type和resource_id查询对应资源，检查资源是否上架，计算总价，创建订单记录，扣减库存，返回订单信息。这一步涉及多个数据操作，必须使用@Transactional确保原子性：

@Transactional(rollbackFor = Exception.class) public Order createOrder(OrderRequest request) { Scenic scenic = scenicMapper.selectById(request.getResourceId()); if (scenic == null || scenic.getStatus() != 1) { throw new ServiceException("资源不存在或已下架"); } Order order = new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(request.getUserId()); order.setResourceType(request.getResourceType()); order.setResourceId(scenic.getId()); order.setResourceName(scenic.getName()); order.setPrice(scenic.getPrice()); order.setNum(request.getNum()); order.setTotalPrice(scenic.getPrice() * request.getNum()); order.setStatus(0); orderMapper.insert(order); int count = scenicMapper.reduceStock(scenic.getId(), request.getNum()); if (count == 0) { throw new ServiceException("库存不足"); } return order; }

库存扣减语句使用条件更新方式防止超卖：

update scenic set stock = stock - #{num} where id = #{id} and stock >= #{num}

如果更新影响行数为0，说明库存不足或资源状态有变，直接抛出异常让事务回滚。这种写法在并发场景下比先查后改更可靠，也是很多真实项目里采用的方案。

防止重复提交可以在前端做按钮loading控制，但更可靠的是后端增加幂等判断。简单做法是记录订单来源的token或业务编号，如果同一用户对同一资源在短时间内存在相同业务编号的待支付订单，则拒绝再次创建。这个小细节可以在答辩时重点提。

3.5 文件上传与静态资源映射

文旅网站的景点、线路、酒店都需要上传图片，文件上传接口是一个绕不开的基础功能。后端接口接收MultipartFile文件流，校验文件大小和扩展名，把文件写入本地磁盘指定目录，文件名使用UUID或时间戳重命名，避免中文文件名和重复文件名带来的问题。上传成功后返回相对路径，例如/upload/20240715/xxx.jpg。

文件写入本地后，还要配置静态资源映射才能让前端可以访问。在WebMvcConfigurer实现中，把磁盘路径映射到URL路径：

@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:D:/travel-upload/"); }

这个配置是图片404问题的高发区。尤其是部署到Linux服务器后，路径分隔符、目录是否存在、映射是否生效都会影响图片访问。我的建议是上传目录独立配置在application.yml里，部署时只需修改一个配置项，不要写死在代码中。文件上传还应该限制类型和大小，避免项目被上传恶意文件。

4. 前端Vue：页面实现与前后端联调

4.1 工程搭建与目录规划

前端工程基于Vue CLI创建，在已有脚手架基础上安装vue-router、vuex、axios和element-ui。前三者是Vue生态的基础设施，element-ui用来快速搭建后台管理界面的表格、表单、弹窗组件。工程目录建议保持清晰：

src ├── api // 接口定义 ├── assets // 静态资源 ├── components // 公共组件 ├── router // 路由配置 ├── store // Vuex状态管理 ├── utils // 请求封装、工具函数 └── views ├── client // 用户端页面 └── admin // 管理端页面

api目录单独存放接口定义，而不是在页面组件中直接调用axios，这样可以集中管理接口路径和请求参数。比如src/api/scenic.js里定义getScenicList(data)、getScenicDetail(id)等函数，页面组件只需要引入并调用。项目接口路径调整时，只需要修改一处，不会全局污染。

4.2 Axios封装与登录态管理

Axios需要在请求发出前统一注入Token，在响应返回后统一处理错误状态码。封装一个request.js是所有前后端分离项目的基础工作：

import axios from 'axios' import { Message } from 'element-ui' import router from '@/router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { Message.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } Message.error('网络异常，请稍后重试') return Promise.reject(error) } ) export default request

登录成功后，后端返回的Token存到localStorage，用户信息存到Vuex。刷新页面时，Vuex中的用户信息会丢失，所以还需要在应用初始化时读取一次登录状态。可以在路由守卫中检查Token和路由元信息，判断当前路由是否需要登录权限。

4.3 首页、列表页、详情页实现思路

首页的重点是模块化展示。轮播图用el-carousel渲染banner数据，热门推荐用卡片网格展示热度最高的景点和线路，分类入口用图标导航跳转到对应列表页。每个模块可以拆成一个独立组件，父组件负责拉取数据后分发。首页的加载体验很重要，接口还在请求时用v-loading给区块加加载态，避免页面出现大面积空白。

列表页要处理搜索表单和分页组件。搜索表单通常包含关键词输入、分类下拉、价格区间和排序选项。搜索参数变化后重新请求列表数据，分页组件当前页码需要同步。更进一步的做法是把分页和筛选参数同步到URL的query参数中，刷新页面后状态不丢失，这个体验细节很加分。列表项展示的资源卡片要包含封面图、名称、简介、价格和标签，点击后跳转详情页。

详情页根据路由参数id请求接口，展示封面大图、资源名称、标签、价格以及图文详情。图文详情字段在数据库中通常是富文本HTML或者带格式的长文本，前端可以用v-html渲染。使用v-html时要注意XSS风险，如果内容是后台管理员录入的可信内容，问题不大，但加入基本的内容过滤更加稳妥。

4.4 下单流程、个人中心与后台CRUD

用户端下单选好资源后跳转确认订单页面，确认数量、总价，点击下单按钮后调用后端创建订单接口。下单成功后跳转到我的订单列表，用户可以看到待支付、已支付、已取消等状态的订单。这里需要为订单列表增加状态筛选tab，不同状态显示不同操作按钮，如待支付可以取消，已支付可以查看详情。

个人中心页面展示当前用户信息、我的订单、我的收藏、我的评论。用户信息区域支持编辑昵称和头像，我的收藏展示收藏的资源卡片，点击可跳转详情。若需要使用ECharts统计图表，可以在管理端加入用户访问量或订单量统计，管理端整体以el-table展示数据列表、el-dialog嵌表单实现新增和编辑、el-switch实现上下架切换。这些操作完成后统一刷新表格数据，保持界面同步。

4.5 跨域问题与联调配置

前后端分离后，跨域问题是联调阶段最常遇到的。开发环境推荐使用Vue CLI的devServer代理，前端请求仍写相对路径，由devServer把请求转发到后端服务：

module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }

生产环境下不使用devServer，由Nginx统一处理前端静态文件和后端接口转发。后端虽然也可以配置CorsFilter放开跨域限制，但生产环境更推荐把跨域处理交给Nginx或者同域部署，这样后端的地址不会暴露给浏览器端，也更安全。

5. 打包部署、问题排查与避坑总结

5.1 从本地到服务器：打包与Nginx部署

部署流程大致分三步。第一步后端打包：在项目根目录执行mvn clean package -DskipTests，生成可执行的jar文件。第二步前端构建：在frontend目录执行npm run build，生成dist静态文件目录。第三步是服务器配置：把jar文件上传到服务器，使用java -jar travel-web.jar启动后端，把dist目录上传到Nginx的html目录，配置Nginx做静态文件服务和接口反向代理。

Nginx配置的关键片段如下：

server { listen 80; server_name your-domain.com; location / { root /opt/travel-web/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

这里有一个SPA部署的经典坑：Vue路由使用history模式时，刷新某个子页面会返回404，因为Nginx找不到对应的物理路径。try_files $uri $uri/ /index.html的作用就是把所有未命中的请求全部回退到index.html，让前端路由接管。如果你使用的是hash模式，则不需要这个配置。

数据库导入时还要注意字符集问题。创建数据库时使用default charset utf8mb4，导入SQL文件时设置同样的字符集，否则中文可能出现乱码。Linux服务器上还要留意数据库大小写敏感问题，表名和字段名尽量统一使用小写，避免大小写不一致导致连接失败。

5.2 高频报错与排查方法速查表

我把项目调试和部署过程中遇到的高频问题整理成一张速查表，方便你对照处理：

排查问题时最忌讳“瞎改”。正确的方式是先看后端控制台日志，找到第一行异常信息；再看前端Network面板，确认是请求没发出去、后端报错还是响应格式异常；最后按异常堆栈定位到具体代码行。日志里真正的错误信息通常在前三行，别被大段堆栈吓住。

5.3 除了能跑之外：性能与安全的几个关键点

功能跑通之后，还需要花一点时间做性能和安全的加固，这些内容在项目文档和答辩中都是加分项。

性能方面，列表接口只查询当前页面需要的字段，不要把详情大字段带进列表查询。如果查询SQL里使用了select *，建议改为显式字段列表。首页的热门推荐、轮播图这类热点数据可以加一层Redis缓存；如果不引入Redis，也可以用本地内存做一个定时刷新的简单缓存，效果也明显。查询次数频繁的接口务必确认索引是否生效，用explain查看执行计划是快速验证手段。

安全方面，至少要做四件事：一是用户输入参数校验，后端在接收参数时校验非空、长度和格式，不能只依赖前端限制；二是SQL注入防护，MyBatis的#{}自动处理参数转义，但${}拼接要避免，尤其不能把用户输入直接拼进SQL；三是接口权限校验，所有管理端接口必须在后端拦截器中校验管理员身份；四是文件上传安全，限制扩展名、文件大小和保存目录权限。这些措施都不需要太多额外代码，但能把项目的安全等级提升一个档次。

5.4 接手源码后我建议按这条链路先跑一遍

如果你拿到的不是自己从头写的源码，而是别人已经写好的工程，建议不要急着“看代码”，先按以下顺序在本地把项目跑通：导入SQL脚本、改数据库配置、启动后端、启动前端、注册新账号、登录、浏览资源列表、查看详情、下一笔订单、到后台确认订单、发布评论并审核。整条链路走完，你就能确认环境配置正确、核心功能可运行，后面熟悉代码就有的放矢了。

在我的经验里，很多人拿到源码后先从控制器开始逐行阅读，读了两天还在模块之间绕来绕去，效率很低。比较高效的做法是从数据表入手：先看表关系，再看订单和资源的核心状态流转，最后按一个具体请求把Controller、Service、Mapper三层代码串一遍。比如“用户点击景点列表后发生了什么”这个问题能完整回答，你就基本掌握这个项目了。

调试项目时还遇到过一些很琐碎但容易卡住的细节：MySQL版本不同导致驱动类名不同、JDK版本与SpringBoot版本不匹配、前端依赖没装全导致编译失败。建议环境统一用JDK1.8、MySQL5.7或者8.0、Node14以上，遇到版本问题优先查官方文档确认兼容性。把基础运行环境搞定，后续开发会顺畅很多。