用 Java 接微信支付与公众号后端（WxJava）

微信生态的后端接口散在几套互不相通的体系里。公众号、小程序、微信支付、企业微信、开放平台，各自的鉴权方式、签名规则、证书管理都不一样，文档还会随官方调整而变。Java 项目从零手写这些调用，光是把 access_token 的缓存、刷新与多实例同步做对，就要花掉不少时间。

WxJava 是微信后端开发的 Java SDK，用 Maven 引入，输入微信的 appId、密钥和接口参数，输出 AccessToken、用户信息、支付下单结果等接口返回数据。

仓库地址在 https://github.com/binarywang/WxJava ，主要语言 Java，语言占比统计为 Java 100.0%，许可证 Apache License 2.0。抓取时项目有 33139 Star、9052 Fork、1336 Watcher，开放 Issue 9 个；创建于 2016-01-06，默认分支 develop，最近一次提交在 2026-09-26。

它的组织方式是按业务模块拆包，一个模块对应一组 maven artifact。公众号、小程序、支付、企业微信、开放平台各有独立仓库目录，也有 weixin-java-common 这样的公共层，以及 spring-boot-starters、solon-plugins 这类框架适配层。用哪个模块，取决于你要对接微信的哪一块能力。

这件事以前怎么做

不借助这类 SDK，做微信后端通常是对着官方文档手写 HTTP 请求，再自己维护一套配置与缓存。

access_token 有有效期，且与账号绑定，多实例部署时要考虑加锁和共享存储。微信支付要管证书序列号、签名验证，还要跟着平台证书模式到公钥模式的变更做调整。消息推送要处理加解密，以及 XML 与 JSON 之间的格式转换。这些环节每一处都不复杂，麻烦的是持续跟进。

项目 Issue 里的记录能反映这类问题：有用户在 Redis 存储方案下遇到可能循环获取 access_token 的情况，有用户在高并发发送公众号模板通知时遇到线程阻塞，也有人反馈小程序请求偶尔抛出 GSON 的 JSON 解析异常。这些问题在自研封装里同样容易出现，区别只在谁来修。

另一条路是找现成的封装，但微信模块多，往往要凑几个不同来源的库：公众号用一套，支付用另一套，配置方式、异常类型、日志风格都不统一，排查线上问题时要在几套抽象之间来回切。

换成它之后

1. 先按业务场景确定模块。公众号对应 weixin-java-mp，小程序对应 weixin-java-miniapp，微信支付对应 weixin-java-pay，企业微信对应 weixin-java-cp，微信开放平台（第三方平台）对应 weixin-java-open，视频号与微信小店对应 weixin-java-channel。
2. 引入依赖。同时使用多个模块时，推荐用 BOM 统一管理版本，wx-java-bom 从 4.8.3.B 版本开始提供：

   <properties>
     <wx-java.version>4.8.3.B</wx-java.version>
   </properties>
   
   <dependencyManagement>
     <dependencies>
       <dependency>
         <groupId>com.github.binarywang</groupId>
         <artifactId>wx-java-bom</artifactId>
         <version>${wx-java.version}</version>
         <type>pom</type>
         <scope>import</scope>
       </dependency>
     </dependencies>
   </dependencyManagement>

   之后引入具体模块不必再写版本号，例如 weixin-java-mp 与 weixin-java-pay 直接声明 artifactId 即可。只用一个模块时，也可以按 com.github.binarywang + 模块名 + 版本号（当前最新正式版为 4.8.0）单独引用。
3. 初始化 Service 并填入配置。以公众号为例：

   WxMpDefaultConfigImpl config = new WxMpDefaultConfigImpl();
   config.setAppId("your-app-id");
   config.setSecret("your-secret");
   
   WxMpService wxMpService = new WxMpServiceImpl();
   wxMpService.setWxMpConfigStorage(config);
   
   String accessToken = wxMpService.getAccessToken();
   System.out.println(accessToken);

   小程序模块的初始化方式相近，用 WxMaDefaultConfigImpl、WxMaService 完成配置后即可调用 code2Session 这类接口。
4. 后续调用都走同一个 Service 实例的方法，参数与返回值是项目里定义好的对象，不再自己拼 URL、签名字符串和解析响应体。

Java 微信 SDK 与同类项目对照

如果技术栈不是 Java，WxJava 帮不上忙，应该去看对应语言的 SDK。即便在 Java 项目里，只对接公众号一个模块、且已有内部封装的话，引入这套多模块方案要额外承担选模块、管版本的启动成本，BOM 也是从 4.8.3.B 才提供；这种场景下像 weixin4j 这类覆盖面更窄的方案反而更轻。

怎么接进现有流程

输入来自微信后台：公众号或小程序的 appId 与 secret，支付的商户号与证书文件。这些值可以写在代码里 set 进 ConfigImpl，也可以通过 spring-boot-starters 落到 Spring Boot 的配置文件中，让框架负责装配。用 Solon 的项目有 solon-plugins 对应。

access_token 存在哪里由 configStorage 决定。内存实现适合单实例，多实例部署一般换成 Redis 实现，Issue 里就有关于 WxMpInRedisConfigStorage 在多实例下锁行为的讨论。仓库没有说明需要额外挂定时任务来刷新凭据，这部分由配置存储层承担。

输出是 Service 方法的返回值，业务代码直接拿去用。需要注意的是消息回调：SDK 负责解析和加解密，但接收微信推送的 HTTP 接口要你自己暴露，仓库明确说明本项目未提供 Web 实现。

如果团队在用支持 SKILL 约定的 AI 编程智能体，仓库的 skills 目录提供了模块选择、接入指南、故障排查、接口贡献、升级迁移五个 SKILL，每个以 SKILL.md 为入口。以 Codex 为例：

git clone https://github.com/binarywang/WxJava.git
mkdir -p "${CODEX_HOME:-$HOME/.codex}/skills"
cp -R WxJava/skills/wxjava-* "${CODEX_HOME:-$HOME/.codex}/skills/"

重启或新建会话后，就可以用自然语言要求智能体按 wxjava-integration-guide 之类的能力来辅助接入。

它替代不了的部分

它是一个 SDK 开发工具包，README 里写明未提供 Web 实现，也没有自带管理后台、运营页面或数据库结构。你要的是一个能直接登录、配置素材、看数据报表的成品系统，它给不了。

移动端的微信登录与分享能力，仍然要集成微信官方提供的 iOS/Android 客户端 SDK。服务端这一侧可以用 weixin-java-open 处理网页授权的 OAuth 流程，但客户端那部分它不覆盖。

JDK 版本上有硬门槛。当前版本要求最低 JDK 8；还在用 JDK 7 的项目只能使用 3.8.0 及以前的版本，JDK 6 则要换成作者维护的另一个项目。另外源码里用到了 lombok，直接读源码前要先了解它，否则编译期生成的方法会让人找不到来源。

这套 SDK 会实际调用微信接口、处理用户数据与支付信息，只能用在自有资产或已经获得授权的公众号、小程序、商户号上。拿别人的 AppID 做测试、绕开平台鉴权批量抓取用户数据，可能触犯法律，账号也会被平台封停。

值不值得换

后端是 Java，且要接的微信模块不止一个，现在就可以换。公众号加支付、小程序加企业微信这类组合，用一套配置方式管起来，比维护几套来源不同的封装省事。

项目还在持续跟进官方接口变更的，也适合换。v4.8.0 正式版一次更新包含超过 70 项改进，覆盖支付、小程序、企业微信等多个模块，这类维护量不适合由业务团队自己扛。

已经在用 Spring Boot 或 Solon 的团队，可以直接用对应的 starter 与插件，配置写在配置文件里，减少手工初始化代码。

技术栈不是 Java 的团队不要换，去选对应语言的 SDK 更直接；只需要移动端登录分享这类客户端能力的项目，也不该指望服务端 SDK 来解决。

焚评：这个项目的量化评分

本项目的选题来自 焚.com（一个按公开公式给 GitHub 项目打分的站）。焚评当前总分 9.3 分（满分 10）。下表是各维度的得分：

评分口径、权重与计算方式见焚.com 的评分方法页；数据随 GitHub 指标刷新，具体数值以焚.com 当前页面为准。本文正文为诀.com 独立撰写，评分数据由焚.com 授权引用。