1. 需求分析与技术选型为什么这套方案值得参考经常在技术社区里看到有人发类似的选题——springbootvue3基于Android的旅游导航系统——尤其是毕设季和接私活的时候这类题目几乎成了标配。说实话这个题目的确适合用来练手因为它的技术栈覆盖得很全后端有Spring Boot管理端有Vue3移动端有Android业务上又要跟地图、定位、路线规划这些真实场景挂钩。你做完这一套基本就把一个完整产品从0到1的链路走了一遍而且任何一个环节拿出来都能在面试里聊上几句。先说说这套系统要解决的业务问题。旅游导航系统不是简单地把地图嵌进App里它至少要覆盖几件事游客打开App能找到附近有哪些景点、能看到景点的介绍和评价、能规划从当前位置到景点的路线、能获取导航引导而管理端需要维护景点数据、处理用户反馈、看运营数据。核心是把地理信息服务和业务数据服务揉在一起让用户在一个App里完成从发现目的地到抵达目的地的完整闭环。再来说技术选型的逻辑。题目里已经定死了三个关键词Spring Boot、Vue3、Android。这其实是一个很常见的全栈组合——Spring Boot负责提供RESTful APIVue3负责搭建管理后台Android作为面向游客的移动端入口。地图能力不在这三者范围内通常来说会引入一家地图开放平台的SDK和Web服务API来支撑。为什么这么组合因为Spring Boot生态成熟、招人好招、资料多Vue3的Composition API写管理后台非常顺手Android原生开发对地图SDK的支持最完整、权限控制和系统集成最可控。如果你准备自己完整做一遍这个项目我的建议是先把功能清单列清楚否则容易陷入地图SDK怎么调的细节里出不来。下面这个功能表格是这类系统最常见的划分方式你可以直接拿去用端核心功能说明Android端地图展示、定位、周边景点搜索、路线规划、景点详情、收藏、评论面向游客依赖地图SDK和后端API管理后台景点CRUD、分类管理、用户管理、评论审核、数据统计Vue3 Element Plus实现面向运营人员后端服务用户认证、景点数据接口、评论/收藏接口、距离计算、热门推荐、地图服务代理Spring Boot统一提供以上是最小可用版本再往下做还可以加语音播报、AR导航、足迹记录、行程规划但先把骨架搭对后面加功能都是锦上添花。我接触过的不少半途而废的项目问题都不是功能太少而是架构一开始就没想清楚后面越写越乱。这一篇我会从后端、Android、Vue3、部署联调四个方向把关键点都过一遍重点放在那些文档里不会写但你一定会踩的细节上。2. 系统架构与数据模型三端联动的关键设计2.1 整体架构如何拆分这套系统建议采用标准的前后端分离架构Android作为前端消费者Vue3管理后台作为另一个前端消费者两者都通过HTTP/HTTPS请求访问Spring Boot后端API。后端连接MySQL存储业务数据同时调用地图开放平台的服务端API完成逆地理编码、POI搜索、路径规划等地理能力。架构上的第一个决策点是地图能力放在哪一端调用。这里有两种路线。第一种是Android端直接集成地图SDK定位、搜索、路线规划全部由SDK完成后端只存业务数据第二种是Android端只负责展示把地理能力通过后端代理转发给地图Web服务API。我推荐用第一种为主、第二种为辅的混合方式——交互性强的操作地图拖动、定位、导航过程用Android端SDK需要跟业务数据结合的操作如按距我最近排序、查询某景点驾车路线)在后端聚合因为这类接口往往要同时查数据库和地图服务放后端更统一。管理后台和Android端都会调后端的登录、景点列表、评论接口所以权限设计必须做。项目里我用的是JWTJSON Web Token方案登录成功后后端签发token后续请求在Header里携带后端通过拦截器统一校验。游客端的浏览类接口可以放行涉及个人数据的接口收藏、评论、我的路线必须校验token。2.2 数据库表结构设计要点数据库设计是这类系统最容易返工的地方。第一个原则是围绕景点实体展开第二个原则是把地理坐标直接冗余在业务表里不要反过来去查地图服务。我设计过的表结构大致如下你可以根据实际情况增减字段。用户表t_user用户ID、昵称、手机号、密码BCrypt加密存储、头像URL、注册时间、状态。游客端登录我建议同时支持手机号密码登录和第三方授权登录第三方登录只需要多存一个openId字段前期可以先不做。景点表t_scenic景点ID、名称、简介、详细描述、分类ID、经度、纬度、地址、封面图URL、轮播图URL集合JSON存储、开放时间、门票价格、联系电话、评分、浏览量、收藏量、状态上架/下架/待审核。这里最重要的是一开始就把经度和纬度字段加进去并建索引后面所有附近景点、按距离排序的功能都依赖这两个字段。分类表t_category分类ID、分类名称、排序号。分类一般分自然风光、历史遗迹、主题乐园、博物馆、美食街等不要分太细否则运营时新增数据会很痛苦。评论表t_comment评论ID、景点ID、用户ID、评分1-5、内容、图片URL、发布时间、状态正常/屏蔽/待审核。评论是UGC内容一定要留状态字段管理后台要做审核和屏蔽能力。收藏表t_favorite收藏ID、用户ID、景点ID、创建时间加唯一约束(user_id, scenic_id)防止重复收藏。浏览记录表t_history记录ID、用户ID、景点ID、浏览时间用于最近浏览和个人化推荐。路线规划表t_route如果只是临时查询路线路线不需要落库但如果要做我的行程功能就需要保存路线起点、终点、途经点、交通方式、距离、耗时等信息。这个功能看你的项目深度来定MVP阶段可以不做。这几张表是业务主链路增删改查的开发量不大真正花时间的是写查询SQL时要结合经纬度做距离计算。后面的章节我会专门讲这个点。3. Spring Boot后端地理业务接口的实现逻辑3.1 项目初始化与分层结构Spring Boot项目建议直接用Spring Initializr生成版本选当前稳定版如果是Spring Boot 3.x注意JDK要用17。引入的依赖包括spring-boot-starter-web、spring-boot-starter-validation、mybatis-plus-spring-boot3-starter、mysql-connector-j、spring-boot-starter-data-redis用于缓存热点数据和token刷新、jjwtJWT、hutool工具类、lombok。分层结构我习惯这样组织com.example.tour ├── controller # 接口层只做参数接收和结果封装 ├── service # 业务逻辑层处理核心业务 ├── mapper # MyBatis-Plus的Mapper接口 ├── entity # 数据库实体类 ├── dto # 请求/响应对象避免直接暴露实体 ├── config # 配置类拦截器、跨域、Redis等 ├── common # 统一返回结果、异常处理、常量 └── utils # 工具类距离计算、JWT等这里有个经验Controller层一定要薄业务逻辑尽量沉淀在Service层。因为这类项目越写到后面Service里的逻辑会越来越复杂比如查询附近景点要合并距离计算、排序、缓存、分页如果一开始就把逻辑堆在Controller里后面几乎没法维护。3.2 统一返回结果与异常处理前后端分离项目中Android端和Vue3管理后台都需要识别接口的成功与失败。我建议封装一个统一的返回体Data public class ResultT { private Integer code; // 200表示成功 private String message; // 提示信息 private T data; // 数据负载 public static T ResultT ok(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT fail(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }code设计上200表示成功401表示未登录或token过期403表示无权限500表示业务/系统异常。Android端拦截到401时应该引导用户重新登录Vue3管理后台则在axios响应拦截器里统一跳转到登录页。同时配合全局异常处理器RestControllerAdvice把业务异常、参数校验异常、系统异常分别处理这样接口层可以少写很多try-catch。你可能会觉得这个步骤不起眼但实际联调时一个格式混乱的返回体会让三端对接的人都想骂人——统一返回值是这类多人项目最值得一开始就定下来的规范。3.3 经纬度距离计算与附近景点查询这是旅游导航系统后端最核心的查询场景。用户打开App后客户端拿到当前经纬度请求后端获取附近的景点后端要返回按距离排序的景点列表。常见方案有两种。第一种是MySQL直接计算适合数据量不大的项目第二种是引入Redis GEO或者Elasticsearch适合数据量大的场景。对毕设和中小型项目MySQL方案完全够用前提是几条SQL写法要清楚。MySQL中用得比较多的距离公式是Haversine可以直接在SQL里写也可以查出数据后在Java里算。我建议在SQL里算因为可以直接order bySELECT id, name, longitude, latitude, (6371 * acos( cos(radians(#{lat})) * cos(radians(latitude)) * cos(radians(longitude) - radians(#{lng})) sin(radians(#{lat})) * sin(radians(latitude)) )) AS distance FROM t_scenic WHERE status 1 ORDER BY distance ASC LIMIT #{pageSize}这个SQL的逻辑很简单把地球近似看作半径6371公里的球体通过两点的经纬度计算球面距离。实际项目里为了让性能更好可以先缩小范围再精确计算——用经纬度差约0.01度对应约1公里的经验值先用WHERE把范围锁定在5公里内再在Java侧做精确排序。如下所示// 先粗筛以用户位置为中心向外扩0.05度约5公里 double minLat lat - 0.05; double maxLat lat 0.05; double minLng lng - 0.05; double maxLng lng 0.05; // MyBatis-Plus中构造lambdaQuery LambdaQueryWrapperScenic wrapper new LambdaQueryWrapper(); wrapper.between(Scenic::getLatitude, minLat, maxLat) .between(Scenic::getLongitude, minLng, maxLng) .eq(Scenic::getStatus, 1);粗筛完之后在Java里用Haversine公式计算精确距离并排序。好处是SQL执行快坏处是精度略低但对附近景点这种业务场景来说完全够用。如果项目数据量进一步增长可以给经纬度字段加联合索引基本不会有性能瓶颈。3.4 地图Web服务API的代理封装Android端通过地图SDK能直接完成定位和路线规划但有些能力需要服务端配合。典型场景是Android端传入用户位置后端返回该位置附近的POI比如景点酒店停车场或者后端把一个地点的文本描述转成经纬度地理编码。这些能力要通过HTTP调用地图开放平台的Web服务API然后把结果加工成自己的业务数据返回给客户端。我的做法是在后端单独做一个MapService统一封装地图API的调用Service public class MapService { private final RestTemplate restTemplate; public MapService(RestTemplate restTemplate) { this.restTemplate restTemplate; } public String searchPoi(String keyword, double lat, double lng, int radius) { // 构造请求参数 String url https://restapi.example.com/v3/place/around ?location lng , lat keywords URLEncoder.encode(keyword) radius radius key apiKey; // 调用并解析 ResponseEntityString response restTemplate.getForEntity(url, String.class); return response.getBody(); } }需要注意几个问题。一是API Key不要硬编码在代码里放到配置文件或环境变量中因为这类项目经常会上传到公开仓库密钥一旦泄露会被盗刷。二是地图API有配额限制测试阶段经常遇到QUOTA_EXCEEDED后端要做缓存和降级处理避免客户端频繁触发。三是请求和响应都要打日志方便排查为什么这个POI搜不到为什么定位结果不对这类问题。第三方服务的排错第一件事永远是看原始请求和原始响应。3.5 JWT认证与登录链路登录链路是游客端和管理端都要用的。用户提交手机号密码后端先查用户表用BCrypt校验密码成功后生成JWT返回。JWT的payload中放userId和role基于jasypt或jjwt的库生成签名token。// 生成token示例 String token Jwts.builder() .setSubject(userId.toString()) .claim(role, user.getRole()) .setExpiration(new Date(System.currentTimeMillis() 7L * 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();拦截器侧需要做两件事放行登录、注册、景点列表、景点详情等公开接口其他接口校验token同时把解析出的userId放到ThreadLocal或请求属性里方便Service层使用。我见过不少项目把token校验写在每个Controller里代码重复量很大而且容易漏——统一拦截器是唯一正确做法。还有一个细节管理后台和游客App的接口虽然共用一套后端但建议在JWT的role字段里区分。管理员的接口要加RequireRole(ADMIN)之类的注解配合拦截器做二次校验防止游客token直接调用管理接口。4. Android客户端地图渲染、定位与路线规划的落地细节4.1 项目工程结构与SDK引入Android端建议用Kotlin写现在的Android项目基本都转Kotlin了地图SDK对Kotlin的支持也很完善。工程结构按功能包来分ui页面、vmViewModel、api网络请求、model数据模型、adapter列表适配器、utils工具类。网络层用Retrofit OkHttp图片加载用Coil或GlideMapSDK根据你选的地图开放平台在build.gradle中引入。引入地图SDK时有几个坑要提前知道。第一是so文件架构默认要配置abiFilters否则在部分真机上会出现找不到so文件的闪退。第二是包名要和申请API Key时填写的包名完全一致不一致直接无法初始化日志里会提示鉴权失败。第三是AndroidManifest.xml中要声明权限这里最容易漏的就是定位权限和网络权限。4.2 定位与权限处理定位是整个App最先触发的功能。Android从6.0开始要求运行时权限需要同时申请ACCESS_FINE_LOCATION和ACCESS_COARSE_LOCATIONif (ContextCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION) ! PackageManager.PERMISSION_GRANTED) { ActivityCompat.requestPermissions(this, new String[]{ Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_COARSE_LOCATION }, LOCATION_PERMISSION_REQUEST_CODE); }到了Android 10及以上还要在应用信息页或者代码里请求期间允许访问精确位置对应ACCESS_BACKGROUND_LOCATION权限要单独申请。很多新手在这个地方栽跟头——前台定位没问题App退到后台再回前台就定位失败。所以定位逻辑要放在onResume中重新触发同时做好用户拒绝权限和权限被永久拒绝的两套提示。还有个测试阶段的常见问题模拟器定位。很多Android模拟器虽然提供了设置GPS坐标的功能但地图SDK在模拟器上的定位非常不稳定。我的经验是真机调试为主模拟器为辅模拟器实在定位不到就手动在地图中心设一个测试点。4.3 地图初始化与标记点展示地图初始化的核心代码是绑定生命周期并在onCreate中加载地图class MainActivity : AppCompatActivity() { private lateinit var mapView: MapView override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) mapView findViewById(R.id.map_view) mapView.onCreate(savedInstanceState) } override fun onResume() { super.onResume() mapView.onResume() } override fun onPause() { super.onPause() mapView.onPause() } override fun onDestroy() { super.onDestroy() mapView.onDestroy() } }地图加载成功后通常会把当前定位位置显示在地图上然后请求后端景点列表把景点经纬度转成Marker添加到地图上。注意Marker数量不宜过多一页展示几十个就会卡顿一般做法是只展示当前可视区域内的景点。可以通过后端接口传左下角经纬度和右上角经纬度做矩形范围查询也可以在前端做Marker的可见性裁剪。MarkerView的点击事件承载着进入景点详情的入口这里要把景点ID绑定到Marker对象上不要在回调里再写一堆if-else去判断是哪个Marker。代码上看绑定ID的做法是val options MarkerOptions() .position(LatLng(lat, lng)) .title(scenic.name) marker map.addMarker(options) marker.obj scenic.id4.4 周边搜索与搜索建议搜索功能是游客找景点的主要方式。实现上有两种路径一种是直接调地图SDK的POI搜索输入“景点”返回周边POI另一种是调后端接口搜索自己数据库里的景点。我建议两者结合搜索词优先匹配业务库业务库没有结果再用地图POI兜底。原因是业务库里的景点信息通常比地图POI更准确——门票、开放时间、图片都是你自己运营的POI只有名称和坐标展示在列表里体验会差很多。搜索页面还要做搜索历史和热门搜索两个板块。搜索历史存到Android的DataStore或Room里热门搜索从后端接口获取通常是统计用户搜索词的频率排Top N。这两个功能看着小但对于旅游类App来说能明显提升留存和搜索成功率。4.5 路线规划与导航页实现路线规划是导航系统的题眼。Android端拿到用户当前经纬度和目标景点经纬度后调地图SDK的路线规划接口支持步行、骑行、驾车、公交四种模式。结果会返回多条路线每条包含距离、预计耗时、分段步行指示。在地图上画出路线轨迹并在底部弹出一个路线信息卡片。这里有一个产品层面的细节默认选哪条路线。地图SDK通常返回多条路线我实测的经验是不要默认选第一条——第一条往往是推荐路线但对于步行用户来说可能推荐了一条适合驾车但步行绕远的路。所以要看你App的使用场景来定游客在城市里逛默认用步行模式外地自驾来的默认用驾车模式。可以在设置页让用户选择默认交通方式。导航页的启动分为模拟导航和真实导航两类都不会自动展开——我们的App不是一个车载导航仪更多是给游客看路线、约车、步行用的。真实导航开启时Android端会持续监听GPS位置变化在地图上刷新位置标记并在接近转弯点时有语音播报。这个功能测试必须依赖真机。5. Vue3管理后台景点运营与统计模块的搭建要点5.1 搭建脚手架与登录鉴权管理后台我用Vite Vue3 TypeScript Element Plus搭建。为什么不推荐用Vue CLIVite的启动速度和热更新效率明显更优Vue3生态目前也全面转向Vite了。初始化命令简单一句话npm create vitelatest tour-admin -- --template vue-ts登录逻辑跟Android端共用后端的JWT接口。前端在axios请求拦截器里从localStorage取出token设置到请求头在响应拦截器里判断code 401时清空本地用户信息跳转登录页。路由守卫里也要做token判断未登录访问非公开页面时重定向。这里有一个实操问题Vite开发环境与后端接口的跨域。Spring Boot默认不允许跨域最简单的方式是在Vite的vite.config.ts里配置代理export default defineConfig({ server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })所有请求都走/api前缀开发环境由Vite代理转发生产环境由Nginx做同样的代理。这样前端代码里不写后端地址环境切换时只改配置。5.2 景点管理模块的完整功能景点管理是后台的核心模块功能覆盖列表、筛选、新增、编辑、详情预览、上下架。列表页用Element Plus的el-table展示列包括景点名称、分类、地址、经纬度、状态、评分、收藏数、创建时间。筛选条件包括分类、状态、关键词搜索。新增/编辑表单用el-dialogel-form组成字段较多建议分组展示基础信息名称、简介、分类、状态、地理信息经度、纬度、地址、运营信息开放时间、门票价格、联系电话、图片信息封面图、轮播图。图片上传这块我建议后端提供一个单独的上传接口接收文件后存储到本地磁盘或云存储返回URL。注意上传文件时要校验文件类型和大小同时在后端做统一的MultipartFile处理。图片URL存储到数据库时只存相对路径前端访问时拼接域名这样将来迁移存储位置不需要改数据库。经纬度字段别让运营手填——填错的概率极高。一个省力的做法在表单里嵌一个地图选择器运营点击地图某个位置自动把经纬度填入表单。实现上可以加载地图SDKWeb端监听click事件获取坐标。5.3 数据统计可视化统计模块一般包括总景点数、总评论数、总收藏数、今日新增用户、景点浏览TOP10、分类占比。图表库用ECharts的Vue3封装vue-echarts后端提供聚合接口。聚合SQL其实很简单比如按分类统计景点数SELECT c.name AS category_name, COUNT(s.id) AS cnt FROM t_category c LEFT JOIN t_scenic s ON c.id s.category_id GROUP BY c.id, c.name浏览TOP10就是按浏览量倒序查景点表。这些数据量不大直接查库就行不用额外引入中间件做数据管道。如果某天数据量大到需要优化再考虑定时任务把统计结果预聚合到一张报表表里定时刷新即可。6. 联调、打包与上线实录实测中的坑和解决办法6.1 三方通信的联调流程这套系统至少要打通三条链路Android ↔ 后端、管理后台 ↔ 后端、后端 ↔ 地图API。联调顺序建议是后端先把所有自测接口跑通管理后台接入Android最后接。因为Android端涉及真机、模拟器、打包签名、权限弹窗等变数问题最多留足时间去磨。联调阶段要建一个固定的接口文档不推荐写Word或PDF直接用Apifox或者Swagger在线维护接口变更及时同步。实际项目里我见过好多次前端和后端吵起来原因都是后端改了字段没通知前端调用时拿不到预期数据。你要是嫌工具配置麻烦至少要在后端的Swagger页面上标注每个字段的含义和示例值。6.2 Android真机与后端联调的三个重点坑第一个坑是在真机上访问不到后端。Android模拟器访问电脑上的localhost:8080可以用10.0.2.2但真机必须用电脑的局域网IP而且手机和电脑要连同一个WiFi。如果你的电脑开了防火墙8080端口会被拦需要手动在防火墙中放行。第二个坑是Android9及以上默认禁止HTTP明文请求。如果后端没有配置HTTPS需要在AndroidManifest.xml里允许明文流量application android:usesCleartextTraffictrue ... 第三个坑是64位so文件与API Key配置。地图SDK在build.gradle里要设置ndk.abiFilters只保留armeabi-v7a和arm64-v8a。API Key申请时填写的包名如果和实际applicationId不一致地图会白屏并在日志输出鉴权失败请检查你的SHA1和PackageName。打包后如果在另一个机型上白屏优先检查这两项。6.3 管理后台生产部署方案管理后台构建后是一堆静态文件部署步骤很简单先npm run build把dist目录的产物放到Nginx的html目录下再做两个配置。第一个是前端路由采用history模式时需要配置Nginx把非静态文件的请求都重定向到index.html否则刷新页面会404location / { try_files $uri $uri/ /index.html; }第二个是对/api的代理location /api { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }后端Spring Boot打jar包部署时注意数据库连接配置不要用localhost——如果MySQL单独跑在一台服务器上要写内网IP。另外生产环境建议关闭Swagger和接口文档暴露避免安全风险。6.4 数据初始化与缓存策略系统上线前景点数据不是空库直接上线的你需要至少准备一个城市的基础景点数据。一批数据来源可以是大平台POI抓取但要注意版权和合规更稳妥的做法是用地图平台的POI搜索结果再人工审核补充图片和描述。人工审核这一步别省很多项目上线后被用户吐槽景点信息是错的基本都是省了审核。热点数据热门景点列表、首页推荐位用Redis缓存缓存失效时间设10-30分钟就够了。我在联调时发现如果不加缓存首页每次刷新的景点列表请求压力虽然不算大但配合地图SDK的并发请求后端偶发超时。加了缓存之后接口响应从60-80毫秒降到5毫秒体验提升非常明显。7. 整体经验复盘与后续扩展思路整套系统做下来我最大的体会是技术栈本身不算难真正的复杂度在于三端对数据语义的统一理解。比如经纬度字段数据库存的是double类型后端返回的JSON是字符串还是数字Android端解析的时候会不会丢精度Vue3后台展示时是不是要保留6位小数——这些问题在联调阶段全都会暴露。我的建议是在后端DTO里把经纬度明确为double类型并保持6位小数数据库字段用decimal(10,6)全局统一不要各端自己转换。另一个很实用的技巧是把距离和排序这类通用逻辑抽象成后端公共方法不要Android端算一遍、Vue3端又算一遍。距离计算、评分排序、热门排行这些规则都放在Service层统一实现客户端只负责展示结果。如果后续还想继续扩展可以考虑几个方向把景点推荐从按距离排序升级成协同过滤标签匹配给Android端加入足迹记录和行程规划功能管理后台增加用户画像和漏斗分析。这些功能加在现有架构上都不会伤筋动骨因为底层的用户、景点、评论、收藏表结构已经够稳固。我个人的习惯是这类全栈项目做完之后把数据库建表SQL、接口文档、部署文档整理成一套完整的交付资料。一方面后续自己接类似私活可以快速复用另一方面这类文档在毕业答辩或者项目复盘时都是加分项。你如果正在做或者准备做这个项目遇到具体报错卡壳了可以按这个思路去排查先看日志定位到哪一层是Android端没有拿到数据还是后端SQL报错还是地图API返回异常——90%的问题都能在日志里找到答案。
1. 需求分析与技术选型为什么这套方案值得参考经常在技术社区里看到有人发类似的选题——springbootvue3基于Android的旅游导航系统——尤其是毕设季和接私活的时候这类题目几乎成了标配。说实话这个题目的确适合用来练手因为它的技术栈覆盖得很全后端有Spring Boot管理端有Vue3移动端有Android业务上又要跟地图、定位、路线规划这些真实场景挂钩。你做完这一套基本就把一个完整产品从0到1的链路走了一遍而且任何一个环节拿出来都能在面试里聊上几句。先说说这套系统要解决的业务问题。旅游导航系统不是简单地把地图嵌进App里它至少要覆盖几件事游客打开App能找到附近有哪些景点、能看到景点的介绍和评价、能规划从当前位置到景点的路线、能获取导航引导而管理端需要维护景点数据、处理用户反馈、看运营数据。核心是把地理信息服务和业务数据服务揉在一起让用户在一个App里完成从发现目的地到抵达目的地的完整闭环。再来说技术选型的逻辑。题目里已经定死了三个关键词Spring Boot、Vue3、Android。这其实是一个很常见的全栈组合——Spring Boot负责提供RESTful APIVue3负责搭建管理后台Android作为面向游客的移动端入口。地图能力不在这三者范围内通常来说会引入一家地图开放平台的SDK和Web服务API来支撑。为什么这么组合因为Spring Boot生态成熟、招人好招、资料多Vue3的Composition API写管理后台非常顺手Android原生开发对地图SDK的支持最完整、权限控制和系统集成最可控。如果你准备自己完整做一遍这个项目我的建议是先把功能清单列清楚否则容易陷入地图SDK怎么调的细节里出不来。下面这个功能表格是这类系统最常见的划分方式你可以直接拿去用端核心功能说明Android端地图展示、定位、周边景点搜索、路线规划、景点详情、收藏、评论面向游客依赖地图SDK和后端API管理后台景点CRUD、分类管理、用户管理、评论审核、数据统计Vue3 Element Plus实现面向运营人员后端服务用户认证、景点数据接口、评论/收藏接口、距离计算、热门推荐、地图服务代理Spring Boot统一提供以上是最小可用版本再往下做还可以加语音播报、AR导航、足迹记录、行程规划但先把骨架搭对后面加功能都是锦上添花。我接触过的不少半途而废的项目问题都不是功能太少而是架构一开始就没想清楚后面越写越乱。这一篇我会从后端、Android、Vue3、部署联调四个方向把关键点都过一遍重点放在那些文档里不会写但你一定会踩的细节上。2. 系统架构与数据模型三端联动的关键设计2.1 整体架构如何拆分这套系统建议采用标准的前后端分离架构Android作为前端消费者Vue3管理后台作为另一个前端消费者两者都通过HTTP/HTTPS请求访问Spring Boot后端API。后端连接MySQL存储业务数据同时调用地图开放平台的服务端API完成逆地理编码、POI搜索、路径规划等地理能力。架构上的第一个决策点是地图能力放在哪一端调用。这里有两种路线。第一种是Android端直接集成地图SDK定位、搜索、路线规划全部由SDK完成后端只存业务数据第二种是Android端只负责展示把地理能力通过后端代理转发给地图Web服务API。我推荐用第一种为主、第二种为辅的混合方式——交互性强的操作地图拖动、定位、导航过程用Android端SDK需要跟业务数据结合的操作如按距我最近排序、查询某景点驾车路线)在后端聚合因为这类接口往往要同时查数据库和地图服务放后端更统一。管理后台和Android端都会调后端的登录、景点列表、评论接口所以权限设计必须做。项目里我用的是JWTJSON Web Token方案登录成功后后端签发token后续请求在Header里携带后端通过拦截器统一校验。游客端的浏览类接口可以放行涉及个人数据的接口收藏、评论、我的路线必须校验token。2.2 数据库表结构设计要点数据库设计是这类系统最容易返工的地方。第一个原则是围绕景点实体展开第二个原则是把地理坐标直接冗余在业务表里不要反过来去查地图服务。我设计过的表结构大致如下你可以根据实际情况增减字段。用户表t_user用户ID、昵称、手机号、密码BCrypt加密存储、头像URL、注册时间、状态。游客端登录我建议同时支持手机号密码登录和第三方授权登录第三方登录只需要多存一个openId字段前期可以先不做。景点表t_scenic景点ID、名称、简介、详细描述、分类ID、经度、纬度、地址、封面图URL、轮播图URL集合JSON存储、开放时间、门票价格、联系电话、评分、浏览量、收藏量、状态上架/下架/待审核。这里最重要的是一开始就把经度和纬度字段加进去并建索引后面所有附近景点、按距离排序的功能都依赖这两个字段。分类表t_category分类ID、分类名称、排序号。分类一般分自然风光、历史遗迹、主题乐园、博物馆、美食街等不要分太细否则运营时新增数据会很痛苦。评论表t_comment评论ID、景点ID、用户ID、评分1-5、内容、图片URL、发布时间、状态正常/屏蔽/待审核。评论是UGC内容一定要留状态字段管理后台要做审核和屏蔽能力。收藏表t_favorite收藏ID、用户ID、景点ID、创建时间加唯一约束(user_id, scenic_id)防止重复收藏。浏览记录表t_history记录ID、用户ID、景点ID、浏览时间用于最近浏览和个人化推荐。路线规划表t_route如果只是临时查询路线路线不需要落库但如果要做我的行程功能就需要保存路线起点、终点、途经点、交通方式、距离、耗时等信息。这个功能看你的项目深度来定MVP阶段可以不做。这几张表是业务主链路增删改查的开发量不大真正花时间的是写查询SQL时要结合经纬度做距离计算。后面的章节我会专门讲这个点。3. Spring Boot后端地理业务接口的实现逻辑3.1 项目初始化与分层结构Spring Boot项目建议直接用Spring Initializr生成版本选当前稳定版如果是Spring Boot 3.x注意JDK要用17。引入的依赖包括spring-boot-starter-web、spring-boot-starter-validation、mybatis-plus-spring-boot3-starter、mysql-connector-j、spring-boot-starter-data-redis用于缓存热点数据和token刷新、jjwtJWT、hutool工具类、lombok。分层结构我习惯这样组织com.example.tour ├── controller # 接口层只做参数接收和结果封装 ├── service # 业务逻辑层处理核心业务 ├── mapper # MyBatis-Plus的Mapper接口 ├── entity # 数据库实体类 ├── dto # 请求/响应对象避免直接暴露实体 ├── config # 配置类拦截器、跨域、Redis等 ├── common # 统一返回结果、异常处理、常量 └── utils # 工具类距离计算、JWT等这里有个经验Controller层一定要薄业务逻辑尽量沉淀在Service层。因为这类项目越写到后面Service里的逻辑会越来越复杂比如查询附近景点要合并距离计算、排序、缓存、分页如果一开始就把逻辑堆在Controller里后面几乎没法维护。3.2 统一返回结果与异常处理前后端分离项目中Android端和Vue3管理后台都需要识别接口的成功与失败。我建议封装一个统一的返回体Data public class ResultT { private Integer code; // 200表示成功 private String message; // 提示信息 private T data; // 数据负载 public static T ResultT ok(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT fail(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }code设计上200表示成功401表示未登录或token过期403表示无权限500表示业务/系统异常。Android端拦截到401时应该引导用户重新登录Vue3管理后台则在axios响应拦截器里统一跳转到登录页。同时配合全局异常处理器RestControllerAdvice把业务异常、参数校验异常、系统异常分别处理这样接口层可以少写很多try-catch。你可能会觉得这个步骤不起眼但实际联调时一个格式混乱的返回体会让三端对接的人都想骂人——统一返回值是这类多人项目最值得一开始就定下来的规范。3.3 经纬度距离计算与附近景点查询这是旅游导航系统后端最核心的查询场景。用户打开App后客户端拿到当前经纬度请求后端获取附近的景点后端要返回按距离排序的景点列表。常见方案有两种。第一种是MySQL直接计算适合数据量不大的项目第二种是引入Redis GEO或者Elasticsearch适合数据量大的场景。对毕设和中小型项目MySQL方案完全够用前提是几条SQL写法要清楚。MySQL中用得比较多的距离公式是Haversine可以直接在SQL里写也可以查出数据后在Java里算。我建议在SQL里算因为可以直接order bySELECT id, name, longitude, latitude, (6371 * acos( cos(radians(#{lat})) * cos(radians(latitude)) * cos(radians(longitude) - radians(#{lng})) sin(radians(#{lat})) * sin(radians(latitude)) )) AS distance FROM t_scenic WHERE status 1 ORDER BY distance ASC LIMIT #{pageSize}这个SQL的逻辑很简单把地球近似看作半径6371公里的球体通过两点的经纬度计算球面距离。实际项目里为了让性能更好可以先缩小范围再精确计算——用经纬度差约0.01度对应约1公里的经验值先用WHERE把范围锁定在5公里内再在Java侧做精确排序。如下所示// 先粗筛以用户位置为中心向外扩0.05度约5公里 double minLat lat - 0.05; double maxLat lat 0.05; double minLng lng - 0.05; double maxLng lng 0.05; // MyBatis-Plus中构造lambdaQuery LambdaQueryWrapperScenic wrapper new LambdaQueryWrapper(); wrapper.between(Scenic::getLatitude, minLat, maxLat) .between(Scenic::getLongitude, minLng, maxLng) .eq(Scenic::getStatus, 1);粗筛完之后在Java里用Haversine公式计算精确距离并排序。好处是SQL执行快坏处是精度略低但对附近景点这种业务场景来说完全够用。如果项目数据量进一步增长可以给经纬度字段加联合索引基本不会有性能瓶颈。3.4 地图Web服务API的代理封装Android端通过地图SDK能直接完成定位和路线规划但有些能力需要服务端配合。典型场景是Android端传入用户位置后端返回该位置附近的POI比如景点酒店停车场或者后端把一个地点的文本描述转成经纬度地理编码。这些能力要通过HTTP调用地图开放平台的Web服务API然后把结果加工成自己的业务数据返回给客户端。我的做法是在后端单独做一个MapService统一封装地图API的调用Service public class MapService { private final RestTemplate restTemplate; public MapService(RestTemplate restTemplate) { this.restTemplate restTemplate; } public String searchPoi(String keyword, double lat, double lng, int radius) { // 构造请求参数 String url https://restapi.example.com/v3/place/around ?location lng , lat keywords URLEncoder.encode(keyword) radius radius key apiKey; // 调用并解析 ResponseEntityString response restTemplate.getForEntity(url, String.class); return response.getBody(); } }需要注意几个问题。一是API Key不要硬编码在代码里放到配置文件或环境变量中因为这类项目经常会上传到公开仓库密钥一旦泄露会被盗刷。二是地图API有配额限制测试阶段经常遇到QUOTA_EXCEEDED后端要做缓存和降级处理避免客户端频繁触发。三是请求和响应都要打日志方便排查为什么这个POI搜不到为什么定位结果不对这类问题。第三方服务的排错第一件事永远是看原始请求和原始响应。3.5 JWT认证与登录链路登录链路是游客端和管理端都要用的。用户提交手机号密码后端先查用户表用BCrypt校验密码成功后生成JWT返回。JWT的payload中放userId和role基于jasypt或jjwt的库生成签名token。// 生成token示例 String token Jwts.builder() .setSubject(userId.toString()) .claim(role, user.getRole()) .setExpiration(new Date(System.currentTimeMillis() 7L * 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();拦截器侧需要做两件事放行登录、注册、景点列表、景点详情等公开接口其他接口校验token同时把解析出的userId放到ThreadLocal或请求属性里方便Service层使用。我见过不少项目把token校验写在每个Controller里代码重复量很大而且容易漏——统一拦截器是唯一正确做法。还有一个细节管理后台和游客App的接口虽然共用一套后端但建议在JWT的role字段里区分。管理员的接口要加RequireRole(ADMIN)之类的注解配合拦截器做二次校验防止游客token直接调用管理接口。4. Android客户端地图渲染、定位与路线规划的落地细节4.1 项目工程结构与SDK引入Android端建议用Kotlin写现在的Android项目基本都转Kotlin了地图SDK对Kotlin的支持也很完善。工程结构按功能包来分ui页面、vmViewModel、api网络请求、model数据模型、adapter列表适配器、utils工具类。网络层用Retrofit OkHttp图片加载用Coil或GlideMapSDK根据你选的地图开放平台在build.gradle中引入。引入地图SDK时有几个坑要提前知道。第一是so文件架构默认要配置abiFilters否则在部分真机上会出现找不到so文件的闪退。第二是包名要和申请API Key时填写的包名完全一致不一致直接无法初始化日志里会提示鉴权失败。第三是AndroidManifest.xml中要声明权限这里最容易漏的就是定位权限和网络权限。4.2 定位与权限处理定位是整个App最先触发的功能。Android从6.0开始要求运行时权限需要同时申请ACCESS_FINE_LOCATION和ACCESS_COARSE_LOCATIONif (ContextCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION) ! PackageManager.PERMISSION_GRANTED) { ActivityCompat.requestPermissions(this, new String[]{ Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_COARSE_LOCATION }, LOCATION_PERMISSION_REQUEST_CODE); }到了Android 10及以上还要在应用信息页或者代码里请求期间允许访问精确位置对应ACCESS_BACKGROUND_LOCATION权限要单独申请。很多新手在这个地方栽跟头——前台定位没问题App退到后台再回前台就定位失败。所以定位逻辑要放在onResume中重新触发同时做好用户拒绝权限和权限被永久拒绝的两套提示。还有个测试阶段的常见问题模拟器定位。很多Android模拟器虽然提供了设置GPS坐标的功能但地图SDK在模拟器上的定位非常不稳定。我的经验是真机调试为主模拟器为辅模拟器实在定位不到就手动在地图中心设一个测试点。4.3 地图初始化与标记点展示地图初始化的核心代码是绑定生命周期并在onCreate中加载地图class MainActivity : AppCompatActivity() { private lateinit var mapView: MapView override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) mapView findViewById(R.id.map_view) mapView.onCreate(savedInstanceState) } override fun onResume() { super.onResume() mapView.onResume() } override fun onPause() { super.onPause() mapView.onPause() } override fun onDestroy() { super.onDestroy() mapView.onDestroy() } }地图加载成功后通常会把当前定位位置显示在地图上然后请求后端景点列表把景点经纬度转成Marker添加到地图上。注意Marker数量不宜过多一页展示几十个就会卡顿一般做法是只展示当前可视区域内的景点。可以通过后端接口传左下角经纬度和右上角经纬度做矩形范围查询也可以在前端做Marker的可见性裁剪。MarkerView的点击事件承载着进入景点详情的入口这里要把景点ID绑定到Marker对象上不要在回调里再写一堆if-else去判断是哪个Marker。代码上看绑定ID的做法是val options MarkerOptions() .position(LatLng(lat, lng)) .title(scenic.name) marker map.addMarker(options) marker.obj scenic.id4.4 周边搜索与搜索建议搜索功能是游客找景点的主要方式。实现上有两种路径一种是直接调地图SDK的POI搜索输入“景点”返回周边POI另一种是调后端接口搜索自己数据库里的景点。我建议两者结合搜索词优先匹配业务库业务库没有结果再用地图POI兜底。原因是业务库里的景点信息通常比地图POI更准确——门票、开放时间、图片都是你自己运营的POI只有名称和坐标展示在列表里体验会差很多。搜索页面还要做搜索历史和热门搜索两个板块。搜索历史存到Android的DataStore或Room里热门搜索从后端接口获取通常是统计用户搜索词的频率排Top N。这两个功能看着小但对于旅游类App来说能明显提升留存和搜索成功率。4.5 路线规划与导航页实现路线规划是导航系统的题眼。Android端拿到用户当前经纬度和目标景点经纬度后调地图SDK的路线规划接口支持步行、骑行、驾车、公交四种模式。结果会返回多条路线每条包含距离、预计耗时、分段步行指示。在地图上画出路线轨迹并在底部弹出一个路线信息卡片。这里有一个产品层面的细节默认选哪条路线。地图SDK通常返回多条路线我实测的经验是不要默认选第一条——第一条往往是推荐路线但对于步行用户来说可能推荐了一条适合驾车但步行绕远的路。所以要看你App的使用场景来定游客在城市里逛默认用步行模式外地自驾来的默认用驾车模式。可以在设置页让用户选择默认交通方式。导航页的启动分为模拟导航和真实导航两类都不会自动展开——我们的App不是一个车载导航仪更多是给游客看路线、约车、步行用的。真实导航开启时Android端会持续监听GPS位置变化在地图上刷新位置标记并在接近转弯点时有语音播报。这个功能测试必须依赖真机。5. Vue3管理后台景点运营与统计模块的搭建要点5.1 搭建脚手架与登录鉴权管理后台我用Vite Vue3 TypeScript Element Plus搭建。为什么不推荐用Vue CLIVite的启动速度和热更新效率明显更优Vue3生态目前也全面转向Vite了。初始化命令简单一句话npm create vitelatest tour-admin -- --template vue-ts登录逻辑跟Android端共用后端的JWT接口。前端在axios请求拦截器里从localStorage取出token设置到请求头在响应拦截器里判断code 401时清空本地用户信息跳转登录页。路由守卫里也要做token判断未登录访问非公开页面时重定向。这里有一个实操问题Vite开发环境与后端接口的跨域。Spring Boot默认不允许跨域最简单的方式是在Vite的vite.config.ts里配置代理export default defineConfig({ server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })所有请求都走/api前缀开发环境由Vite代理转发生产环境由Nginx做同样的代理。这样前端代码里不写后端地址环境切换时只改配置。5.2 景点管理模块的完整功能景点管理是后台的核心模块功能覆盖列表、筛选、新增、编辑、详情预览、上下架。列表页用Element Plus的el-table展示列包括景点名称、分类、地址、经纬度、状态、评分、收藏数、创建时间。筛选条件包括分类、状态、关键词搜索。新增/编辑表单用el-dialogel-form组成字段较多建议分组展示基础信息名称、简介、分类、状态、地理信息经度、纬度、地址、运营信息开放时间、门票价格、联系电话、图片信息封面图、轮播图。图片上传这块我建议后端提供一个单独的上传接口接收文件后存储到本地磁盘或云存储返回URL。注意上传文件时要校验文件类型和大小同时在后端做统一的MultipartFile处理。图片URL存储到数据库时只存相对路径前端访问时拼接域名这样将来迁移存储位置不需要改数据库。经纬度字段别让运营手填——填错的概率极高。一个省力的做法在表单里嵌一个地图选择器运营点击地图某个位置自动把经纬度填入表单。实现上可以加载地图SDKWeb端监听click事件获取坐标。5.3 数据统计可视化统计模块一般包括总景点数、总评论数、总收藏数、今日新增用户、景点浏览TOP10、分类占比。图表库用ECharts的Vue3封装vue-echarts后端提供聚合接口。聚合SQL其实很简单比如按分类统计景点数SELECT c.name AS category_name, COUNT(s.id) AS cnt FROM t_category c LEFT JOIN t_scenic s ON c.id s.category_id GROUP BY c.id, c.name浏览TOP10就是按浏览量倒序查景点表。这些数据量不大直接查库就行不用额外引入中间件做数据管道。如果某天数据量大到需要优化再考虑定时任务把统计结果预聚合到一张报表表里定时刷新即可。6. 联调、打包与上线实录实测中的坑和解决办法6.1 三方通信的联调流程这套系统至少要打通三条链路Android ↔ 后端、管理后台 ↔ 后端、后端 ↔ 地图API。联调顺序建议是后端先把所有自测接口跑通管理后台接入Android最后接。因为Android端涉及真机、模拟器、打包签名、权限弹窗等变数问题最多留足时间去磨。联调阶段要建一个固定的接口文档不推荐写Word或PDF直接用Apifox或者Swagger在线维护接口变更及时同步。实际项目里我见过好多次前端和后端吵起来原因都是后端改了字段没通知前端调用时拿不到预期数据。你要是嫌工具配置麻烦至少要在后端的Swagger页面上标注每个字段的含义和示例值。6.2 Android真机与后端联调的三个重点坑第一个坑是在真机上访问不到后端。Android模拟器访问电脑上的localhost:8080可以用10.0.2.2但真机必须用电脑的局域网IP而且手机和电脑要连同一个WiFi。如果你的电脑开了防火墙8080端口会被拦需要手动在防火墙中放行。第二个坑是Android9及以上默认禁止HTTP明文请求。如果后端没有配置HTTPS需要在AndroidManifest.xml里允许明文流量application android:usesCleartextTraffictrue ... 第三个坑是64位so文件与API Key配置。地图SDK在build.gradle里要设置ndk.abiFilters只保留armeabi-v7a和arm64-v8a。API Key申请时填写的包名如果和实际applicationId不一致地图会白屏并在日志输出鉴权失败请检查你的SHA1和PackageName。打包后如果在另一个机型上白屏优先检查这两项。6.3 管理后台生产部署方案管理后台构建后是一堆静态文件部署步骤很简单先npm run build把dist目录的产物放到Nginx的html目录下再做两个配置。第一个是前端路由采用history模式时需要配置Nginx把非静态文件的请求都重定向到index.html否则刷新页面会404location / { try_files $uri $uri/ /index.html; }第二个是对/api的代理location /api { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }后端Spring Boot打jar包部署时注意数据库连接配置不要用localhost——如果MySQL单独跑在一台服务器上要写内网IP。另外生产环境建议关闭Swagger和接口文档暴露避免安全风险。6.4 数据初始化与缓存策略系统上线前景点数据不是空库直接上线的你需要至少准备一个城市的基础景点数据。一批数据来源可以是大平台POI抓取但要注意版权和合规更稳妥的做法是用地图平台的POI搜索结果再人工审核补充图片和描述。人工审核这一步别省很多项目上线后被用户吐槽景点信息是错的基本都是省了审核。热点数据热门景点列表、首页推荐位用Redis缓存缓存失效时间设10-30分钟就够了。我在联调时发现如果不加缓存首页每次刷新的景点列表请求压力虽然不算大但配合地图SDK的并发请求后端偶发超时。加了缓存之后接口响应从60-80毫秒降到5毫秒体验提升非常明显。7. 整体经验复盘与后续扩展思路整套系统做下来我最大的体会是技术栈本身不算难真正的复杂度在于三端对数据语义的统一理解。比如经纬度字段数据库存的是double类型后端返回的JSON是字符串还是数字Android端解析的时候会不会丢精度Vue3后台展示时是不是要保留6位小数——这些问题在联调阶段全都会暴露。我的建议是在后端DTO里把经纬度明确为double类型并保持6位小数数据库字段用decimal(10,6)全局统一不要各端自己转换。另一个很实用的技巧是把距离和排序这类通用逻辑抽象成后端公共方法不要Android端算一遍、Vue3端又算一遍。距离计算、评分排序、热门排行这些规则都放在Service层统一实现客户端只负责展示结果。如果后续还想继续扩展可以考虑几个方向把景点推荐从按距离排序升级成协同过滤标签匹配给Android端加入足迹记录和行程规划功能管理后台增加用户画像和漏斗分析。这些功能加在现有架构上都不会伤筋动骨因为底层的用户、景点、评论、收藏表结构已经够稳固。我个人的习惯是这类全栈项目做完之后把数据库建表SQL、接口文档、部署文档整理成一套完整的交付资料。一方面后续自己接类似私活可以快速复用另一方面这类文档在毕业答辩或者项目复盘时都是加分项。你如果正在做或者准备做这个项目遇到具体报错卡壳了可以按这个思路去排查先看日志定位到哪一层是Android端没有拿到数据还是后端SQL报错还是地图API返回异常——90%的问题都能在日志里找到答案。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
