户外救援这几年越来越多人关注一方面是户外徒步、山地穿越、野外露营的人群基数在涨另一方面是救援调度本身存在很大的信息断层。传统方式靠电话沟通、微信群报位置效率低且容易出错等真正出险情的时候时间就是生命。我做了一套基于JavaSpringBootSSM的户外救援系统把求助上报、定位追踪、任务指派、物资调度全流程串了起来今天把整个项目的设计思路、核心实现、踩坑记录完整分享出来。这套系统适合谁看如果你正在做类似的管理系统开发比如应急调度、工单派发、物流配送或者你是准备毕业设计、找工作需要SSM/SpringBoot项目经验的学生这篇文章都能给你一些直接能抄的作业。项目覆盖了用户权限、救援流程、地图定位、消息推送、数据统计这些高频业务场景技术点上涉及SpringBoot、MyBatis、Redis、WebSocket、高德地图API等算是比较典型的中后台移动端配合的项目形态。1. 项目背景与需求拆解1.1 户外救援场景里的真实痛点做这个系统之前我和几个户外俱乐部的领队聊过也在救援队的公开案例里翻了不少资料。户外救援最难的不是“救援”本身而是“信息匹配”。一个驴友在深山失联他最后出现的位置在哪里他带了什么装备有没有同伴这些信息如果不能快速汇聚到指挥中心救援队去了也是大海捞针。传统流程大致是这样的家属或者同伴拨打救援电话接线员记录信息再转发给救援队微信群队长在群里问“谁有空”然后大家各自开车过去。整个流程里至少存在三个问题信息碎片化。报警人的口述、现场的图片、坐标定位分别散落在电话、微信、短信里指挥人员需要手动拼凑。任务指派靠人工。哪个队伍离现场最近谁擅长山地搜救谁有无人机这些信息全靠队长脑子记。过程无法回溯。救援结束后要做复盘但整个过程的记录基本是空白连时间线都凑不齐。这套系统的核心目标就是把“报案-定位-响应-救援-复盘”全链路搬到线上。具体拆解下来需求主要集中在五个方面用户管理、救援请求管理、任务调度、物资管理、数据统计。每个模块都有明确的使用对象和业务边界不能做成大杂烩。1.2 技术选型为什么是SpringBootSSM这套组合技术选型上我最终采用了SpringBoot SpringMVC MyBatis这套经典组合用SpringBoot作为基础框架来整合SSM。有人可能会问既然是SSM为什么还要用SpringBoot这里要解释一下传统的SSM是指Spring SpringMVC MyBatis三个框架的手动整合需要写大量的XML配置比如web.xml、spring-mvc.xml、mybatis-config.xml光是配置文件就能把人绕晕。SpringBoot的核心价值在于自动配置和约定优于配置。它把SpringMVC、MyBatis这些组件的装配过程封装好了我只需要在pom.xml里引入对应的starter依赖再在application.yml里写少量配置就能跑起来。本质上底层还是SSM那套东西但开发效率提升了一大截。选这套组合而不是Spring Cloud或者微服务架构有几点考虑项目规模决定架构复杂度。救援系统的核心用户是救援队、管理员、普通用户并发量不会像电商秒杀那样夸张单体应用完全扛得住。团队技术栈匹配。SSM SpringBoot是Java后端最普及的技术组合招人容易、资料多、出了问题好排查。部署成本低。一个jar包就能跑不需要引入注册中心、配置中心、网关那一套对野外救援这种可能部署在临时服务器的场景反而更友好。数据库用了MySQL缓存用了Redis实时消息推送用了WebSocket定位服务接入了高德地图API。整套技术栈都是成熟稳定的方案没有为了炫技引入冷门框架。2. 系统整体设计与架构拆分2.1 功能模块全览整个系统按照使用角色划分为三个端用户端网页端、救援队端、管理后台。实际开发中我按照业务模块做了拆分每个模块独立开发、独立测试最后再聚合到主工程里。第一个模块是用户管理。包含注册、登录、个人信息维护、密码修改、实名认证。用户角色分为普通用户、救援队员、管理员三种权限控制采用Spring Security JWT的方式每次请求都携带Token后端通过拦截器校验身份和权限。这里要说明一下JWT天然适合这种前后端分离的项目服务端不需要存Session减轻了内存压力也方便后续做移动端接口复用。第二个模块是救援请求管理。用户遇到险情时可以填写求助表单包括当前位置通过地图选点、人数、伤势情况、物资需求、现场描述支持上传图片和视频。求助信息提交后系统会根据位置自动匹配最近的救援队伍并生成一条救援工单。第三个模块是救援任务调度。这是整个系统的核心救援队队长可以查看待处理的工单对工单进行接单、指派队员、更新救援进度。任务状态包括待受理、已接单、救援中、已完成、已关闭五种状态流转有严格的权限控制比如普通用户不能直接把任务改成已完成只有队长或者管理员可以。第四个模块是物资管理。户外救援离不开装备这个模块维护救援物资的入库、出库、库存预警。每件物资关联一个救援任务任务结束后自动扣减库存库存低于阈值时系统自动提醒管理员补货。第五个模块是数据统计。后台用ECharts做了几个看板包括救援请求数量趋势、任务完成率、响应时间分布、物资消耗排行。这些数据主要用于救援队的日常运营分析比如哪个季节求助最多、哪个区域的响应时间最长、哪些物资消耗最快方便提前做预案。2.2 角色权限与数据隔离设计权限设计这块我踩过一些坑一开始用了简单的拦截器判断角色后面发现不够灵活。例如救援队员和队长在同一个救援任务里能做的操作完全不同队员只能更新自己的救援进度队长却能指派整个队伍。单纯判断角色会漏掉很多细分场景。我最终采用了RBAC基于角色的访问控制模型角色和权限分离。用户表不直接关联权限而是关联角色角色再关联权限。一张用户表、一张角色表、一张权限表加上用户角色关系表和角色权限关系表一共五张表搞定。数据隔离上救援任务和用户之间通过创建者ID关联查询时强制带上条件。比如救援队员登录后只能看到分配给自己的任务以及本队伍的任务看不到其他队伍的数据避免信息泄露。这里我在MyBatis的Mapper层做了硬编码没有依赖框架级别的数据权限插件逻辑更透明排查问题也容易。2.3 数据库设计思路与核心表结构数据库是一个管理系统的地基设计不好后面全是坑。我按照业务模块画了ER图拆出了十几张核心表。这里挑几张重点的说一下。用户表sys_user字段包括userId、username、password、realName、phone、roleId、status、createTime。密码存的是BCrypt加密后的密文不存明文。status字段用于禁用账号比如队员离职后不需要删除数据直接禁用即可。求助工单表rescue_order是核心中的核心字段包括orderId、userId、location、longitude、latitude、peopleCount、injuryDesc、materialsNeed、images、status、assigneeTeamId、createTime、updateTime。位置信息单独存了经纬度是为了后续做距离计算。这里我用了高德地图的坐标体系GCJ-02注意不要和GPS的WGS-84坐标混用否则地图上会偏移几百米。救援任务表rescue_task和工单表是一对一关系字段包括taskId、orderId、teamId、leaderId、status、startTime、endTime、resultDesc。任务表单独拆出来是为了把“求助信息”和“救援执行”解耦。工单记录了用户上报了什么任务记录了救援队做了什么两者各司其职后面做统计数据时会很方便。物资表material和物资出入库记录表material_log是另一组核心表。物资表存储当前库存量每次出入库操作在material_log里插入一条记录同时更新material表的库存字段。这里要注意事务控制扣库存和插入日志必须在一个事务里不然会出现库存对不上的情况。数据库表关系用外键约束还是代码维护我的做法是不建物理外键只建普通索引。原因是物理外键在数据量大了之后影响写入性能而且很多团队维护历史数据时修改起来非常痛苦。表之间的关联关系通过业务代码保证查询时用JOIN或者多次查询组装。3. 核心功能实现与实操要点3.1 环境准备与项目骨架搭建开发环境我建议用这套配置JDK 1.8Maven 3.6以上MySQL 5.7以上Redis 5.0以上SpringBoot 2.3.x。为什么不用JDK 11或者17因为很多依赖和插件在老项目里没有适配而且网上搜解决方案的时候1.8的资料最多出了问题好排查。搭建项目骨架直接用Spring InitializrIDEA自带这个功能。我习惯手动选依赖核心的包括Spring Web、MyBatis、MySQL Driver、Redis、Spring Security、Lombok。注意SpringBoot版本别选太高2.3.x到2.7.x都行不要一上来就选3.x因为MyBatis和部分第三方组件的兼容性需要额外配置。pom.xml里面MyBatis相关的依赖建议直接用mybatis-spring-boot-starter版本用2.1.4兼容性好。如果要用代码生成器再加一个mybatis-generator-maven-plugin。Redis相关的用spring-boot-starter-data-redis默认用的是Lettuce连接池配置一下就够用。项目目录结构我是这样划分的controller接收前端请求做一些参数校验不写业务逻辑。service业务逻辑层接口和实现分开。mapperMyBatis的接口层配合XML文件使用。entity数据库实体类。dto数据传输对象用于接口入参和出参。config配置类比如WebMvc拦截器、WebSocket配置。utils工具类比如JWT工具、坐标计算工具。这个分包方式是业内最常见的好处是清晰、好维护面试的时候讲出来也顺。application.yml里核心配置有数据源、Redis、MyBatis的mapper路径和驼峰映射。这里有一个我当初踩过的坑MyBatis默认不开启驼峰映射如果数据库字段是create_time这种下划线风格实体类属性是createTime这种驼峰风格不开启的话查询结果全是null。需要在配置里加上mybatis.configuration.map-underscore-to-camel-case: true。3.2 用户登录与权限控制的完整实现登录这块我用的是Spring Security JWT方案。整个流程是这样的用户输入用户名密码后端去数据库比对BCrypt密文验证通过后生成一个JWT Token返回给前端。前端拿到Token后存到LocalStorage每次请求都在Header里带上Authorization: Bearer token。后端拦截器校验Token的合法性解析出用户ID和角色信息放行或者拒绝。JWT工具类主要做三件事生成Token、解析Token、校验Token。生成Token时把userId和role放进去过期时间设为24小时。这里要注意密钥不要明文写在代码里放到配置文件中部署时通过环境变量注入。Spring Security的配置类需要重写三个核心方法configure(HttpSecurity http)定义哪些接口需要认证哪些接口放行configure(AuthenticationManagerBuilder auth)配置认证管理器另外再定义一个PasswordEncoder的Bean返回BCryptPasswordEncoder实例。实际操作中我建议把注册、登录、获取验证码这几个接口放行其他所有接口都必须携带Token。前端页面通过Vue Router的导航守卫判断本地有没有Token没有就跳转到登录页。这样前后端双重拦截安全性才有保证。还要注意Session和JWT的选择问题。如果你做的是传统的服务端渲染项目用Session会更简单如果是前后端分离JWT是主流。JWT有一个天然的缺点是注销困难因为Token是无状态的你没法在服务端把某个Token作废。我的方案是在Redis里存储黑名单用户退出登录时把Token加入黑名单过期时间跟Token的过期时间一致。这样既享受了JWT的无状态特性又解决了注销问题。3.3 救援请求与地图定位模块用户提交救援请求是整个救援流程的起点也是我认为最能体现系统价值的地方。前端用一个地图组件让用户选点选好后把经纬度传到后端。后端要做的是逆地理编码把经纬度转换成文字地址描述这样即使地图组件加载不出来指挥中心也能通过文字了解大概位置。高德地图API使用的是Web服务接口我封装了一个工具类调用逆地理编码接口输入经纬度返回省市区和详细地址。这里要注意高德的Key需要在控制台申请并且配置域名白名单。开发阶段可以先用Web端Key上线前一定要换成安全等级更高的服务端Key并且把IP白名单配好不然Key泄露会被盗刷。存储坐标的时候我把经纬度设计成Decimal类型精度设为10,7因为一个经纬度如果精度不够会导致定位偏移几十甚至上百米。这个精度是我测过的10,7大概能精确到1米左右对于户外救援场景完全够了。看到有些项目用Double类型存经纬度其实也可以但Decimal在数据库层面做了精度约束数据质量更有保证。距离计算我封装了一个工具方法利用高德地图的坐标距离计算也可以直接在地图上画一个圆把附近的救援队列出来。这个功能相当于外卖平台的“附近商家”用户在野外按下求助按钮后系统自动按距离由近到远排列救援队伍队长看到的是等待受理的任务列表。这里的SQL查询用的还是传统的经纬度范围筛选适用于中小数据量。3.4 救援任务流转与WebSocket实时通知任务状态流转是整个系统最容易写乱的逻辑。我一开始用if-else判断各种状态组合维护起来极其痛苦。后来用了状态机的方式把每个状态的合法流转路径提前定义好代码里用一个Map存放状态变更时根据当前状态到Map里查合法的下一个状态不是合法路径就直接抛异常。举例说明救援任务的状态有“待受理”“已接单”“救援中”“已完成”“已关闭”五个。待受理可以转为已接单或者已关闭已接单只能转为救援中救援中只能转为已完成或者已关闭。就这简单几条规则用状态机一约束所有乱改状态的情况直接杜绝。任务状态变化以后需要实时通知相关人员。这里用了WebSocket后端在任务状态变更后通过WebSocket广播消息前端收到消息后重新拉取任务详情刷新页面。WebSocket配置起来不难定义一个Handler类继承TextWebSocketHandler重写afterConnectionEstablished和handleTextMessage方法。连接建立时把用户ID和WebSocket Session存到Map里发送消息时根据用户ID找到Session调用sendMessage方法推送。我遇到的一个坑是WebSocket和Spring Security的集成问题。WebSocket握手时不会自动走Spring Security的过滤器链所以我在握手拦截器里手动校验了Token。前端在连接WebSocket时把Token作为查询参数拼接在URL后面后端在拦截器里解析Token验证通过才允许建立连接。WebSocket方案对比轮询的优势很直观。如果不用WebSocket前端只能每隔几秒发一次请求问“任务状态变了吗”效率低还费流量。在野外的弱网环境下WebSocket一次连接、持续推送体验好很多。当然WebSocket也有缺点就是长连接占资源需要做好心跳检测和断线重连。我在前端做了断线重连机制心跳间隔30秒如果60秒没收到响应就主动断开重连。3.5 物资库存扣减与并发安全物资管理模块看起来简单实际上并发问题很隐蔽。比如一个救援任务需要消耗5个急救包操作员点击“出库”后系统先查库存判断够不够再扣减。如果两个操作员同时操作可能都查到还有5个库存然后都执行扣减最后库存变成-5数据就错了。解决这个问题我用的是乐观锁方案。在material表里面加了一个版本号字段version更新库存时带上条件WHERE material_id ? AND version ?执行UPDATE后通过返回的影响行数判断是否更新成功。如果影响行数为0说明版本号已经变了需要重新查询库存再尝试。这里还要注意更新库存和插入出入库记录必须在同一个事务里。为什么用乐观锁而不是悲观锁悲观锁是用SELECT ... FOR UPDATE把行锁住简单但容易造成死锁尤其在事务里还有其他数据库操作时。乐观锁在并发量不大的场景下完全够用而且实现简单、性能好。户外救援系统的并发量不大关键是逻辑要正确、代码要简洁所以我选了乐观锁。库存预警我用的是Spring的定时任务用Scheduled注解每天凌晨跑一次扫描库存低于阈值的物资自动给管理员发送邮件提醒。定时任务要注意线程池配置避免多个任务同时执行时互相阻塞。我的做法是单独配置一个ThreadPoolTaskScheduler核心线程数设为5队列容量用默认值。4. 常见问题与排查技巧实录4.1 SpringBoot启动报错锦集这个项目从头到尾遇到最多的问题就是启动失败。第一次跑的时候报错信息是Failed to configure a DataSource一看就是数据库连接没配上。后来发现是application.yml里面的url写法不标准少了?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai这一段。MySQL 8.0以上的驱动对时区要求很严格不指定serverTimezone就会报错这个坑很多人都会遇到。还有一个很经典的冲突问题处理了好久才发现是Maven依赖冲突。SpringBoot自带的Logback和项目里引入的log4j撞了控制台疯狂刷警告。最后的解决办法是在pom.xml里排除掉SpringBoot默认的日志依赖只保留log4j2。类似的冲突还出现在commons-logging上排查方法就是用mvn dependency:tree命令看依赖树一层一层捋。IDEA创建SpringBoot项目超时的问题我也遇到过原因是Spring Initializr的默认地址是https://start.spring.io在某些网络环境下访问很慢。解决办法是把服务地址换成阿里的镜像https://start.aliyun.com。另外Maven依赖下载慢的问题在settings.xml里面配置阿里云镜像就可以解决这个属于老生常谈但每次换新电脑都会踩一遍。4.2 数据库和缓存不一致怎么办项目里有些热点数据会用Redis做缓存比如用户信息、救援队伍列表。缓存最大的坑就是数据不一致。比如用户改了手机号数据库更新了但Redis里还是旧数据用户刷新页面看到还是旧手机号。我采用的方案是Cache Aside Pattern也就是先更新数据库再删除缓存。下次请求时发现缓存里没有就重新从数据库加载并回填缓存。这个方案简单有效唯一的风险是删除缓存失败导致缓存一直不更新。我的处理方式是在删除缓存失败时打印错误日志并通过定时任务做一致性校验。另一个方案是延迟双删更新数据库后先删除缓存等几百毫秒再删一次。这个方案能解决高并发下的极端情况但实现复杂度高而且几百毫秒的延迟不好定在并发量不大时性价比不高。我的建议是简单项目用Cache Aside就够别过度设计。Redis在项目里还承担了防止重复提交的功能。用户连续点几次“提交救助请求”会产生多条重复工单。我的解决办法是在Redis里存一个Key用订单ID加用户ID生成唯一Key设置过期时间为5秒只有第一次请求才能成功写入并继续执行后面的请求直接返回“请勿重复提交”。这个场景用Spring AOP实现会更优雅但用拦截器也能达到效果看个人偏好。4.3 坐标偏移和地图显示问题户外救援系统里地图定位是核心功能而坐标偏移是必须面对的问题。国内的互联网地图使用的坐标系是GCJ-02而GPS设备输出的坐标是WGS-84两者之间存在偏移。如果直接把GPS坐标放到高德地图上位置会偏移约几百米这在救援场景中是致命的。我的处理方式是在后端统一做一个坐标转换工具类。用户上报坐标之前前端通过高德地图JS API选点拿到的已经是GCJ-02坐标系这个坐标可以直接存储和展示。但如果有第三方设备上报WGS-84坐标后端需要调用高德地图的坐标转换API转成GCJ-02后再存库。这里有一个细节值得注意高德地图的坐标转换API每次最多转换40个坐标点如果需要批量转换要分批调用。另外坐标转换是精度敏感的运算建议用double类型不要用float否则小数点后精度会丢失导致地图匹配不上。4.4 常见问题速查表问题现象可能原因解决方案启动报Failed to configure a DataSource数据库连接配置缺失或时区问题检查application.yml配置好URL、用户名密码加上serverTimezoneAsia/Shanghai查询结果全是nullMyBatis未开启驼峰映射配置map-underscore-to-camel-case为trueJWT Token每次请求都被拦截拦截器未放行OPTIONS请求在拦截器里对OPTIONS请求直接放行否则跨域预检会失败WebSocket连接后无法推送消息ngrokToken校验失败或Session管理出错检查握手拦截器确认WebSocket握手时校验Token的方式并发扣库存出现负数没有做并发控制用乐观锁在UPDATE语句里加version条件地图坐标偏移几百米WGS-84和GCJ-02坐标系混用统一使用GCJ-02必要时用API做坐标转换Redis缓存数据和数据库不一致缓存更新策略不对先更新数据库再删除缓存必要时做延迟双删依赖冲突导致的ClassNotFoundMaven依赖管理混乱用mvn dependency:tree排查排除冲突依赖4.5 调试与排障的独门技巧整个项目最耗时间的其实是调试环节我总结几个特别实用的习惯。第一个是接口测试不要光靠Postman手动点把请求封存成Postman Collection可以一键跑全量接口测试。项目交付时把Collection导出发给对方对方也能快速了解接口结构。第二个是SQL日志必须开。MyBatis默认不打印SQL我习惯在application.yml里配置mybatis.configuration.log-impl: org.apache.ibatis.logging.stdout.StdOutImpl这样每次执行的SQL、参数、返回结果数都会打印到控制台。排查问题时先看SQL是否按预期执行再看参数是否传对效率翻倍。第三个是全局异常处理。我写了一个RestControllerAdvice注解的全局异常处理器捕获所有运行时异常统一返回JSON格式的错误信息。这样做的好处是前端拿到错误信息后能直接展示不会出现白屏或者500错误裸奔的情况。全局异常处理器里我还汇总了自定义的业务异常码比如1001表示参数校验失败1002表示无权限1003表示资源不存在排查时看一眼异常码就能定位问题方向。5. 项目部署与后续扩展方向5.1 打包部署的完整流程项目的部署我是按传统单体应用来做的。项目开发完成后在IDEA里执行mvn clean package -DskipTests生成一个可执行的jar包。这个jar包包含了SpringBoot内嵌的Tomcat所以不需要额外安装Tomcat服务器直接用java -jar命令就能启动。服务器环境我建议用Linux安装好JDK 1.8和MySQL、Redis然后把jar包上传上去。启动命令要加一些JVM参数比如-Xms512m -Xmx1024m限制内存占用。日志输出到指定文件方便排障。如果是正式生产环境还要配置systemd服务设置开机自启动。nginx做反向代理把80端口的请求转发到SpringBoot的8080端口。静态资源直接由nginx托管比如前端打包出来的dist目录放到nginx的html目录接口请求通过/api前缀转发到后端这样前后端共用一个域名避免跨域问题。还有一个建议是启动脚本里要加上对MySQL和Redis的依赖检查。等数据库和缓存都启动成功了再启Java应用不然会一直报错看起来就像启动失败。这种细节在写部署文档时要说清楚不然接手的人很痛苦。5.2 这套系统的扩展空间户外救援系统的业务场景其实可以延伸出很多东西我这里挑几个可能的方向聊一下。一个是接入物联网设备。现在很多户外装备有智能定位功能比如支持北斗短报文的卫星终端、带有SOS按键的智能手表。如果这些设备能通过MQTT协议把位置信息实时上报到救援系统指挥中心就能在大屏上看到所有队员和求助者的实时位置调度效率会提升很多。另一个是做救援资源的热力图分析。系统积累了一两年的救援数据后可以分析出哪些区域是事故高发区、哪些时段是救援高峰期。有了这些数据救援队可以提前在这些区域部署前置物资或者在高峰期增加值班人手从被动响应变成主动布防。还有AI辅助分诊的方向。用户填写求助信息时描述伤势情况后端可以接入文本分类模型自动判断伤情严重程度优先处理危重伤员的求助请求。这个方向现在有很多现成的算法模型可以做比如基于BERT的文本分类准确率在80%以上落地难度不大。不过这些都是后话了作为一个单体应用先把核心流程跑通、数据积累起来后面的迭代才有基础。6. 一些开发建议与个人体会整套系统从零开始写前后大概花了两个月时间最大的体会是业务系统开发的复杂度不在技术栈而在对业务流程的理解深度。救援系统的核心是“怎么让求助信息精准、高效地流转到合适的人手里”在这个基础上再去谈技术选型才是有意义的。技术层面我有几个建议送给正在做类似项目的朋友。第一项目骨架一定要搭好先用Swagger把所有接口文档写清楚再开始写业务代码不然前后端联调时会很痛苦。第二事务控制要谨慎每个Service方法都考虑一下数据一致性该加Transactional的地方一定要加但也不要滥用避免长事务锁定过多资源。第三日志一定要打全特别是核心链路比如任务状态变更、物资扣减、登录操作都要记录操作人和操作时间方便出问题时回溯。还有一个很现实的建议这个类型的管理系统业务逻辑并不难难的是数据的边界划分和权限控制。如果表设计的时候没有把角色、组织、区域这些维度考虑进去后面加需求的时候会非常痛苦。我在这套系统里一开始没预留区域字段后面要加“按区域统计救援数据”的功能时只能临时加字段补数据费了不少功夫。所以做表设计时尽可能多想两层把维度拆细一些宁可前期多做一点也别后期返工。最后再说一个细节。用户提交的救援请求可能涉及隐私比如身体伤势、具体位置这些数据要做脱敏处理。管理员后台查看列表时手机号中间四位打码显示队员的个人信息不能全部展示给普通用户。虽然这个项目本质上是一个救援工具但从产品设计的角度信任和安全永远要放在第一位。这套系统目前已经跑起来了从救援请求上报到队伍指派、物资消耗、复盘统计的完整闭环都通了。后续我打算继续完善移动端适配把高德地图的轨迹回放功能集成进去让每次救援行动都能自动生成轨迹报告。如果你也在做类似的项目欢迎一起交流。