前后端分离的论坛/推荐站项目，我做过不少，但一个能同时覆盖热门网游推荐这个垂直场景、又完整跑通了SpringBoot + Vue + MyBatis + MySQL这套主流技术栈的可直接二次开发项目，确实值得拿出来认真聊聊。我最初拿到这套源码的时候，第一反应是它把“前后端分离”和“管理系统+展示网站”兼顾得比较好——既适合做毕业设计，也适合刚入行的朋友拿来系统性理解企业级项目的分层结构，更可以直接当作个人作品集里的实战项目。这篇文章我不打算只贴代码，而是从架构选型、数据库设计、核心接口实现、前端对接、再到部署上线，把整条链路拆开揉碎讲清楚，把我实际踩过的坑和排查思路也一并放进来，希望对正在做类似系统或者准备用这套技术栈练手的你有实际参考价值。

1. 项目整体拆解与选型思路

很多人在看到“前后端分离”这四个字的时候，往往只关注到“前端一个项目、后端一个项目”，但真正决定一个系统能否稳定跑起来、能否顺利扩展的，是对“分离”边界的把握。这个热门网游推荐网站系统，其实包含了两条主线：对外是游戏资讯和推荐内容的展示，对内是管理员对游戏条目、分类、推荐位、用户评论等的管理。两者天然适合拆分成不同端来做。

1.1 为什么是前后端分离

先说结论：面向展示型网站，前后端分离是当下性价比最高的方案，没有之一。原因并不复杂：

第一，展示端与业务端的迭代节奏不一样。前台推荐页要频繁调整展示样式、导航结构、推荐位排序，而后台管理系统的功能相对固定。如果二者耦合在同一个服务端渲染项目中，每一次小的前端改动都可能牵连控制器和模板逻辑，发布风险也被放大了。拆开以后，Vue负责全部交互和渲染，后端只负责稳定输出JSON。

第二，开发和调试的并行度更高。在一个团队里，前端同学和后端同学可以用一份接口文档并行开发，前端用Mock数据先跑界面，后端用Swagger/Postman自测接口，两边互不阻塞。即便是一个人全栈开发，分离之后的心智负担也小得多——改前端不用盯着Java代码，调接口问题也不会被模板引擎的报错干扰。

第三，部署和扩展更灵活。前端打包成纯静态资源，扔到Nginx里就行；后端是独立Java进程，随时可以水平扩展。如果后续访问量上来，只需要在后端前面加负载均衡，前端静态资源走CDN，整个系统的弹性就出来了。

1.2 技术栈选型的逻辑

这套系统选了SpringBoot做后端基础框架、Vue做前端框架、MyBatis做持久层、MySQL做存储。这四样东西单独看都很常见，但组合在一起恰好覆盖了一个典型Web业务系统的全部环节：

• SpringBoot：负责提供RESTful接口、依赖注入、事务管理、参数校验。它简化了Spring的配置，让开发人员把更多精力放在业务逻辑上。在这套系统里，它的核心职责是接收前端请求、调用Service层处理业务、操作数据库、返回统一格式的JSON。

• Vue：负责页面渲染和用户交互。它用组件化的方式组织页面，配合Vue Router做前端路由，配合Vuex/Pinia做全局状态管理，配合Axios做HTTP请求。对于这类包含首页展示、游戏详情、评论列表、后台管理表格的站点，Vue的响应式数据绑定能极大减少DOM操作的代码量。

• MyBatis：负责Java对象与数据库记录之间的映射。它比JPA/Hibernate更轻量，SQL由开发者自己控制，排查问题更直接。对于推荐网站这类需要大量自定义查询（比如按分类筛选、按评分排序、多条件模糊搜索）的业务场景，MyBatis的灵活性几乎是不可替代的。

• MySQL：负责数据持久化存储。它稳定、轻量、生态完善，对于这个项目量级的并发和数据量完全够用。配合InnoDB引擎，事务安全有保障，适合存储游戏信息、用户信息、评论、分类等结构化数据。

这里我想多说一句：选技术栈不是越新越好，而是看它是否匹配业务规模和维护成本。这套组合之所以经典，是因为每一个环节都有成熟的替代方案兜底，即便你以后换人维护、二次开发，招人成本和上手成本都低。

2. 核心功能与数据库设计

一个项目的骨架是数据库，血肉是业务功能。我在拿到这类源码时，通常会先看三样东西：表结构、接口列表和前端路由。把这三样理清了，整个系统的业务逻辑基本就浮出水面了。

2.1 功能模块划分

这个热门网游推荐网站系统整体上可以分为前台展示和后台管理两大部分。

前台展示端以游客和注册用户为主体，核心功能包括：

• 游戏列表页：按分类、热门程度、评分等维度展示游戏卡片
• 游戏详情页：展示游戏名称、简介、玩法特色、推荐理由、所属分类、评论列表
• 用户注册与登录：支持账号密码登录，登录后可以发表评论和收藏
• 热门推荐位：在首页展示编辑推荐的游戏，通常带推荐标识或排序权重
• 搜索功能：按游戏名称进行模糊搜索

后台管理端以管理员为主体，核心功能包括：

• 管理员登录与权限校验
• 游戏管理：新增游戏、编辑游戏、上下架、删除游戏
• 分类管理：维护游戏所属分类（如MMORPG、MOBA、射击、休闲等）
• 推荐位管理：设置推荐游戏及排序权重
• 用户管理：查看注册用户列表、封禁或启用用户
• 评论管理：查看评论、删除违规评论

从这些功能反推表结构，你可以发现它们并不是粗暴地堆在一张大表里，而是按职责拆分成多张互相独立、通过外键关联的表。这个拆分正是后面系统易于扩展的关键。

2.2 数据库表结构设计要点

以我看到的这套源码设计为例，表的划分体现在game、category、user、comment、recommend等核心表上。

category表保存游戏分类信息，字段一般包括分类ID、分类名称、排序值。这里的排序值很重要，前端分类导航的展示顺序靠它控制，而后台新增分类时只需录入一个更大的排序值，就能把新分类排到后面。

game表保存游戏主体信息，主要包括：游戏ID、标题、封面图地址、简介、详细介绍、所属分类ID、评分、热度值、是否推荐、创建时间。这个表里有两个字段需要特别关注——分类ID和评分/热度字段。分类ID关联category表，在查询游戏列表时通过JOIN或子查询把分类名称带出来；评分和热度字段则是排序逻辑的依据，推荐位游戏往往优先展示热度高、评分高的记录。

user表保存用户账号信息，至少包含用户ID、用户名、密码（加密存储，常见的是MD5加盐或BCrypt）、角色标识（普通用户/管理员）、头像、注册时间。需要注意，管理员和普通用户在这个项目里可以共用一张用户表，通过role字段区分，而不是把管理员单独建表。这样在登录校验上，一套逻辑就能同时处理两方身份，代码也更精简。

comment表保存用户对游戏的评论，字段包括评论ID、游戏ID、用户ID、评论内容、评论时间。它通过游戏ID和用户ID分别关联到game表和user表，前端展示评论时联合查询出用户名和头像即可。

recommend表（或复用game表里的推荐字段）负责推荐位配置。如果项目用了独立表，字段包括推荐ID、游戏ID、排序值、推荐时间；如果只是复用game.recommend_flag字段，那么推荐逻辑就退化为一个布尔查询。两者各有优劣，独立表更灵活，布尔字段更简单。这套源码采用的是偏向独立推荐管理的方案，后台一次配置、前台直接读取，数据的时效性和可控性都更好。

关于表结构，我强烈建议你在看源码的时候，把每张表的主键、外键关系和索引都过一遍。这里有一个非常常见的坑：列表页模糊搜索时，game_name LIKE '%xxx%'走不了索引，如果游戏表数据量过万，查询会明显变慢。所以这类系统在初期数据量不大时还说得过去，但如果你打算二次开发并准备上线跑真实流量，建议给category_id、is_recommend、heat这些常出现在WHERE和ORDER BY中的字段加索引，搜索接口再做分页，避免全表扫描和内存排序。

3. 后端核心实现

后端是整个系统的业务中枢，也是很多人自学时最容易卡壳的地方。我看了这套SpringBoot项目的目录结构，它属于非常标准的Controller-Service-Mapper三层架构，清晰度很高，适合作为模仿范本。

3.1 SpringBoot骨架与MyBatis集成

项目启动类上标注的@SpringBootApplication注解通常包含了三个核心注解：@SpringBootConfiguration负责读取配置文件，@EnableAutoConfiguration负责自动装配所需的Bean，@ComponentScan负责扫描组件。这个注解一打上，SpringBoot就主动完成了大半的自动化工作，你不需要像传统Spring那样手写大段XML配置了。

MyBatis的集成通常有两种方式：注解SQL和XML映射。这套项目里两者都有体现。简单的单表CRUD用注解SQL就够了，例如在Mapper接口上直接写@Select("SELECT * FROM game WHERE id=#{id}")这样简洁明了；而复杂查询，比如游戏列表按多个条件动态筛选，推荐放在XML文件中用<where>动态SQL拼条件，因为XML方式更便于维护长SQL，而且修改SQL不用重新编译Java代码。

这里我特别提醒一点：在配置MyBatis时，要留意map-underscore-to-camel-case参数。数据库字段通常用下划线命名（如game_name），Java实体类通常用驼峰命名（如gameName）。如果这个参数不开启，查询返回时会发现gameName字段一直是null，因为MyBatis默认不会自动把下划线转驼峰。这个开关在application.yml或application.properties里配置，一行代码就能解决问题，但新手查半天才知道原因的大有人在。

3.2 接口设计与统一返回格式

这个系统的接口设计走的是RESTful风格，Game模块的常见接口路径大致如下：

GET /api/game/list 分页查询游戏列表 GET /api/game/{id} 查询游戏详情 POST /api/game 新增游戏 PUT /api/game/{id} 修改游戏信息 DELETE /api/game/{id} 删除游戏 GET /api/category/list 查询分类列表 POST /api/comment 发表评论 GET /api/recommend/list 获取推荐位游戏

接口路径是否规范直接决定了前端对接的效率。我曾经遇到过一个项目，接口路径混乱不堪，有的用动词、有的用名词，前端联调时不得不四处问人，效率极低。而RESTful的路径设计有两条核心准则：用名词不用动词、用HTTP方法表达操作意图。这套系统的路径基本遵守了这一准则，值得学习。

这里还涉及一个前端对接体验的问题——统一返回体。几乎每个接口都返回相同的JSON结构会极大降低前端处理逻辑的复杂度。例如：

{ "code": 200, "message": "操作成功", "data": { "id": 1, "gameName": "示例游戏" } }

前端Axios拦截器获取到响应后，只需判断code是否为200，如果业务异常则直接提示message，完全不需要针对每个接口单独写错误处理分支。如果某天你发现某些跨域调用时返回结构不统一，八成是后端某个Controller里有个方法直接返回了裸对象，而没经过统一的Result封装——这种细节在二次开发时尤其容易踩。

对于需要登录的接口（比如发表评论、后台管理操作），这个系统通常配合拦截器或Spring Security + JWT实现权限校验。我看到的版本用的是相对轻量的Token方案：用户登录成功后，后端生成一个Token返回给前端，前端把Token存在本地存储并在每次请求的Header里带上，后端通过拦截器解析Token中的用户ID和角色信息，未登录请求会被拦截并返回401状态码。这个方案比Session方案更适合前后端分离和分布式部署，因为Token是无状态的，不需要在服务端保存会话。

3.3 MyBatis动态SQL的实战用法

动态SQL是我觉得这套系统里特别有学习价值的部分。拿游戏列表的多条件筛选来说，前端可能同时传入分类ID、关键字、热门排序等多个参数，但用户未必每次都会填满所有筛选条件。如果为每一种组合都写一个SQL方法，那代码量会爆炸。MyBatis的<where>标签恰好解决这个问题：

<select id="selectGameList" resultType="com.example.entity.Game"> SELECT * FROM game <where> <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="keyword != null and keyword != ''"> AND game_name LIKE CONCAT('%', #{keyword}, '%') </if> <if test="isRecommend != null"> AND is_recommend = #{isRecommend} </if> </where> ORDER BY heat DESC </select>

这个查询的最大好处是：<where>标签会自动去掉第一个AND，所以不用纠结SQL拼接时前缀问题，也避免了传入空条件时出现WHERE 1=1这种低效写法。配合<if>判断，一个方法就吃透了列表页的绝大多数筛选场景。

很多人看到LIKE CONCAT('%', #{keyword}, '%')会疑惑为什么不直接写LIKE '%${keyword}%'。这里有一个绝对不能踩的坑：${}是字符串替换，直接把参数拼进SQL，如果关键字里包含单引号或OR 1=1这类内容，就有SQL注入风险。#{}是预编译参数占位符，会对参数做安全转义，所以只要不是必须动态拼接表名、排序列名等固定结构的需求，一律用#{}。

4. 前端Vue实现

前端部分是用户能直接感知到的那一层，也是这套系统里最能直观体现“推荐网站”气质的模块。Vue项目往往包含环境搭建、路由设计、Axios封装、组件划分和页面实现这么几大块内容。

4.1 环境准备与路由设计

项目如果用的是Vue CLI脚手架，你会看到标准的src目录结构：

src/ ├── api/ # 接口请求封装 ├── assets/ # 静态资源 ├── components/ # 公共组件 ├── router/ # 路由配置 ├── store/ # 状态管理（Vuex或Pinia） ├── views/ # 页面级组件 ├── App.vue # 根组件 └── main.js # 入口文件

路由设计是整个前端结构的支点。你会看到路由通常分为两块：不做登录校验的公共页面（首页、游戏列表、游戏详情）和需要管理员权限的后台页面（游戏管理、分类管理、评论管理）。Vue Router实现这个控制的核心是导航守卫，在beforeEach钩子里判断用户Token和角色信息，如果没有权限就重定向到登录页。这个机制的代码很短，但是理解了它，你才真切感受到前端路由守卫和后端接口拦截是如何配合起来构成一套完整访问控制体系的。

拿我的经验来说，路由命名最好和页面模块一一对应，不要用一些过于抽象的缩写。比如/game/detail/:id一眼就能看出是游戏详情页，接手你代码的人不需要反复翻文件才知道路由指向哪里。这个项目在这一点上做得不错，路径和组件的对应关系清楚明了。

4.2 Axios封装和状态管理

Axios在前端项目里是请求后端的标配。为了不把请求逻辑散落各处，这套项目在api目录里对Axios做了统一封装。封装的核心有两点：

第一，创建独立的Axios实例并设置baseURL。开发环境和生产环境的后端地址不同，这个地址一般放在环境变量文件里（.env.development和.env.production），构建时自动切换，避免代码写死接口地址。

第二，通过拦截器统一处理请求和响应。请求拦截器负责在每次请求的Header中追加Token，响应拦截器负责统一解包后端返回的数据、处理HTTP错误码。例如当后端返回401时，拦截器可以统一清除本地Token并跳转登录页，让所有页面共享同一套登录失效逻辑。

状态管理方面，这个项目用Vuex存用户信息。相比在每个组件里各自请求用户信息，全局状态管理的好处显而易见：用户登录后把信息写进Store，页面的任何位置都能直接读取，不需要重复请求。购物车、收藏列表这类需要跨页面共享的数据，在这个项目里也借用了同样的思路。

4.3 页面组件划分与数据绑定

页面实现上，推荐网站最核心的页面是游戏列表页和游戏详情页。列表页整体是由游戏卡片组成的网格，每一张卡片包含封面图、游戏名、评分和热度。这个卡片组件可以复用多次，所以拉到components目录里单独定义成子组件很合理，由父组件通过props把游戏数据传进去。

列表页的筛选逻辑是典型的数据驱动式写法：用户选中分类或输入关键字后，筛选条件存入本地data中，然后通过watch或点击按钮触发请求函数重拉游戏列表。这里常用的实现方式是这样的：

fetchGameList() { const params = { page: this.currentPage, limit: this.pageSize, categoryId: this.selectedCategory, keyword: this.searchKeyword }; getGameList(params).then(res => { this.gameList = res.data.records; this.total = res.data.total; }); }

这个函数的核心是把页面上的筛选条件映射成后端接口所需参数。一旦理解了它，前端页面的任何筛选交互都能套用。有个细节需要注意：页码重置。用户筛选条件变化时，如果当前已经翻到第5页，还带着第5页的页码去搜索，就会出现搜索后没有数据的错觉。所以我一般在请求前判断筛选条件是否变化，若有变化就先把currentPage重置为1再触发请求。

详情页的数据展示比较直接——路由params中携带游戏ID，mounted钩子中调用详情接口拿到数据，渲染到页面上。如果包含评论功能，评论区会同时维护一个输入框和评论列表，发布评论后调用POST /api/comment接口并重新拉取评论列表。要注意的是，未登录用户点击“发表评论”时需要跳转登录页或弹出登录框，这个交互逻辑要写清楚，不能等后端返回401才提示用户。

5. 部署上线与踩坑实录

走到部署这一步，项目才算真正完整。前后端分离项目的部署，和传统单体应用的部署方式完全不同，关键在于“前端静态资源 + 后端动态接口”的分离托管。我在部署这套系统的过程中踩了不少坑，这里一并整理出来。

5.1 环境准备与配置

部署一个SpringBoot + Vue项目，核心环境就三件套：Nginx、JDK、MySQL。

MySQL负责数据存储，上线前先要把本地的建表SQL导入线上库，并且创建独立账号、分配最小权限，绝不要直接用root账号连接业务库。JDK不用多解释，SpringBoot打包后是一个可执行的Jar包，需要JDK8或JDK11这类运行时环境支撑。Nginx虽然看起来只负责托管前端静态文件，但同时还要承担反向代理的职责——把/api开头的请求转发到后端服务，从而解决跨域问题。

部署流程大致如下：

1. 后端项目执行 mvn clean package 打包成 Jar 包 2. 将 Jar 包上传到服务器，执行 java -jar xxx.jar 启动 3. 前端项目执行 npm run build 打包生成 dist 目录 4. 将 dist 目录上传到服务器，交给 Nginx 托管 5. 配置 Nginx，将 /api 请求反向代理到后端端口

这里最值得展开的是Nginx配置。假设你打包并启动了后端服务在8080端口，前端dist目录放在/var/www/frontend，那么配置文件的关键部分可以写成这样：

server { listen 80; server_name your_domain; root /var/www/frontend; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

第一段location /里的try_files $uri $uri/ /index.html是Vue等SPA应用部署的关键，它解决了直接刷新非首页路由时404的问题。第二段location /api/就是反向代理，前端请求/api/game/list会被转发到http://127.0.0.1:8080/api/game/list，这个操作让浏览器以为接口和页面是同一个来源，彻底绕开了开发环境里常见的跨域报错，你甚至不需要在后端额外配置CORS。这个思路很重要——跨域问题的解决方式不只是后端加过滤器，通过Nginx反向代理让同源是生产环境里更优雅的方案。

5.2 常见问题与排查技巧实录

我每次带人做完技术栈类似的系统，遇到最多的问题几乎都集中在下面几个。我把它们做成一个速查表，方便你部署时逐条核对。

这里我再额外分享一个排查经验：当你遇到前端页面白屏或者数据不显示，又确认接口返回正常时，优先去看浏览器控制台的报错，尤其是Cannot read properties of undefined (reading 'xxx')这一类问题，往往是因为后端返回的数据结构和前端预期不一致。我在接触这套系统时，就踩过一次类似的问题：详情页接口返回的字段名是updateTime，前端组件里却用了update_time，导致页面渲染失败。后来统一规范了后端实体类的序列化规则，前端严格按照接口返回的字段名取数，这类问题就再没有出现过。

5.3 上线前的配置检查

部署成功之后，还有几处细节需要检查，这些细节往往决定一个项目是“能跑”还是“能上线”。

一是线上环境关闭开发工具。SpringBoot项目检查application.yml里的spring.profiles.active是否为prod，同时确认spring.devtools.restart.enabled是否关闭。开发热部署在线上毫无用处，白白占用资源。前端项目检查构建命令是否是npm run build:prod而不是serve。

二是数据库账号按最小权限分配。业务账号只给SELECT、INSERT、UPDATE、DELETE权限，不给DROP、ALTER等DDL权限。一旦遇到SQL注入或者误操作，至少不会把整个库的表删掉。这个习惯无论项目大小都应该养成。

三是日志文件切割。后端启动命令像java -jar xxx.jar --logging.file=/var/log/app/app.log这种方式，时间久了单个日志文件会非常庞大。生产环境建议接入logback-spring.xml做按天滚动，保留最近30天日志，既方便排查问题，也不至于磁盘被日志塞满。我见过不止一个项目因为忘了配日志滚动，上线两个月后磁盘满了，接口全部卡死。

四是前端页面兜底体验。上线环境网络相对复杂，图片加载失败和接口超时都很常见。给游戏封面图设置默认占位图、给请求设置超时时间并给出友好提示，这些小细节虽然不影响核心逻辑，但直接影响用户在真实环境中的体验。

6. 二次开发与扩展建议

项目跑通只是第一步，我更建议你基于这套系统去做一些扩展练习，这样才能把前后端分离的精髓真正内化成自己的能力。这里我按推荐指数排序给你几个方向，每个方向都有明确的学习指向。

第一个方向：把目前的“手动加推荐位”升级成“智能推荐逻辑”。原来的推荐位由管理员后台手工配置，扩展方向是在后端增加一个定时任务，根据游戏的评分、访问热度、评论数量等指标定期计算推荐排序。实现上可以利用Spring自带的@Scheduled注解，写一个定时统计方法，更新game表的推荐分值字段。这个练习会让你掌握定时任务、聚合SQL和缓存预热，含金量非常高。

第二个方向：引入Redis做缓存。现在每次打开首页都会查询数据库，数据量一大并发一高，性能短板就出现了。你可以引入Redis缓存首页游戏列表和热门游戏详情，设置5到10分钟的过期时间，后台编辑游戏时主动删除对应缓存。这个练习能让你真正理解缓存穿透、缓存击穿和缓存雪崩的区别，面试时也是高频考点。

第三个方向：把简单的JWT登录升级为Spring Security + JWT组合。Spring Security提供了完整的认证授权链路，包括密码加密（BCrypt）、方法级权限控制、记住我功能等。学习曲线确实陡峭，但一旦啃下来，你对“认证”“授权”“过滤器链”的理解会有一个质的提升。这套项目本身就具备用户和管理员两种角色，正好是设计权限模型的最佳练习场。

第四个方向：引入文件上传与云存储。目前游戏封面图可能是网络图片地址或本地上传图片。实际项目中，图片资源一般不会直接放在应用服务器里，而是传到对象存储服务并在数据库保存URL。你可以实现一个图片上传接口，上传后自动生成访问链接，返回给前端回显。这个功能几乎是企业级项目的标配，做一次就会了。

第五个方向：性能与监控增强。比如在MyBatis中开启SQL日志打印，使用Druid连接池监控SQL执行情况，或者接入简单的API访问日志中间件。不要小看这些“非业务功能”，线上环境排查问题靠的都是这些基础设施。我见过有经验的开发者接到报警后，第一件事就是翻监控面板看SQL耗时和接口RT，没这些数据只能干瞪眼。

扩展练习的方向不算少，但我的意见是你不需要全部都做。挑一个你当前最薄弱的方向，把它吃深做透，比每个方向都浅尝辄止要有用得多。我个人的建议顺序是：Redis缓存 > Spring Security > 定时推荐 > 云存储 > 监控增强。理由是缓存和安全这两块在实际就业市场里出现频率最高，先把这两块啃下来，收益最大。

7. 最后再分享一些实际操作中的体会

这套前后端分离的网游推荐网站系统，陆陆续续带过不少朋友和同学完整跑通，每次陪跑都多多少少会踩到一些新问题，但也越来越确认这套技术栈的稳定性。如果你想拿它练手，我的建议是：不要只看代码，一定要动手把项目从零到一跑起来，再自己动手加一个功能或者改一个页面，感受一下前后端联调的完整闭环。

我个人实际操作中有一个心得：永远先跑通再优化。很多同学一上来就想搞完美的架构、微服务、分布式缓存，结果项目根本跑不起来。其实先把SpringBoot + Vue + MyBatis + MySQL整条链路跑通，再逐步引入缓存、安全框架、对象存储这些周边能力，才是符合事物发展和真实学习规律的做法。这套项目最让我欣赏的地方，恰恰是它足够简单、足够清晰，能让你专注在核心链路的理解上，而不是被花哨的技术遮蔽了本质。

还有一个小技巧想分享给正在部署的你：本地开发和线上部署的配置最好分离。具体做法是SpringBoot里用application-dev.yml和application-prod.yml区分环境，前端用.env.development和.env.production区分接口地址。用--spring.profiles.active=prod指定线上环境，就不会出现把本地数据库地址带到线上的尴尬。这个习惯越早养成越好，以后换任何项目都用得上。

如果你正在学这套系统，建议给自己定一个目标时间——比如两个星期。第一个星期跑通项目并读懂核心模块，第二个星期自己动手扩展一个小功能。两个星期后，你就会发现前后端分离项目在你眼里不再是一团迷雾了。