一、概要我从 1.2 环境安装阶段开始对照项目配置确认依赖组件启动核心服务联调前后端然后一路排到小程序登录报错最终把问题锁定并修掉。写入范围jzo2o 项目环境准备、服务启动、ES 搜索环境与代码理解、小程序登录与修复二、ES环境安装阶段搜索功能ES肯定是第一选择因为单纯的数据库查询从能力和性能上都无法满足需求如果要从ES中进行数据的检索就必须保证数据库中的参与搜索的这部分数据实时同步到ES中此功能的实现大体有下面这些方案同步双写在程序在中同时向MySQL和ES写数据这种方式实现简单但是代码耦合异步消息程序在向MySQL写入数据之后向MQ中投递消息ES相关程序监听MQ获取数据写入ESCanal监听使用Canal监听MySQL的binlog当发现写入操作后立即读取到新写入的内容并同步到ESCanal的工作原理Canal伪装自己为MySQL的从节点向MySQL主节点发送dump协议MySQL主节点一旦收到dump请求开始推送binlog给canalCanal会接收并解析这些变更事件并解析binlog并发送到其它服务器比如es、redis等等环境目标保证从MySQL-Canal-MQ-ES这套环境是没问题的保证serve、serve_item、serve_type表数据变化的时候serve_sync表中的数据要同步变化保证小程序端用户可以从ES中搜索数据组件我确认它存在的依据在本项目里的作用这次记录中的状态CentOS 虚拟机用户明确说明“虚拟机已打开”并补充系统为 CentOS承载后端服务和相关中间件运行环境已确认存在NacosSpring Boot bootstrap 与 live 配置中心读取结果服务注册、配置下发已确认配置入口Redisshared-redis / shared-redis-cluster 配置缓存与会话相关能力已确认依赖MySQLshared-mysql 配置与各服务 db-name核心业务数据存储已确认依赖Elasticsearchshared-es 配置与搜索代码片段服务搜索能力、聚合索引查询已确认依赖RabbitMQshared-rabbitmq 配置消息投递与异步联动已确认依赖微信开发者工具小程序前端实际运行与报错截图运行 jzo2o-consumer 并完成登录联调已参与联调这一步最重要的价值是让我在真正启动项目之前就已经知道自己不是在面对一个单体应用而是在面对一个由网关、用户中心、公共能力、基础数据和多种中间件共同协作的微服务项目。如果这里没有先把依赖图谱理清后面一旦联调报错我就很容易在错误的层级里反复打转。三、“端口-职责-请求路径”项目跑起来之后最先需要解决的不是“看见四个服务很开心”而是必须知道这四个服务分别管什么。否则一旦请求报错我连该看哪个模块、哪个日志都没有方向。图 1 这次联调阶段实际启动的四个核心 Spring Boot 服务服务端口主要职责和这次问题的关系GatewayApplication11500统一入口、路由转发、Token 过滤、白名单放行前端请求先经过它CustomerApplication11502登录、普通用户、地址簿、服务人员、评价等用户中心能力小程序登录核心业务在这里PublicsApplication11503微信、短信、地图、存储等公共能力微信 code 换 openid 在这里FoundationsApplication11509区域、服务类型、服务项等基础数据首页和搜索相关基础数据依赖它另外还有一个很关键但非常容易忽略的点网关里明明白白配置了多个路由规则例如 /customer/** 会转发到 jzo2o-customer/publics/** 会转发到 jzo2o-publics而 /customer/open/login/common/user 这条登录接口又恰好处在网关白名单里。换句话说登录请求本身不是先被 token 拦掉而是确实已经往后走到了业务服务。1. /customer/** - jzo2o-customer2. /publics/** - jzo2o-publics3. /customer/open/login/common/user 位于白名单中四、ES 先确认依赖再理解查询链路因为当前章节本身就是“搜索下单”所以我没有把 ES 当成一个孤立的中间件看待而是把它当成业务功能的一部分去理解。从配置上看基础服务已经显式依赖 ES 共享配置从代码片段上看搜索逻辑会围绕索引 serve_aggregation 构造布尔查询再把命中结果转换成前端需要的简化 DTO。我当时重点抓了三个参数cityCode、keyword、serveTypeId。它们分别对应城市范围、关键词匹配和服务类型过滤。也就是说这段搜索代码本质上不是“随便查一下”而是在做一个有约束条件、有排序、有结果映射的正式业务搜索接口。图 2 ES 搜索流程图从参数进入到 DTO 列表返回现象原因处理看配置如果 ES 地址、认证、共享配置没对上代码再正确也跑不通先确认 shared-es 是否存在再谈查询逻辑看 SearchRequest索引名直接决定查的是哪类数据确认索引为 serve_aggregation避免查错库看结果映射业务接口最后要返回 DTO不是原始 hits把 ES 返回值和前端展示结果串起来理解RestHighLevelClient 已经在新版本生态里被标记为弃用但对于现有 ES 7.x 项目来说它依然是可以继续工作的。五、小程序登录报错环境和服务都就位之后我开始打开前端微信小程序做联调。结果登录按钮一点页面直接弹出了 invalid code 的提示。这个报错非常短但也非常关键因为它意味着问题大概率不在普通业务逻辑而是在微信登录链路本身。图 3 小程序登录出错登录报错第一轮判断现象原因处理前端能拉起页面点击登录即报 invalid code前端页面本身可运行问题更可能出在 code 换取 openid 这一步把注意力从页面样式转到登录链路不是 401也不是网关无权限网关白名单已经放行登录接口继续往 customer 和 publics 服务内部追提示文案来自微信能力链路wx.login 生成的 code 最终要交给微信官方接口校验重点核对 appid、secret、code 对应关系六、沿着代码往后追把登录链路完整串起来为了避免“感觉上像是微信问题”这种模糊判断我直接回到代码把小程序登录从前端一路追到了后端。前端 pages/login/index.vue 里会先执行 wx.login 拿到 res.code再把 code、头像、昵称发到 /customer/open/login/common/user。而在 customer 服务内部loginForCommonUser() 并不会直接生成 token它会先调用 wechatApi.getOpenId(code)。这个 Feign 接口再转到 publics 服务的 /inner/wechat/getOpenId最后由 WechatServiceImpl 调用微信官方的 jscode2session 接口去换取 openid。图 4 微信小程序登录调用链与问题定位流程图wx.login 生成的 code必须和后端拿去换 openid 的 appid/secret 属于同一个小程序。只要这三者不是一套微信就会直接返回 invalid code。七、第一次修复的思路统一到了后端那套 AppID(❌)当时我先从后端入手查到了 jzo2o-publics 当前正在使用的一套微信配置。于是我的第一反应很自然既然后端已经有一套 appid 和 secret那我就把前端也统一到这一套。从技术直觉上看这一步并没有错因为 code 与后端配置一致确实是解决 invalid code 的必要条件。但真正改完之后微信开发者工具又弹出了另一个非常扎眼的提示当前登录账号不是该小程序的开发者。也就是说技术上我把链路对齐了权限上却又撞到了墙。图 5 第一次统一 AppID 后出现的提示当前账号无该小程序权限现象原因处理我先统一到了后端那套 appid这是最直接、最符合技术逻辑的尝试保留这段过程能真实反映排障不是一步到位微信开发者工具提示无开发权限说明“技术一致”不等于“当前账号可运行”排障视角从代码层扩展到账号权限层最终改走方案 B要统一到“当前开发者账号有权限”的那套小程序把问题从“能不能调用”进一步缩小到“当前谁能调用”八、问题根源前后端用了不止一套小程序身份继续往下查之后问题才真正清晰起来。前端工程里至少出现了三处和小程序运行有关的 appidmanifest.json 一套project.config.json 一套编译产物里的 project.config.json 还有一套与此同时后端 Nacos 中 jzo2o-publics 的微信配置又是另一套。到这一步我对 invalid code 的理解就完全落地了是“微信登录临时 code 的归属小程序”和“后端用于换 openid 的小程序配置”从根上就没统一。这次排查到的关键配置入口1. manifest.json - mp-weixin.appid2. project.config.json - 微信开发者工具当前工程 appid3. unpackage/dist/dev/mp-weixin/project.config.json - 当前编译产物 appid4. Nacos: jzo2o-publics.yaml - tencent.wechat.app-id / secret九、最终修复统一到当前有权限的AppID验证 AppSecret既然第一次失败是因为我把前端对齐到了“当前账号无权限”的小程序那么最终修复思路也就明确了反过来把前端和后端全部统一到“当前开发者账号有权限”的那一套小程序。我先把前端 manifest.json、project.config.json 和编译产物里的 project.config.json 统一到了同一个 appid再去确认这套小程序对应的 AppSecret 是否真的可用。这个验证不能靠猜所以我额外做了一步非常关键的确认直接调用微信官方 token 接口测试这组 appid AppSecret。结果接口成功返回 access_token说明这套配置是真实可用的。随后我把 Nacos 中 jzo2o-publics.yaml 的 tencent.wechat.app-id 和 secret 一并切到了这套配置再提醒自己不要忘记重启 jzo2o-publics 服务让运行中的进程真正加载新值。现象原因处理前端三处 appid 统一避免源码、开发者工具、编译产物各跑各的保证 wx.login 生成的 code 归属明确验证 AppSecret只改 appid 不改 secret问题不会消失通过微信官方接口拿到 access_token确认凭据有效更新 Nacos 并重启 publics运行中的服务不会自动变成新配置让 jzo2o-publics 用上新的微信身份信息十一、小总结1. 确认请求有没有走到网关白名单 / 路由层2. 涉及第三方平台时记得核对“前端身份”和“后端身份”是否一致3. Nacos 配置改完后运行中服务不一定生效需要重启对应服务4. 同一个前端工程里注意源码配置、开发者工具配置、编译产物配置是否一致5. 遇到搜索功能时看查询语句、索引、过滤条件、排序和 DTO 映射