企业官网建设流程全解析

自驾游攻略这个需求，看起来是个老生常谈的话题，但真要做成一个能用的查询系统，坑并不少。我前后花了三周时间，用SpringBoot + Vue把整套东西从零搭了出来，从数据建模到地图可视化，再到打包部署，踩了不少坑，也沉淀了一些还算通用的解法。这篇就把整个项目的设计思路、核心代码、部署细节和排查经验一次说清楚，给正在做类似毕业设计或企业小工具的同学一个可参考的完整方案。

先交代一下背景和这个系统能干什么：用户打开页面后，可以根据目的地、出行天数、预算、主题标签（比如亲子、摄影、徒步）组合筛选攻略；点进攻略详情能看到完整的行程安排、每天的路线轨迹、沿途景点介绍和花费预估；登录后可以收藏攻略、给自己规划的路线生成分享卡片。后台管理端支持维护景点库、攻略内容和推荐位。整个项目前端是Vue 3 + Element Plus + ECharts + 腾讯地图，后端是Spring Boot 2.7 + MyBatis-Plus + Redis + MySQL，接口风格走RESTful。

1. 技术选型：为什么是SpringBoot + Vue，而不是其他组合

1.1 后端用SpringBoot的核心考虑

SpringBoot在Java生态里早就不是“新东西”了，但放在这种查询系统里依然是最稳的选择，原因有三个。

第一是起步成本低。SpringBoot的自动装配把Spring MVC、事务管理、 Jackson序列化这些基础设施全部整合好了，我只需要关注业务代码。写一个攻略查询接口，从建项目到能跑通，十分钟之内能完成，不用像传统SSM那样写一大堆XML配置。

第二是生态成熟度。和MySQL、Redis、Elasticsearch这些组件的整合方案已经被验证过无数次，出了问题搜索解决方案一抓一大把。我在系统里用到了Redis做热门攻略缓存，用WebSocket做后台攻略更新推送，SpringBoot都有对应的starter支持。

第三是部署友好。系统最终要交付给用户使用，SpringBoot内嵌Tomcat，打包成可执行jar后丢到服务器上就能跑，配合Nginx做静态资源分离非常顺手。这一点在后端选型时几乎是决定性的——我不想为了部署去单独装一个Tomcat然后还要维护两个进程。

当然也有替代方案，比如若依这种快速开发平台，或者直接用Node.js的Express/NestJS。但考虑到大多数读者还是以Java技术栈为背景，且毕设或企业内部项目评审往往看重SpringBoot这套体系，我最终没有采用那些方案。

1.2 前端为什么锁定Vue

前端框架的备选其实不少，React、Vue、Svelte各有拥趸。我选Vue的理由很实际：Vue单文件组件的写法对后端转前端的开发者最友好，模板语法接近原生HTML，不需要像JSX那样在JavaScript里写标签结构。

更重要的是Vue生态在中文社区沉淀了大量现成的解决方案。Element Plus这套组件库覆盖了表格、表单、穿梭框等几乎所有管理端需求；Vue Router配合动态路由可以轻松做权限控制；Pinia做状态管理时类型提示比Vuex舒服得多。而这次系统里需要用到的地图可视化，腾讯地图JavaScript SDK也有现成的Vue封装，不需要自己从零封装底层GL库。

前端的整体架构我采用了Vue 3 + Vite + Pinia + Vue Router + Axios的组合。Vite构建要比Webpack快一个量级，尤其是我这种反复改代码验证效果的开发模式，热更新几乎秒开，体验提升非常明显。

1.3 为什么前后端分离，而非服务端渲染

这个项目的核心场景是攻略查询，页面交互状态多——筛选条件要实时联动，地图要异步加载，收藏按钮点击后不能刷新页面。如果用传统的Thymeleaf服务端渲染，每次筛选都要刷新整个页面，体验会很差。前后端分离后，前端只负责渲染和交互，后端只提供数据接口，两边可以并行开发互不阻塞。

为了兼顾SEO和首屏速度，我在前端做了路由懒加载和按需加载，攻略详情页打开后再请求地图和评论数据，这样就规避了大部分SPA的通病。如果后续需要搜索引擎收录攻略内容，再考虑给详情页加一个服务端渲染中间层，但现阶段这个优先级不高。

2. 数据库设计与后端接口落地

2.1 攻略数据怎么建模才合理

攻略数据是整个系统的核心资产，设计表结构的时候我参考了主流旅游平台的做法，用”景点—线路—攻略”三层结构来组织数据。

景点表存基础信息：景点名称、所在城市、经纬度、简介、封面图、建议游玩时长、门票参考价。线路表表示一条具体的行程路线，包含线路名称、所属城市、总天数、主题标签、适合季节。线路和景点通过中间表关联，考虑到同一个景点可能出现在多条线路中，也要记录在某条线路中是第几天的第几个点，所以我设计了route_spot关联表，里面存了spot_order和day_number字段。

攻略表是最终面向用户的输出物。它包含了标题、封面图、作者ID、关联线路ID、详细内容（Markdown格式）、浏览量、点赞数、收藏数、综合评分等字段。这里我踩过的一个坑是：不要把攻略的完整内容直接塞在列表接口里。列表页只需要标题、封面、摘要、评分、浏览量这些轻量字段，真正打开详情时才加载全文。我把详情的Markdown存在单独字段里，通过VO层区分列表对象和详情对象来解决。

数据库的索引设计也值得多说几句。攻略表的筛选条件通常是城市加主题标签加天数区间，所以我建了(city, theme, days)的联合索引；线路表的城市查询频率很高，单独建了索引；用户收藏表则有唯一索引(user_id, strategy_id)。在数据量不大的前提下，这套索引完全够用，不需要引入ES。

2.2 查询接口如何在性能与灵活之间取舍

攻略查询接口是系统的心脏，我设计了两个核心接口：POST /api/strategies/query和GET /api/strategies/{id}。前者接受一个JSON对象，包含城市、主题、天数范围、排序方式、分页参数等字段，后者返回攻略详情。

为什么查询接口用POST而不是GET？因为查询条件组合较多，URL会很长，而且有些条件比如主题标签是一个数组，放Query Param里既丑又容易出错。POST body传JSON干净利落。不过HTTP语义上POST一般用于创建资源，这里用POST做查询会被人诟病，所以我加了一层路由：POST /api/strategies/search，让别人一眼看出这是搜索接口而非普通集合查询。

接口里我做了三个层面的优化。第一层是SQL层面，用MyBatis-Plus的LambdaQueryWrapper动态拼条件，只有当条件非空时才加入where子句；第二层是缓存层面，热门搜索组合（比如“成都+3天”）的结果缓存到Redis，缓存key设计为条件参数的MD5值，过期时间30分钟，中途修改攻略后主动删除相关缓存；第三层是数据组装层面，列表接口查回来的VO只包含基础字段，不关联查询作者表和评分明细，等用户点开详情再组装完整数据。

这里把代码贴出来，给一个MyBatis-Plus连表查询的思路。注意MyBatis-Plus本身不支持多表join查询，我是通过自定义SQL实现的：

@Select("<script>" + "SELECT s.strategy_id, s.title, s.cover, s.summary, s.score, s.view_count " + "FROM strategy s " + "LEFT JOIN route r ON s.route_id = r.route_id " + "WHERE 1=1 " + "<if test='city != null and city != \"\"'> AND r.city = #{city}</if> " + "<if test='theme != null and theme != \"\"'> AND r.theme = #{theme}</if> " + "<if test='minDays != null'> AND r.days &gt;= #{minDays}</if> " + "<if test='maxDays != null'> AND r.days &lt;= #{maxDays}</if> " + "ORDER BY " + "<choose>" + "<when test='sort == \"view\"'>s.view_count DESC</when>" + "<when test='sort == \"score\"'>s.score DESC</when>" + "<otherwise>s.create_time DESC</otherwise>" + "</choose> " + "LIMIT #{offset}, #{pageSize}" + "</script>") List<StrategyListVO> searchStrategies(@Param("city") String city, @Param("theme") String theme, @Param("minDays") Integer minDays, @Param("maxDays") Integer maxDays, @Param("sort") String sort, @Param("offset") Integer offset, @Param("pageSize") Integer pageSize);

注意这里用了<![CDATA[]]>包裹大于号小于号是一种避免XML解析错误的方案，但我代码里用的是>和<转义。两种都可以，看个人习惯。

2.3 Redis缓存与热点攻略的刷新策略

Redis在这个系统里承担两个职责：缓存热门攻略列表、缓存用户会话。

热门攻略列表的缓存我用的是Redis的String结构，key格式为hot:strategy:{city}:{theme}，value是JSON序列化的列表数据。每次用户发起查询时先查Redis，命中就直接返回json字符串，没命中才走数据库，并回填缓存。

但缓存有个经典问题——数据一致性。比如管理员编辑了某篇攻略后，用户查询到的可能还是旧数据，最长要等30分钟缓存过期。我在管理端更新接口里做了缓存清除：每次对攻略表做增删改操作后，删除所有以该攻略线路城市和主题为维度的热门缓存key。虽然这种清除策略比较粗粒度，可能多清了一些不相关的key，但保证了数据的最终一致性，对这种查询场景来说，宁可多失效也不能脏读。

用户会话这块本来应该用JWT实现无状态登录，但考虑到需要支持服务端主动注销和踢人，我选择了Token存入Redis的方案。登录成功后生成一串UUID作为token，Redis中存userId -> token的映射，过期时间7天。用户每次请求带上token，后端校验Redis中是否存在且匹配。这个方案代码量不大，但远比纯JWT安全——JWT一旦签发，在过期前服务端很难让某个用户立即下线。

3. Vue前端核心功能与踩坑实录

3.1 环境搭建与项目初始化的注意事项

前端环境这一步看起来简单，但我在给团队几个人部署开发环境时发现，半数问题都出在Node版本和依赖安装上。项目用的Vite 4要求Node.js版本在14.18及以上，最好直接用16+，推荐用nvm管理Node版本，不要跟着系统默认版本走。

安装依赖用npm还是pnpm？我建议用pnpm。原因很实际：pnpm的依赖管理方式使得多个项目间共享依赖，安装速度快，而且能避免npm在某些情况下出现的依赖树混乱问题。在我开发这个项目时，使用pnpm install后没有再遇到那种启动果实然报“Cannot find module”的问题。

初始化项目时，官方脚手架是npm create vite@latest。建议选择Vue + TypeScript模板，虽然初期多写几个类型定义文件，但项目代码量大了以后真的能减少大量低级bug。纯JavaScript虽然写起来爽，但攻略数据这种嵌套结构多、字段多的场景，IDE的智能提示会很大程度降低出错概率。

还有一个容易忽略的配置：Vite的路径别名。我在vite.config.js里设置了@指向src目录，这样组件里引用资源时是@/components/xxx.vue而不是../../components/xxx.vue，整洁且不容易配错。这个配置和TypeScript的tsconfig.json中的paths要对应上，否则IDE里还是会飘红。

3.2 路由设计：静态路由加动态路由一起用

Vue Router在这个项目里承担了页面调度和权限控制两个任务。我的路由表分三层：公共路由（登录页、首页、攻略列表）、需要鉴权的路由（收藏夹、个人信息）、管理端路由（攻略管理、景点管理、数据统计）。

公共路由直接在路由配置里静态定义。但管理端的路由我用了动态路由——后端返回当前用户的权限列表，前端根据权限列表动态添加路由。这种方式解决了两个问题：不同角色的用户看到不同的菜单和页面；攻击者即使猜测到管理端路由路径，由于路由未被注册，走进来也只会落到404页面，而不是看到一片空壳页面。

动态路由的代码模板大致是：

// 登录后根据角色动态注册路由 const loadRoutes = async (role) => { const allRoutes = [ { path: '/admin', component: () => import('@/views/admin/Index.vue'), meta: { roles: ['admin'] } }, { path: '/admin/strategies', component: () => import('@/views/admin/StrategyManage.vue'), meta: { roles: ['admin'] } }, { path: '/admin/spots', component: () => import('@/views/admin/SpotManage.vue'), meta: { roles: ['admin'] } } ]; const accessible = allRoutes.filter(route => route.meta.roles.includes(role)); accessible.forEach(route => router.addRoute(route)); };

这里有个细节，路由跳转前要做全局前置守卫，检查目标路由是否需要登录以及当前用户角色是否匹配，不匹配就重定向到401页或者登录页。另外router.addRoute加进去的路由在用户刷新页面时会丢失，所以页面加载后必须先调接口获取当前用户权限，再注册动态路由，最后再下发跳转指令。这个流程如果顺序不对，就会出现刷新后白屏或者跳到404的诡异现象。

3.3 地图可视化：腾讯地图在Vue里的正确打开方式

自驾游系统的核心视觉元素就是地图。攻略详情页需要展示每天的行车路线和景点标注，攻略列表页需要展示景点分布热力图。这些功能我最终选择了腾讯地图JavaScript API，而不是高德或者百度，原因是它的API清除简洁、定位精度在中国大陆场景下足够好，而且与Vue的配合也比较顺。

接入步骤非常简单：去腾讯地图开放平台注册开发者账号，创建应用拿到Key，然后在Vue项目里通过loadScript动态加载JavaScript SDK：

export const loadMapSDK = (key) => { return new Promise((resolve, reject) => { if (window.TMap) { resolve(window.TMap); return; } const script = document.createElement('script'); script.src = `https://map.qq.com/api/gljs?v=1.exp&key=${key}`; script.onload = () => resolve(window.TMap); script.onerror = reject; document.head.appendChild(script); }); };

通过这种方式异步加载SDK，不会阻塞首屏渲染。地图组件的生命周期里，我在onMounted时初始化地图，在onUnmounted时调用map.destroy()销毁地图实例，否则来回切换页面会累积多个地图实例导致内存泄漏。

绘制路线时我用了TMap.MultiPolyline，坐标数据来自后端线路表中每天途经景点连成的折线。因为景点间实际路线可能是弯曲的，直接用直线连接显得很不真实。我一开始没有做路线拟合，结果地图上的线路是横穿多个街区的直线，误导性很强。后来换成了先根据途经点的经纬度调用腾讯地图的方向服务API获取真实导航路径坐标串，再用这个坐标串绘制折线，视觉和实际骑行路线就贴合了。

3.4 富文本与图片展示的易错点

攻略详情里的图文内容，后端存的是一大段Markdown字符串。前端用了marked.js解析Markdown为HTML，再通过v-html渲染。这里有两个坑必须说清楚。

第一个坑是XSS风险。攻略内容里有用户上传的图片地址和可能存在的链接，如果直接渲染，恶意脚本就能在用户浏览器里执行。我的处理方案是渲染前对HTML字符串做清洗，用DOMPurify过滤掉所有script标签、onerror这样的事件属性，只允许白名单标签和属性。虽然项目里没遇到真实攻击，但做了这层防护心里才踏实。

第二个坑是图片响应式。攻略编辑器里插入的图片可能是不同尺寸的，直接渲染到页面上会出现横向溢出。解决方案是在全局CSS里限制.strategy-content img { max-width: 100%; height: auto; }，同时给所有图片加loading="lazy"让页面滚动到图片位置时才加载，优化首屏速度。

地图组件在详情页里的展示宽度同样要处理好，否则在移动端会出现遮挡和空白。我封装了一个DayRouteMap组件，把每天的路程封装成独立组件，通过props接收坐标数组，用v-if切换不同天的路线显示，这样一天的路线就是一张独立的地图，不会出现所有天的路线混在一张图上导致看不清楚的情况。

4. 热词背后的那些考点与细节

4.1 Vue打包后如何放进SpringBoot里

这个话题我是在“springboot打包vue”系列问法里反复见到的，正好也是部署时最纠结的点。常见的方案有两种：一种是Nginx托管前端静态文件，后端单独跑jar；另一种是把前端打包产物直接丢进SpringBoot的src/main/resources/static目录，由SpringBoot统一托管。两种方案各有适用场景，但很多同学不知道它们之间的取舍。

如果你的系统部署在单一服务器上，且没有单独的静态资源服务器，我推荐第二种方案，因为省了一个Nginx进程。具体做法是前端执行npm run build后，将dist目录下的文件拷贝到src/main/resources/static目录，然后重新打包后端jar。用户访问/时，SpringBoot返回index.html；访问/api/xxx时走Controller；访问其他静态资源时从static目录直接返回。

这个方案的坑在于前端路由的history模式。如果用户直接在浏览器地址栏输入http://server:8080/strategy/123然后回车，SpringBoot会试图找一个叫strategy/123的Controller或者静态资源，发现404就返回404页面。解决方法是写一个Controller将所有非静态资源、非接口的路径转发到index.html：

@Controller public class ForwardController { @RequestMapping(value = {"/", "/strategy/**", "/search/**", "/user/**", "/manage/**"}) public String forward() { return "forward:/index.html"; } }

注意这个Controller不能拦截/api路径，否则所有接口请求也会被转发到前端页面。另外，/assets/**这类静态资源路径不应该被forward，否则前端打包出来的JS CSS文件就取不到了。我实际配置时只列了前端路由需要覆盖的前缀，没有用通配符/**，避免副作用。

如果选择Nginx方案，则Nginx配置的关键是location/指向静态目录，location/api作为反向代理转发到后端。这种方案的好处是静态资源和后端完全解耦，后端升级不会影响静态文件。但服务器上需要额外跑一个Nginx进程，还要管理静态目录的更新。给毕设或小工具用的话，我觉得SpringBoot内置静态目录更省心。

4.2 SpringBoot版本太高带来的兼容性坑

开发时新项目往往追求“用最新”，但SpringBoot 3.x和2.x不是简单的版本号差异，它底层基于Jakarta EE，javax.servlet前缀变成了jakarta.servlet，很多老版本的第三方库直接不兼容。我所在的团队里有人新建SpringBoot 3.2项目后，发现MyBatis-Plus老版本无法识别数据源，Redis连接池报错，折腾了一整天才发现是包名和序列化机制变了。

想少踩坑，我的建议是：毕设和中小型项目用SpringBoot 2.7.x绝对够用且稳定。2.7.x对Java 8支持良好，MyBatis-Plus、PageHelper等生态完全兼容，相关教程也是主流版本讲的东西比较多。

如果你非要用SpringBoot 3.x，那就必须把配套组件全部升级到适配版本：MyBatis-Plus需要3.5.3以上的版本，且要注意mybatis-plus-spring-boot3-starter这个starter的存在；Redis客户端要换到Lettuce的适配版本；PageHelper需要更新到支持Jakarta的版本。否则项目启动时各种ClassNotFoundException和BeanCreationException会把你折磨到怀疑人生。

还有一个细节是SpringBoot 2.7与Vue Router history模式整合时的路径匹配问题。SpringBoot默认对路径中的点号.有特殊处理，会认为是文件后缀。比如某个前端路由是/strategy/3.5.1，SpringBoot转发时可能匹配异常。我的解决方案是在application.yml里加一行配置：

spring: mvc: pathmatch: matching-strategy: ant_path_matcher

虽然这行配置在SpringBoot 2.6之后默认值是path_pattern_parser，但Ant风格的路径匹配在包含点号和正则的路径上更宽容。这个细节如果提前不知道，遇到具体的路径匹配问题会浪费半天。

4.3 攻略数据里汉语言处理的场景

搜索功能如果要做成“智能提问式”的，比如用户输入“成都三天两晚适合带小孩玩”，系统需要把这句话拆解成结构化查询条件——城市=成都，天数=3，主题=亲子。这个需求我当时犹豫要不要上轻量级NLP，最终采用的是HanLP分词加关键词词典的方案。

HanLP是一款开源的中文自然语言处理工具包，能在Java项目里通过Maven直接引入。我用它把用户输入的自然语言句子分词，然后通过正则和数据词典提取城市名、数字天数、主题关键词。起步不需要训练模型，内置的模型对常规中文分词已经比较准确。对于“成都”“拉萨”这种旅游地名，我在词典里额外维护了一个热点城市词表，需要在HanLP的CustomDictionary里动态加载。

举个例子，用户输入“杭州周末自驾游”，HanLP分词得到[杭州, 周末, 自驾游]，然后我依次判断：杭州是城市词表中已有的词，提取为城市条件；周末我在时间词表中映射为“2~3天”的天数范围；自驾游映射为主题标签。这套逻辑不算复杂，但搜索体验比单纯的关键字匹配好了不少。如果还需要更强的语义理解，那就得引入ES的查询语法或者向量化召回，对一个小项目来说方法论过度了。

5. 项目从开发到上线的完整过程与心得

5.1 分阶段开发节奏与任务拆解

一个前后端分离的项目，最容易出现的风险是两边并行开发后接口对不上。我从一开始就定了铁律：先定义接口文档，再动手写代码。具体操作是用Swagger/OpenAPI规范描述所有接口的请求响应结构，前端和后端都对着这份文档开发。

开发节奏我分了四个阶段：第一阶段打通技术骨架——前后端项目初始化、用户登录注册、JWT鉴权、基础布局；第二阶段实现核心查询——攻略列表、详情、搜索、筛选排序，这部分是整个系统的主干，必须最先做扎实；第三阶段做地图相关功能——线路展示、景点标注、路线绘制，这部分视觉性强，做完后整个系统就像模像样了；第四阶段是管理和优化——后台管理功能、缓存、部署上线、性能优化。

第一轮自测时我发现了几个比较隐蔽的问题：删除一个景点后，关联线路中的景点顺序出现空位，导致地图上漏掉标注点。这个缘起是数据库里route_spot关联表没有设置外键约束，我在应用层删除景点、线路时也没有同步清理关联数据。解决办法很简单，在Service层做事务控制，删除景点时一并清理关联表和攻略缓存。这种事如果在代码评审阶段就能被标记为风险项，后面调试会轻松很多。

5.2 部署与环境变量管理的实操细节

后端部署到服务器时，环境配置不会和本地完全一样。我用了SpringBoot的多环境配置方案：application-dev.yml对应本地开发环境，application-prod.yml对应服务器正式环境。打包时指定-Dspring.profiles.active=prod或者启动时加参数--spring.profiles.active=prod。

连接生产数据库的账号密码、Redis密码这种东西不放进配置文件提交到代码仓库，这是最基本的底线。我的做法是把这些敏感信息放在环境变量里，配置文件中用占位符引用，例如：

spring: datasource: url: jdbc:mysql://${DB_HOST}:${DB_PORT}/${DB_NAME}?useUnicode=true&characterEncoding=utf8 username: ${DB_USER} password: ${DB_PASSWORD}

启动时通过export DB_HOST=127.0.0.1等命令设置环境变量。这样即使代码仓库泄露，也不会直接暴露数据库密码。当然更严格的做法是使用配置中心如Nacos/Consul，对于小项目来说环境变量已经足够。

前端部署在SpringBoot静态目录方案下没有额外的环境变量概念，但前端代码里调用的后端接口地址是写死的/api前缀，所以前端和后端部署在同一应用里时不需要额外处理跨域。如果是前后端分域名部署，则必须在后端写清CORS配置或者通过Nginx反向代理来规避跨域问题。

5.3 内存与性能的小优化

Redis缓存已经拦掉了大部分热门查询，但还有一些查询条件组合非常多，缓存命中率低，比如按“评分最高+景点数最多”这种没有固定组合的查询。我后来给这种查询加了限制：无排序字段时默认按发布时间倒序；排序字段只能从白名单里选择，防止自由拼接导致的慢SQL。

数据库层面还有一个优化必须做：分页查询不要用大偏移量。比如LIMIT 20000, 20时MySQL要扫描20020行数据，然后丢弃前20000行。攻略数据量达到几十万条后分页会越来越慢。我的方案是使用游标分页——前端传最后一个记录的ID或时间戳作为查询起点，后端用WHERE id < #{lastId} ORDER BY id DESC LIMIT 20来实现。不过这个方案对跳页操作不友好，需要额外做一个“上一页”和“下一页”的导航，好在攻略查询场景下用户对跳页的需求并不强烈。

前端还有个不怎么起眼但收益很大的优化：图片懒加载加CDN加速。攻略封面图、景点图如果全部直出，首屏图片体积可能超过5MB。我用Vue自带的v-lazy指令按需加载图片，然后把静态图片资源上传到OSS/CDN，后端接口只存图片URL。这样首屏加载时间从原来实测的3.2秒降到了1.4秒左右。

6. 开发中遇到的几个高频问题与解法汇总

6.1 前端刷新页面后404

这个问题前面提到过，但值得单独拿出来再说一次。如果你的前端用了Vue Router的history模式且部署在SpringBoot静态目录下，刷新页面后404的根因是：SpringBoot在收到路径如/strategy/123的请求后，默认去static目录找对应的文件或者匹配相关Controller，找不到就返回404，不会自动把你跳到index.html。

问题的标准解法是添加一个ForwardController把所有非API路径转发到index.html。但这里有个细节要格外注意：SpringBoot的静态资源处理顺序和@Controller的匹配顺序。如果你的Controller用了@RequestMapping("/**")，它会拦截所有请求，包括静态资源，导致CSS和JS文件也被forward到HTML页面。我在排查时发现，队友一开始图省事写了个/**的转发生效了页面能打开，但所有的样式和脚本都不加载了，就是这个原因。

我建议不要用通配符，而是列清楚前端路由的前缀，比如这个系统里是“/strategy/”、“/search/”、“/user/”、“/admin/”。如果前端路由特别多且分散，可以考虑用正则表达式限定非静态资源和非API前缀。

6.2 中文乱码问题

前后端交互时中文乱码是历史遗留问题，但SpringBoot中仍然会有遗漏。我在系统里处理了三个层面的编码：页面请求使用UTF-8编码；后端接口的produces明确指定UTF-8；数据库的连接URL加上characterEncoding=utf8参数。这是一个查漏补缺的过程，任何一个环节漏配，中文就可能变成问号或者方块。

MySQL建库时也需要注意编码。如果你的库表默认字符集是UTF-8但排序规则是utf8mb4_general_ci，而另一张表是utf8mb4_unicode_ci，关联字段在特殊情况下可能出现索引失效。我自己建了一个工具方法：每建一张表都显式声明字符集，不依赖数据库全局配置。

从前端发送的中文请求参数，在Axios里默认按UTF-8编码；后端接收时只要SpringBoot配置了UTF-8字符集，就没什么问题。我遇到的乱码更多是在SpringBoot解析表单数据时，server.servlet.encoding.force=true这个配置项没开启，结果前端传的中文到后端变成了乱码，后来加上就正常了。

6.3 攻略列表接口偶尔很慢

有段时间攻略列表接口偶发很慢，排除了数据库慢SQL可能后，我用了链路追踪定位——在查询接口里记录startTime和endTime，把耗时打印到日志里。最终发现是每次查询都会去数据库关联查一次攻略的作者信息，而作者表数据量不大但没走索引，查询耗时就拉高了。

解决方案是列表接口不联查作者信息表，攻略表本身冗余一个author_name字段；详情页需要作者完整信息时再单独查一次。查询次数少了，接口响应时间降了约35%。冗余字段在互联网开发里是常用的读写分离策略，读多写少的场景收益很大，但要注意更新作者昵称时同步更新攻略表里的冗余字段。

还有一个常见的取舍：攻略详情里带着评论列表和点赞数。如果每次打开攻略详情都顺带查6、7张表，接口响应时间几乎不可控。我最终拆成了三个接口：攻略基础信息、攻略评论分页、热门自驾线路推荐。页面打开时活动基础信息优先渲染，评论和推荐异步加载，用户体验顺畅许多。

7. 工具链与团队协作的经验补充

7.1 IDEA社区版与基本配置

使用IDEA做SpringBoot开发，建议安装Lombok插件、MyBatisX插件和Vue插件。Lombok插件的用处是简化实体类代码，@Data注解自动生成getter/setter；MyBatisX插件可以把Mapper接口和XML文件关联起来，支持自动跳转和代码生成；Vue插件主要用来高亮.vue文件中的模板、脚本和样式，没有这个插件的话Vue文件就是一堆乱糟糟的文本。

IDE的配置上，有两个点很重要：一是把编码设置成UTF-8，File -> Settings -> Editor -> File Encodings里全部选择UTF-8；二是配置Maven本地仓库和远程仓库镜像，国内环境不用阿里云镜像的话，下载依赖会特别慢。IDEA里Maven的settings.xml中配置阿里云镜像仓库能显著提升依赖下载速度，这点不接受反驳。

如果你和我一样在Windows下开发，注意SpringBoot应用的启动端口不能被占用。查杀占用端口的方法是netstat -ano | findstr 8080，然后taskkill /F /PID 进程号。如果不想每次手动操作，也可以在IDEA的运行配置中添加指定端口参数，减少这种摩擦。

7.2 接口调试与模拟数据

开发过程中我一直用Apifox做接口调试，集成了Swagger和Mock功能。写好接口文档后，自动生成模拟数据，前后端可以并行开发。等到后端服务启动后，前端可以直接把Mock地址切换到真实地址，替换成本基本为零。

为了前端开发时不依赖后端，我们约定每个接口都有对应的Mock规则。例如攻略列表接口的数据结构必须返回{ code: 0, message: "success", data: { list: [], total: 120 } }，前端根据这个约定开发页面。等到后端联调时，因为数据结构已经定死，很少出现页面空数据的问题。

7.3 数据恢复与备份

数据库的备份很重要，我开发了一个定时任务，每天凌晨用mysqldump将数据库导出到服务器磁盘，然后通过OSS上传一份备份。恢复流程也测试过：先导数据，再启动后端，检查接口返回数据是否正常。这个备份策略虽然简单，但对中小项目来说已经足够，不至于手误删了表然后挠头。

8. 实测效果和后续可扩展的方向

系统上线测试后，我用几个真实自驾游场景做了验证。输入“川西五天自由行”后，搜索服务通过HanLP分词抽取出城市条件为空、天数为5天、主题为自由行，再根据攻略库的匹配返回了11条相关攻略，评分最高的几条封面和内容都符合预期。从点击行为看，列表页用户主要集中在前10条攻略，说明搜索排序算法还有优化空间。

地图路线展示这部分，我导入了一条实际的川西环线数据，从成都出发经过康定、新都桥、理塘、色达返回成都。地图上能正确显示每天的行驶路线，点击某个景点标注可以弹出详情卡片，包含介绍、游玩时长和门票价格。这些数据的录入是有些繁琐的，好在管理端提供了批量上传CSV和可视化编辑功能，运营人员可以在后台地图上直接拖拽景点调整顺序，保存后前端刷新即可生效。

后续我觉得可以加三个方向：一是引入推荐算法，根据用户浏览和收藏行为生成个性化攻略推荐；二是加入行程规划功能，用户自由添加想去的地点后，系统通过地图服务计算路线、时间、预算生成定制攻略；三是接入消息通知，管理员发布的攻略更新或限免活动主动推送到用户微信或站内信。考虑到这个项目的体量，前两个方向的优先度更高。

9. 最后一次分享，关于踩坑与项目的两个实用体会

回想整个开发周期，最深刻的体会是：哪怕功能简单，技术栈选择对了能省一半的心。SpringBoot + Vue这套组合成熟、稳定、学习曲线平缓，遇到问题能搜到大量真实解法，这是那些炫酷但不成熟的新框架给不了的安全感。比如SpringBoot中配置pathmatch的细节、Vue Router history模式的404问题、数据库编码问题，这些坑基本都有现成的答案，关键是你愿不愿意耐心去搜去试。

第二个体会是关于项目的边界。初次做全栈项目很容易陷入“什么功能都想加”的泥潭，结果每个模块都做得很浅。我的建议是优先把核心链路做透——用户搜索攻略、查看地图、收藏、评价，这四个环节体验顺畅了，系统就算成功了。那些锦上添花的功能，比如自动推荐、分享卡片美化，放到二期再去迭代完全来得及。一个能跑且体验好的核心功能，比十个半成品更有说服力。

哪怕你现在只是照着这篇文章把环境搭起来、写完第一个查询接口，后面就是水到渠成的事情了。动手永远比看教程快。