简介微信小程序支付后端示例基于Spring Boot与Java开发面向需要接入微信支付的服务器端开发者项目实现了小程序支付的核心接口包括统一下单、支付结果查询并通过集成微信支付SDK完成与微信服务器的通信。资源压缩包共32个文件其中22个Java源文件构成主要逻辑另有Maven配置文件、yml环境配置、HTTPS密钥库文件以及项目说明文档和示意图片整个包仅124KB轻量紧凑适合快速导入查看。示例重点展示了Spring Boot接口设计思路、支付SDK的调用方式还单独说明了server.keystore的HTTPS配置流程帮助开发者满足微信支付对传输安全的强制要求。对于刚接触微信支付或想参考后端分层写法的初中级工程师这份demo提供了从工程结构到实际代码的完整参照包括下单接口如何暴露、支付回调如何处理等细节。目前已有3151人浏览学习可作为快速上手的实用模板。1. 微信小程序支付 demo 后端最被低估的是它的链路长度微信小程序支付 demo 后端很多人第一反应是“不就是调个接口吗”。实际上手才发现一个最小可跑的 springboot 支付工程横跨了小程序登录态、统一下单、二次签名、回调验签、订单幂等更新五段链路任何一段理解偏了前端 wx.requestPayment 就是弹不起来或者钱扣了订单还是待支付。这个 demo 的价值不在“能支付”而在让你把这三件事变成肌肉记忆后端负责拿着商户私钥签名下单、把 5 个参数交给前端调起支付、再靠异步回调确认最终结果。适合谁刚接触微信支付的后端同学、做毕设需要完整支付闭环的学生以及想把支付从“会调用”升级到“能排错”的初级工程师。本文只聊 JSAPI 支付不碰商家转账那套接口字段别混着抄。2. 搭建 springboot 支付工程目录结构、依赖与商户三件套配置2.1 为什么统一支付链路要放在后端而不是小程序里直接下单微信支付的约束很简单商户私钥不能出现在小程序前端代码里谁都能解包的小程序一旦存了私钥等于把资金操作权交给了别人。所以下单请求必须由后端发起后端负责签名和验签小程序端只负责把用户带到微信的收银台。选择一个 springboot 工程来做这层后端理由也很实际。一是工作室或公司的后端技术栈大多是 Java支付模块要接入现有的用户体系、订单表、对账任务springboot 能无缝嵌进去二是官方提供了 Java 版 SDK签名、平台证书自动更新这些容易出错的部分有人替你兜底三是这个 demo 采用前后端分离的写法springboot 只输出 JSON 接口前面接原生小程序、uni-app 或者 Vue 外壳都一样接口不受前端框架绑架。一个常见的错误认知是“下单之后把 prepay_id 直接返回给前端就行”。prepay_id 只是微信侧生成的预支付单标识小程序端要拉起收银台还需要把它包装成 timeStamp、nonceStr、package、signType、paySign 这五个参数paySign 要用商户私钥对特定格式的字符串做签名。这套“统一下单 二次签名”的配合就是后端存在的核心意义。2.2 工程目录与依赖一个 controller、两个 service、一张订单表支付 demo 不需要复杂的微服务结构我一般这样组织工程wx-pay-demo ├── pom.xml ├── src/main/java/com/example/wxpay │ ├── WxPayApplication.java │ ├── config │ │ ├── WxPayProperties.java // 配置绑定 │ │ └── WxPayConfig.java // SDK Config 初始化 │ ├── controller │ │ └── PayController.java // 下单入口 回调入口 │ ├── service │ │ ├── WxOrderService.java // 统一下单、查单 │ │ └── WxNotifyService.java // 回调验签、解密、改单 │ ├── entity │ │ └── Order.java // order_no, amount, status │ └── mapper │ └── OrderMapper.java └── src/main/resources ├── application.yml └── cert/apiclient_key.pem // 商户 API 私钥别提交到 gitpom.xml 里最要紧的是 spring-boot-starter-web 和官方支付 SDK。注意 SDK 版本不要抄老博客里的旧坐标以 maven 仓库当前 release 为准示例里用版本占位符parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.github.wechatpay-apiv3/groupId artifactIdwechatpay-java/artifactId version${wechatpay.version}/version /dependency /dependencies这里刻意把 springboot 放在 2.7 而不是 3.x后面避坑章节会解释为什么。依赖引入后先跑一次空工程确认 SDK 的 jar 能下载下来再往下走。2.3 商户三件套APIv3 密钥、商户私钥、证书序列号微信支付 V3 体系里有三把“钥匙”各管一段很多 demo 跑不通都是在这里混淆。第一把是 APIv3 密钥32 字节随机串在商户平台里自己设置的它用于解密微信回调过来的报文不参与请求签名。第二把是商户 API 证书私钥最常用的 apiclient_key.pem 文件所有后端发起下单、查单请求的签名都用它是一把“主动签名”的钥匙。第三把是平台证书用来验证微信响应和回调的签名官方 SDK 的自动更新证书模式可以不手动下载但原理必须清楚。配置集中放在 application.ymlwx: pay: app-id: wx1234567890abcdef # 小程序的 AppID mch-id: 1234567890 # 商户号 api-v3-key: 32位随机字符串 # 商户平台设置的 APIv3 密钥 private-key-path: classpath:/cert/apiclient_key.pem private-key-serial-no: 商户API证书序列号 notify-url: https://api.example.com/wx/pay/notifyprivate-key-serial-no 经常被误解它不是文件的名称而是商户平台“API 安全”页里展示的一串十六进制证书序列号。用错了序列号下单请求会直接返回 401 签名错误。接着写配置绑定类Component ConfigurationProperties(prefix wx.pay) public class WxPayProperties { private String appId; private String mchId; private String apiV3Key; private String privateKeyPath; private String privateKeySerialNo; private String notifyUrl; // getter / setter 省略 }Configuration public class WxPayConfig { Bean public RSAAutoCertificateConfig wxPayConfig(WxPayProperties prop) throws Exception { return new RSAAutoCertificateConfig.Builder() .merchantId(prop.getMchId()) .privateKeyFromPath(prop.getPrivateKeyPath()) .merchantSerialNumber(prop.getPrivateKeySerialNo()) .apiV3Key(prop.getApiV3Key()) .build(); } }RSAAutoCertificateConfig 这个类会在首次调用时自动下载微信支付平台证书并在证书快过期时自动更新省去了手动换证书的运维操作。如果你的网络环境访问微信平台域名不通这一步会抛异常可以先在本地用浏览器确认能访问微信支付相关域名。2.4 配置完怎么自检先签名后下单不急着写业务配置完成后不要直接冲进业务代码花两分钟做验证。单元测试里拿配置类签一个明文再验能通说明私钥、序列号没问题SpringBootTest class WxPayConfigTest { Test void testSignAndVerify() throws Exception { RSAAutoCertificateConfig config ...; // 从容器注入 String message hello wxpay; String sign config.createSigner().sign(message); boolean ok config.createVerifier().verify(message, sign); System.out.println(sign verify result: ok); } }签名能通过接下来用 Postman 之类工具直接调一次下单接口观察 HTTP 状态码。返回 200 说明配置链路全通返回 401 排查序列号或私钥内容返回 400 排查参数格式。把这一步作为惯例保留后面每换一个环境本地、测试服务器、生产都先跑签名自检能省掉大量玄学排错时间。3. 小程序 wx.requestPayment 怎么拉起统一下单、二次签名与 5 个参数3.1 下单前先解决 openid登录接口和获取手机号不是一回事小程序端 wx.requestPayment 必须携带支付者 openid这个 openid 来自微信登录流程。很多新手把“获取手机号”当成“获取用户身份”其实两个接口返回的东西完全不同。手机号是用户主动授权才能拿到的敏感信息而 openid 是用户在当前小程序下的唯一标识通过 wx.login 拿到的 code 换 session 接口获得。后端要拿到 openid需要在小程序登录时把 code 传过来后端用 code 调微信的登录接口PostMapping(/wx/login) public MapString, Object login(RequestBody MapString, String body) { String code body.get(code); String url https://api.weixin.qq.com/sns/jscode2session?appid appId secret secret js_code code grant_typeauthorization_code; // 调用 RestTemplate解析返回的 openid 和 session_key return result; }注意 secret 是小程序密钥和商户私钥一样属于后端机密绝不能出现在小程序代码里。这个接口只解决“知道你是谁”不涉及支付签名做 demo 时单独拎出来跑通后面下单直接复用 openid 即可。3.2 统一下单让微信侧返回 prepay_idopenid 就绪后进入核心下单流程。微信支付 V3 的 JSAPI 下单接口路径是 /v3/pay/transactions/jsapi官方 Java SDK 把请求签名和响应验签都封装好了业务代码关注参数即可Service public class WxOrderService { private final RSAAutoCertificateConfig wxPayConfig; private final WxPayProperties wxPayProperties; public PrepayWithRequestPaymentResponse createJsapiPay( String openid, String outTradeNo, long totalFee, String description) throws Exception { JSAPIService service new JSAPIService.Builder().config(wxPayConfig).build(); PrepayRequest request new PrepayRequest(); request.setAppid(wxPayProperties.getAppId()); request.setMchid(wxPayProperties.getMchId()); request.setDescription(description); request.setOutTradeNo(outTradeNo); request.setNotifyUrl(wxPayProperties.getNotifyUrl()); Amount amount new Amount(); amount.setTotal(totalFee); request.setAmount(amount); Payer payer new Payer(); payer.setOpenid(openid); request.setPayer(payer); return service.prepayWithRequestPayment(request); } }代码里的五个字段逐一说明。description 是商品描述长度限制 127 个字符建议格式“商品名-简单规格”别塞完整订单 JSON。outTradeNo 是商户系统内部的订单号6 到 32 个字符同一个商户号下不能重复重复会让下单接口直接报错所以“先生成订单号并落库、再调下单”是比较稳妥的写法。totalFee 的单位是分不是元传 100 表示一块钱用 Long 类型避免浮点误差。notifyUrl 是微信异步通知的地址必须公网可访问且要能处理 POST 请求。payer 里的 openid 必须与当前小程序的 appid 匹配用另一个小程序的 openid 来下单微信直接拒绝。3.3 二次签名与 5 个参数新手翻车最多的地方prepayWithRequestPayment 这个方法名字直白它帮你完成了“统一下单拿到 prepay_id再按 JSAPI 调起支付的规则做二次签名”返回的响应体已经包含了前端需要的全部字段。看这个响应的结构就理解了“为什么不能直接把 prepay_id 抛给前端”{ prepay_id: wx251234567890abcdef, timeStamp: 1712345678, nonceStr: d4e5f6a7b8c9, package: prepay_idwx251234567890abcdef, signType: RSA, paySign: Base64编码的签名串 }timeStamp 是秒级时间戳的字符串形式前端要求 String不是 Long传成数字类型会直接导致调起失败。nonceStr 是随机字符串每次下单都不同。package 必须带 prepay_id 前缀只传裸的 prepay_id 也是常见翻车点。paySign 的签名串格式是 appId、timeStamp、nonceStr、package 四个值用换行分隔然后用商户私钥做 SHA256withRSA 签名。如果把 SDK 换成手写实现二次签名的核心逻辑是这段private String buildPaySign(String appId, String timeStamp, String nonceStr, String packageStr, PrivateKey privateKey) throws Exception { String message appId \n timeStamp \n nonceStr \n packageStr \n; Signature sign Signature.getInstance(SHA256withRSA); sign.initSign(privateKey); sign.update(message.getBytes(StandardCharsets.UTF_8)); return Base64.getEncoder().encodeToString(sign.sign()); }注意这里的 message 不作为 HTTP 请求体发送它只是本地拼出来的待签名串。初学者容易把它和“下单请求的 HTTP 签名”搞混。下单请求签名用的是 HTTP 方法、请求路径、时间戳、随机串、请求体摘要拼出来的 Authorization 头二次签名用的是 appId 等四个支付参数。两者都走 SHA256withRSA但内容不同签名结果不能互相替换。有同学会问官方 SDK 都封装好了为什么还要自己写一遍签名。答案是排错。哪天 paySign 校验不过你能快速判断是拼接格式错了还是私钥加载错了不至于对着黑匣子干瞪眼。3.4 前端调起支付只透传后端返回的 5 个参数后端返回上面的 JSON 后小程序端调用 wx.requestPayment 只需要原样透传const res await request.post(/wx/pay/create, { openid: this.openid, orderNo: orderNo, totalFee: 1 }); wx.requestPayment({ timeStamp: res.data.timeStamp, nonceStr: res.data.nonceStr, package: res.data.package, signType: res.data.signType, paySign: res.data.paySign, success: () { /* 提示支付成功但不要在这里改订单状态 */ }, fail: (err) { /* 用户取消或支付失败 */ } });前端绝对不要在 success 回调里直接调后端“标记订单已支付”因为微信官方明确提示requestPayment 的成功状态只代表调起收银台成功不能作为支付结果。支付的最终确认必须依赖微信异步通知到后端。这一点在下一章展开也是很多人做 demo 时“支付成功但订单没变”的根源。4. 支付回调验签、解密与订单状态更新的标准写法4.1 为什么支付结果必须以后端回调为准小程序端的 wx.requestPayment 成功回调在两种常见场景下会失真用户支付完成后停留在收银台页面手动关闭前端收不到 success或者用户支付成功但手机断网回调根本没到。唯一可靠的事实来源是微信服务器在支付成功后用异步 POST 通知后端 notify_url。这个接口的设计原则是能快速响应、能验明正身、能防重复消费。微信要求回调接收方在 5 秒内给响应否则它会按秒级递增的策略重试多次。这就是为什么回调 Controller 里不能串行执行耗时操作比如同步发短信、调其他业务接口这些动作应该放到支付状态落库之后异步处理。4.2 回调接口的位置与路由设计回调 Controller 需要独立于普通业务接口原因有两个。其一回调地址是下单时固定传给微信的后续更换路径要重新下单才能生效所以路径一旦确定尽量稳定其二回调请求头里带有微信平台的签名信息拦截器里关于用户登录鉴权、token 校验的逻辑对微信服务器根本不适用单独建一个 Controller 可以避开这些通用拦截器。RestController RequestMapping(/wx/pay) public class PayNotifyController { PostMapping(/notify) public ResponseEntityString notify(HttpServletRequest request) throws Exception { return wxNotifyService.handleNotify(request); } }4.3 验签与密文解密回调处理的核心代码回调报文包含两层保护。第一层是微信平台对报文整体做了 HTTP 签名放在请求头的 Wechatpay-Signature 字段里需要用平台证书的公钥去验证防止第三方伪造通知。第二层是报文的 resource 字段内容被 AES-256-GCM 加密需要 APIv3 密钥解密防止传输链路泄露明文。完整的处理逻辑如下Service public class WxNotifyService { private final RSAAutoCertificateConfig wxPayConfig; private final OrderMapper orderMapper; public ResponseEntityString handleNotify(HttpServletRequest request) throws Exception { // 读取请求体 String body StreamUtils.copyToString(request.getInputStream(), StandardCharsets.UTF_8); // 构造验签参数 RequestParam param new RequestParam(); param.setWechatpaySerial(request.getHeader(Wechatpay-Serial)); param.setWechatpaySignature(request.getHeader(Wechatpay-Signature)); param.setWechatpayTimestamp(request.getHeader(Wechatpay-Timestamp)); param.setWechatpayNonce(request.getHeader(Wechatpay-Nonce)); param.setBody(body); // 验签失败直接返回 400不再往下处理 if (!wxPayConfig.createVerifier().verify(param.getWechatpaySerial(), param.getWechatpaySignature(), param.getWechatpayTimestamp(), param.getWechatpayNonce(), param.getBody())) { return ResponseEntity.badRequest().build(); } // 解密报文 AesUtil aesUtil new AesUtil(wxPayConfig.getApiV3Key()); String plaintext aesUtil.decryptBody(param.getBody()); JSONObject resource JSON.parseObject(plaintext); // 从 resource 中取出关键字段 String outTradeNo resource.getString(out_trade_no); String transactionId resource.getString(transaction_id); String tradeState resource.getString(trade_state); int totalAmount resource.getJSONObject(amount).getIntValue(total); // 只有 SUCCESS 才更新订单其他状态如 REFUND 另行处理 if (SUCCESS.equals(tradeState)) { updateOrderIfConsistent(outTradeNo, transactionId, totalAmount); } // 返回 200 空 body微信收到即停止重试 return ResponseEntity.ok().build(); } private void updateOrderIfConsistent(String outTradeNo, String transactionId, int totalAmount) { Order order orderMapper.selectByOrderNo(outTradeNo); if (order null) { // 订单不存在说明是伪造回调或非法参数记录告警 return; } // 金额核对回调金额与本地订单金额必须一致 if (order.getAmount().longValue() ! totalAmount) { // 金额不一致资金风险记录并触发人工介入 return; } // 状态机只有待支付状态能流转为已支付 if (PENDING.equals(order.getStatus())) { order.setStatus(SUCCESS); order.setTransactionId(transactionId); orderMapper.updateByOrderNo(order); } } }代码里的解密过程是 AES-256-GCM微信支付规定的细节是nonce 固定 12 字节额外认证数据 aad 为空字符串解密后的明文是 JSON 字符串。AesUtil 类把这些细节封装好了自己实现时要特别注意 nonce 不能直接当 iv 用长度和格式必须按 GCM 模式来。验签这一步绝不能省略。有同学在本地调试时嫌麻烦直接跳过验签只解密看字段这在测试环境也许能跑通一旦接口暴露在公网任何人都可以往 notify 地址 POST 伪造报文配合一个反向代理就能模拟微信的请求格式。金额核对同样关键只校验 out_trade_no 存在但不管金额攻击者拿一个真实支付成功的 out_trade_no 伪造小额通知订单就被错误标记为支付成功。4.4 幂等更新防止同一笔支付被重复处理微信回调会重试同一个 out_trade_no 可能收到多次通知。重复处理最典型的故障是订单状态已经被改成 SUCCESS第二次回调进来又执行一次更新如果更新逻辑里隐藏着赠品发放、积分累加之类操作用户就白嫖多次。代码里加了两道保险。第一道是状态机约束只允许 PENDING 流转到 SUCCESS已经 SUCCESS 的单子直接跳过第二道是数据库层订单表的 out_trade_no 建唯一索引更新语句带上 status PENDING 作为条件返回更新行数为 0 说明已被处理UPDATE tb_order SET status SUCCESS, transaction_id #{transactionId}, pay_time NOW() WHERE out_trade_no #{outTradeNo} AND status PENDING如果系统里有后续业务比如支付成功要发消息通知仓储发货不要直接在回调里同步处理。常见的做法是把 out_trade_no 写入本地消息表状态标记为待发送由独立任务消费并允许重试这一步能把微信 5 秒的响应时限和业务处理解耦开。demo 阶段先不做消息队列但要把这个设计思想留在代码注释里。5. 支付 demo 避坑指南5 个高频翻车点5.1 把 APIv3 密钥和商户私钥混为一谈现象下单返回 401签名错误代码反复检查签名逻辑也没问题。原因某开发者在商户平台把 APIv3 密钥抄下来直接当成私钥内容填进了配置。APIv3 密钥是 32 字节的对称密钥负责解密回调商户私钥是 PEM 格式的非对称密钥负责请求签名和二次签名。两边字节格式完全不同填错位置签名校验当然过不了。解决把两个值分开存放。APIv3 密钥是一串随机字符没有 pem 头私钥文件以 “-----BEGIN PRIVATE KEY-----” 开头。printf 一下配置加载的内容用头尾特征一眼就能分辨。5.2 金额单位错乱总差 100 倍现象下单金额明明传了 1 元支付时却显示 100 元或者反过来回调金额对不上。原因微信支付 V3 的金额单位是分前端展示的 1 元对应整数 100。如果后端代码里直接拿前端传来的元做入库再原样传给微信就会差 100 倍。解决后端统一定义金额为 Long 型分入库用分和小程序交互也只用分。只在展示层做元分转换转换时用 BigDecimal 的 setScale(2, RoundingMode.HALF_UP) 而不是 Double 运算防止精度丢失。5.3 回调收不到notifyUrl 必须公网可达且路径稳定现象支付成功微信侧显示通知发送成功后端却始终没收到请求。原因notifyUrl 填了 localhost 或内网地址微信服务器无法访问或者回调接口前面有网关、防火墙把 POST 请求拦掉了某些云厂商的默认安全组只放行 80 和 443没有放行自定义端口。解决测试阶段把后端部署到一台有公网地址的测试服务器用域名或 IP 直连路径不带自定义端口最省心。收到回调后在 Controller 第一行打 access log记录请求头和 body配合日志快速定位是被拦截还是验签失败。5.4 springboot 版本太高老教程代码直接编译报错现象抄了网上的 demo在 springboot 3.x 工程里 javax.servlet.* 全部找不到或者 Redis、切面相关的老写法全都失效。原因springboot 3.0 起基础包从 Java EE 迁移到 Jakarta EEjavax 包名整体变成 jakarta。老教程大多基于 springboot 2.ximport javax.servlet.http.HttpServletRequest 在 3.x 下自然编译不过。解决做支付 demo 优先用 springboot 2.7 配 Java 8这是最稳的组合网上资料最多排错也快。如果项目必须用 springboot 3把依赖里的 javax 替换成 jakarta同时确认支付 SDK 版本兼容 Jakarta 规范。别在支付链路上同时挑战新框架和旧教程两个变量叠加会让排查难度翻倍。5.5 回调响应格式用错V2 的 XML 写法套到 V3 上现象回调逻辑明明执行成功微信却不断重试日志里同一笔订单刷屏。原因微信支付 V2 的回调要求返回 XML 格式的 return_code /return_code V3 的规则完全不同只需要 HTTP 200 且返回空 body 就算确认成功。有的同学看了 V2 资料把 XML 响应透传出来反而破坏了 V3 的协议约定。解决确认自己对接的版本。新版商户号基本都走 V3回调方法返回 ResponseEntity.ok().build() 即可不要再拼 XML。另外注意回调处理成功和失败都不要抛异常可以用状态码区分实在处理不了也要先返回 200 并记录死信数据人工补偿比让微信无限重试更有意义。6. 一个更稳的改法让支付结果以数据库为准而不是回调驱动回调通知本质上是一条不可完全信任的异步消息。微信会重试网络会抖动服务器会宕机单靠回调驱动订单状态系统就永远有一个“钱付了但订单还挂着”的窗口。生产级做法是把数据库里的订单状态当唯一事实来源回调负责“尽快推进”定时任务负责“最终兜底”。具体改动是在 service 层加一个主动查单的定时任务Scheduled(fixedDelay 60_000) public void settlePendingOrders() { // 找出超过 5 分钟仍处于 PENDING 的订单 ListOrder pendingOrders orderMapper.selectPendingOlderThan(5); for (Order order : pendingOrders) { try { QueryOrderResult result queryOrderByOutTradeNo(order.getOrderNo()); if (SUCCESS.equals(result.getTradeState())) { updateOrderIfConsistent(order.getOrderNo(), result.getTransactionId(), result.getAmount()); } else if (CLOSED.equals(result.getTradeState()) || REVOKED.equals(result.getTradeState())) { order.setStatus(CLOSED); orderMapper.updateByOrderNo(order); } // NOTPAY 等中间状态继续等待 } catch (Exception e) { // 记录日志下一次循环继续不做重试风暴 } } }查单接口和下单接口一样需要商户签名路径是 /v3/pay/transactions/out-trade-no/{out_trade_no}。定时任务加上回调双重保障后即使某条回调通知彻底丢失最坏情况下 5 到 6 分钟也会被主动查单纠正过来。付款成功后还要处理一个容易被忽略的问题用户支付成功但前端没有任何反应停留在订单页。用户不该依赖定时任务的补偿速度他需要即时反馈。我的习惯是前端在 wx.requestPayment 的 success 回调里不急着提示“支付成功”而是轮询后端订单状态接口每秒一次、最多十次看到后端落库成功再提示这样体验和事实一致也绕开了回调延迟带来的虚假等待。另外建议保留一份 plaintext 解密的原始报文落库时把 transaction_id、回调时间、验签结果一起存进支付日志表。万一出现对账差异这份日志能证明“微信确实通知过后端确实验签成功”配合主动查单结果基本可以还原每一笔订单的真实走向。我身边 A 同学的项目就是这样改的后来线上真遇到一次微信回调网关抖动定时任务在两轮扫描内自动修复了订单态比他手动翻数据库改状态快得多。引用我自己的交付习惯demo 可以只管回调面向用户的订单系统必须回调加主动查单双保险。希望这篇笔记能帮你少走几趟弯路把微信小程序支付后端一次跑顺。本文还有配套的精品资源点击获取