直接说结论：如果是做移动端网页支付，支付宝H5支付（也叫手机网站支付）这条链路，在 Spring Boot 项目里接入并不复杂，但坑比较多。我最近刚给一个商城类项目完整做完“下单支付—异步回调—主动查单—退款—退款查单”这一整套，用的就是 Java 版官方 SDK，过程中踩了好几个文档里不会明说的坑。这篇把核心流程、关键代码、参数设计和排错经验都整理出来，给后面要做类似需求的人一份能直接照着抄的参考。
1. 项目整体设计与方案选型
1.1 支付宝H5支付的本质与适用场景
很多人容易把H5支付和手机App支付混在一起，实际上这是两条完全不同的产品线。支付宝H5支付的核心使用场景是：用户在使用手机浏览器访问你的网页或H5商城时，不需要下载App，直接跳转到支付宝收银台完成付款，支付完成后自动跳转回你的业务页面。
从技术本质上看，H5支付就是服务端拼接一个自动提交的HTML表单（form），前端拿到这个表单后自动POST到支付宝网关，支付宝收银台页面会接管后续操作。所以整个支付成功与否，最终依赖两条反馈通道：一是用户在支付宝收银台支付完成后同步跳转回商家的returnUrl；二是支付宝服务端异步通知商家的notifyUrl。前者只是给用户浏览器看的跳转结果，不能作为订单最终状态依据；后者才是系统对账和更新订单状态的唯一权威来源，这条原则后面所有流程都要围绕它来设计。
为什么选H5而不是扫码支付或者App支付？看场景。扫码支付适合PC端浏览器，用户在手机上没法扫码；App支付需要App集成SDK，还要维护iOS和Android两套打包流程。如果业务是公众号菜单、微信内浏览器、普通手机浏览器、短信链接这些入口，H5支付是兼容性最好的一种方案。用户点开链接，直接收银台付款，支付完成后回到网页，转化路径最短。
1.2 技术选型：Spring Boot + 官方SDK还是原生HTTP调用
支付宝官方提供了Java版SDK（alipay-sdk-java），封装了网关请求、参数签名、响应解析等底层逻辑。实际项目里可以直接选择支持Spring Boot。我这里用的是Spring Boot 2.7.x配合官方SDK 4.x版本，这套组合成熟稳定，网上资料也多，遇到问题容易搜到答案。
有人会问：为什么不自己用HTTP工具拼参数、自己算签名？当然可以，但完全没必要。签名算法涉及RSA2加密、URL编码、参数排序、验签等一堆细节，手写极易出错，调试成本极高。官方SDK把pageExecute、execute、rsaCheckV1这些方法都封装好了，直接传入业务参数就能拿结果。我的原则是：支付这类涉及资金的操作，能用官方SDK绝不用手写方案，稳定性优先。
从整体流程上看，完整的支付对账闭环包含四个核心模块：下单并生成支付表单、异步通知接收与验签、主动查询订单状态、退款与退款查单。下面按模块拆开讲。
2. 环境准备与核心配置
2.1 开通产品、应用创建与密钥配置
在写代码之前需要先在支付宝开放平台完成三件事：创建应用、开通产品能力、配置密钥。
- 创建应用：在开放平台控制台创建网页移动应用，拿到应用的
appId。 - 开通产品：在应用详情里添加“手机网站支付”功能，正常情况下即时生效。退款能力不需要单独申请，
alipay.trade.refund接口默认可用。 - 配置密钥：生成应用私钥和公钥，将应用公钥上传到支付宝，换取支付宝公钥。这里一定要区分清楚：应用私钥是自己生成的，用于请求签名；支付宝公钥是从平台获取的，用于验证支付宝回传消息的签名，两者不能搞混。
配置密钥时建议使用RSA2签名方式，对应算法是SHA256WithRSA。相比旧的RSA1方式，RSA2安全性更高，支付宝方面也推荐使用。
注意：如果是正式上线，回调地址必须是HTTPS，而且域名要和应用配置的授权回调地址保持一致。沙箱环境调试没有这个限制，但沙箱和正式环境的网关地址、密钥要严格区分，我见过不少人把沙箱密钥复制到生产配置里，排查半天才发现是环境配置错了。
2.2 Spring Boot引入依赖与配置类
Maven依赖按官方文档引入：
<dependency> <groupId>com.alipay.sdk</groupId> <artifactId>alipay-sdk-java</artifactId> <version>4.38.0</version> </dependency>SDK版本迭代比较快，4.x系列接口相对稳定。引入依赖后在配置文件里维护支付宝相关参数：
alipay: app-id: 你的appId app-private-key: | -----BEGIN RSA PRIVATE KEY----- 你的应用私钥 -----END RSA PRIVATE KEY----- alipay-public-key: | -----BEGIN PUBLIC KEY----- 支付宝公钥 -----END PUBLIC KEY----- gateway-url: https://openapi.alipay.com/gateway.do charset: UTF-8 sign-type: RSA2 notify-url: https://api.你的域名.com/api/pay/alipay/notify return-url: https://你的域名.com/pay/result创建配置类，初始化AlipayClient单例：
@Configuration @ConfigurationProperties(prefix = "alipay") @Data public class AlipayConfig { private String appId; private String appPrivateKey; private String alipayPublicKey; private String gatewayUrl; private String charset; private String signType; private String notifyUrl; private String returnUrl; @Bean public AlipayClient alipayClient() { return new DefaultAlipayClient( gatewayUrl, appId, appPrivateKey, AlipayConstants.FORMAT_JSON, AlipayConstants.CHARSET_UTF8, alipayPublicKey, signType ); } }DefaultAlipayClient构造参数顺序容易错，IDE提示会有，按顺序对号入座就行：网关地址、应用ID、应用私钥、格式、字符集、支付宝公钥、签名类型。网关地址沙箱和正式不一样，配置提取出来放到application-{env}.yml里是对的，切换环境不用改代码。
3. 支付链路核心实现：从下单到回调
3.1 服务端创建订单并生成form表单
整体时序是这样的：前端（H5页面）携带订单号等信息请求后端下单接口 → 后端校验订单状态、生成支付宝预下单参数 → 调用SDK得到一段自动提交的form表单字符串 → 返回给前端，前端拿到字符串后写入页面并自动触发提交 → 用户跳转支付宝收银台 → 支付完成。
核心代码：
public String createPayOrder(String orderNo, BigDecimal amount, String subject, String userOpenId) { // 1. 业务校验：查数据库订单，确认状态为待支付、金额一致 Order order = orderMapper.selectByOrderNo(orderNo); if (order == null || order.getStatus() != OrderStatus.WAIT_PAY) { throw new BizException("订单不存在或已处理"); } // 2. 构建支付宝H5支付请求 AlipayTradeWapPayRequest request = new AlipayTradeWapPayRequest(); request.setNotifyUrl(alipayConfig.getNotifyUrl()); request.setReturnUrl(alipayConfig.getReturnUrl()); JSONObject bizContent = new JSONObject(); // 商户订单号：只能用字母、数字、下划线，且需要保证唯一 bizContent.put("out_trade_no", orderNo); bizContent.put("total_amount", amount.setScale(2, RoundingMode.HALF_UP).toString()); bizContent.put("subject", subject); bizContent.put("product_code", "QUICK_WAP_WAY"); // 超时时间，注意单位：m表示分钟，c表示天 bizContent.put("timeout_express", "30m"); request.setBizContent(bizContent.toJSONString()); // 3. pageExecute 返回的是表单提交HTML AlipayTradeWapPayResponse response = alipayClient.pageExecute(request); if (response.isSuccess()) { return response.getBody(); // 这是一段含form标签的HTML字符串 } throw new BizException("支付宝下单失败：" + response.getMsg()); }注意几个关键参数：
out_trade_no是商户订单号，必须全局唯一，同一笔订单不能重复下单。建议用业务订单号直接做，避免额外映射，但要做好长度控制和字符白名单校验。total_amount必须以字符串传，用BigDecimal计算后转字符串，避免浮点误差。不要用double传金额。product_code填QUICK_WICK_WAY，这是H5支付固定值，填错了会报“产品码不匹配”。timeout_express表示订单支付超时时间，超过后支付宝会关闭这笔交易。我习惯设30分钟，太短用户容易在收银台被中断，太长容易积累超时账单。
pageExecute返回的是完整HTML字符串，里面是一个自动提交的form表单。前端的处理方式通常是：
<div id="paymentForm"></div> <script> // 假设后端返回的data字段是form HTML字符串 const formHtml = res.data; document.getElementById('paymentForm').innerHTML = formHtml; // 表单会自动submit，也可以手动触发：document.forms['alipaysubmit'].submit(); </script>有些前端框架会拦截表单提交导致无法跳转，这时候可以稍微改动一下，解析出action地址和biz_content等参数，前端用window.location.href做跳转，但参数较多容易出错，最省事的还是把form字符串原样插入DOM。实测中iframe方式有问题，支付宝官方不允许在iframe里承载收银台，所以直接整页跳转。
3.2 异步通知回调处理与验签
异步通知是整条支付链路里最容易出问题的环节，也是绝对不能省的部分。支付宝在用户支付完成后会主动向配置的notifyUrl发一个POST请求，带上所有交易参数和签名。服务端收到通知后必须完成这几件事：
- 验签：确认消息确实来自支付宝，防止伪造。
- 校验业务参数：商户订单号、支付金额、AppId要和本系统订单一致。
- 幂等处理：防止重复通知导致订单状态重复变更。
- 返回响应：正确处理必须输出
success（不加引号），否则支付宝会按策略重试。
控制器实现：
@PostMapping("/api/pay/alipay/notify") public String alipayNotify(HttpServletRequest request) throws AlipaySignatureException { // 1. 读取参数，支付宝回调参数全部是字符串类型 Map<String, String> params = new HashMap<>(); Map<String, String[]> requestParams = request.getParameterMap(); for (String name : requestParams.keySet()) { String[] values = requestParams.get(name); params.put(name, String.join(",", values)); } // 2. 验签 boolean signVerified = AlipaySignature.rsaCheckV1( params, alipayConfig.getAlipayPublicKey(), alipayConfig.getCharset(), alipayConfig.getSignType() ); if (!signVerified) { return "failure"; } // 3. 业务校验 String outTradeNo = params.get("out_trade_no"); String tradeNo = params.get("trade_no"); String totalAmount = params.get("total_amount"); String appId = params.get("app_id"); String tradeStatus = params.get("trade_status"); if (!alipayConfig.getAppId().equals(appId)) { return "failure"; } // 订单存在性校验 + 金额比对：用字符串对比或者BigDecimal compareTo，不能用equals比较1.0和1.00 Order order = orderMapper.selectByOrderNo(outTradeNo); if (order == null || new BigDecimal(totalAmount).compareTo(order.getAmount()) != 0) { return "failure"; } // 4. 幂等更新：订单状态由待支付改为已支付，必须加状态条件，防止并发重复处理 if (OrderStatus.WAIT_PAY.equals(order.getStatus())) { int rows = orderMapper.updateStatusPaid(outTradeNo, tradeNo, order.getStatus()); if (rows > 0) { // 支付成功后的业务处理：加订单流水、发通知、释放库存等 } } return "success"; }这里有个关键点容易被忽视：trade_status有很多种状态，TRADE_SUCCESS和TRADE_FINISHED都表示交易成功。实际项目中到底怎么判断？最简单的办法是：只要收到TRADE_SUCCESS就更新订单为已支付，如果后续又收到TRADE_FINISHED，不影响订单状态，可以忽略或者只做流水记录。不要两种状态分开更新逻辑，容易造成重复动作。更稳妥的做法是：
if (!"TRADE_SUCCESS".equals(tradeStatus) && !"TRADE_FINISHED".equals(tradeStatus)) { // 其他状态：TRADE_CLOSED、WAIT_BUYER_PAY等，按需处理 return "success"; }金额校验用compareTo，因为支付宝回调的金额是字符串"1.00"，你的数据库存的是1.00，如果用equals比较BigDecimal，"1.0"和"1.00"会不相等，坑从此而来。统一用compareTo等于0判断金额一致。
幂等处理必须依赖数据库更新行数加乐观锁。因为通知可能重复、并发到达，如果代码里先判断再加锁更新，中间状态很难控制。我在实际项目里习惯用一条带条件更新的SQL来保证同一时刻只有一个线程能更新成功：
UPDATE t_order SET status = 'PAID', trade_no = #{tradeNo}, pay_time = NOW() WHERE order_no = #{orderNo} AND status = 'WAIT_PAY'这种写法把并发问题交给数据库行锁解决，比加服务端分布式锁简单有效得多。
3.3 同步跳转returnUrl处理与前端适配
returnUrl是用户在支付宝收银台支付完成后跳回商家页面的地址，这里有一个很多人搞不清楚的原则：returnUrl只做展示，不能改状态。因为用户有概率在支付完成后手动关闭浏览器、断网，或者提前杀掉WebView，导致根本没有跳回商家页面，但这并不影响支付实际成功的状态，最终以异步通知为准。
所以我的做法是：returnUrl对应一个H5页面路径，页面上读取地址栏参数（主要是out_trade_no、trade_no、total_amount等），然后静默请求后端的一个订单查询接口，把实时订单状态返回给前端，展示“支付成功”或“支付处理中”给用户。即使查询接口返回“处理中”，也不要慌，异步通知会把状态纠正过来。
@GetMapping("/api/pay/alipay/result") public Result<OrderVO> queryOrderResult(String orderNo) { Order order = orderMapper.selectByOrderNo(orderNo); // 如果订单状态是待支付，可以主动调用支付宝查询接口确认一次，而不是直接给用户展示失败 if (order != null && OrderStatus.WAIT_PAY.equals(order.getStatus())) { tradeQuery(orderNo); } return Result.ok(convert(order)); }前端支付结果页的逻辑也简单：进入页面后请求一次后端查询接口，显示订单状态；如果3秒后未支付成功，启动轮询，每2秒查一次，最多查5次。查询不到已支付状态就显示“支付结果确认中，请稍后刷新”，然后让用户在订单列表里看最终状态。这样用户体验比直接显示失败强很多。
3.4 主动查单：彻底解决通知丢失问题
异步通知虽然可靠，但极端场景下确实存在通知丢失的可能。比如服务重启瞬间通知进来没人接收，或者网络异常导致支付宝重试次数用完。所以成熟项目要保留主动查单的兜底逻辑：定时任务对状态为“支付中”且超过一定时间的订单，主动调用查询接口确认真实交易状态。
查询接口也很简单：
public boolean tradeQuery(String orderNo) { AlipayTradeQueryRequest request = new AlipayTradeQueryRequest(); JSONObject bizContent = new JSONObject(); bizContent.put("out_trade_no", orderNo); request.setBizContent(bizContent.toJSONString()); AlipayTradeQueryResponse response = alipayClient.execute(request); if (response.isSuccess()) { String tradeStatus = response.getTradeStatus(); if ("TRADE_SUCCESS".equals(tradeStatus)) { // 幂等更新订单为已支付 updateOrderPaidIfNeed(orderNo, response.getTradeNo(), response.getTotalAmount()); return true; } if ("TRADE_CLOSED".equals(tradeStatus)) { // 更新订单为已关闭 } } return false; }我建议给订单表加一个状态字段为“待支付”的超时任务，每5分钟批量扫一次超过30分钟还没有支付的订单，调用查询接口确认状态，再决定更新支付成功还是关闭订单。这套兜底逻辑是支付系统健壮性的关键。如果只依赖异步通知，万一某天漏掉一笔，用户付了钱而系统显示未支付，客服工单就来了。
4. 退款流程实现：退款、幂等与对账
4.1 退款接口核心参数
退款和查单相对简单，但同样有坑。退款分为全额退款和部分退款，核心就是发起退款请求后，用out_request_no关联退款请求，再通过退款查单接口确认退款结果。
退款参数如下：
public RefundResult refund(String orderNo, BigDecimal refundAmount, String refundRequestNo) { AlipayTradeRefundRequest request = new AlipayTradeRefundRequest(); JSONObject bizContent = new JSONObject(); bizContent.put("out_trade_no", orderNo); bizContent.put("refund_amount", refundAmount.setScale(2, RoundingMode.HALF_UP).toString()); // 退款单号：幂等关键，同一笔退款单号第二次提交不会重复退款 bizContent.put("out_request_no", refundRequestNo); // 退款原因，长度有限制，不要写太长的文本 bizContent.put("refund_reason", "用户申请退款"); request.setBizContent(bizContent.toJSONString()); AlipayTradeRefundResponse response = alipayClient.execute(request); if (response.isSuccess()) { // 退款接口同步返回的资金渠道信息，可作为凭证 String refundFee = response.getRefundFee(); // 注意：refundFee可能为null，谨慎处理 return RefundResult.success(response.getTradeNo(), refundFee); } // 失败时常见错误码：ACQ.TRADE_NOT_EXIST、ACQ.INVALID_PARAMETER等 return RefundResult.fail(response.getCode(), response.getMsg()); }4.2 线上线下结合：退款状态确认与幂等设计
退款有个容易被忽略的特点：支付宝退款接口是异步执行的，AlipayTradeRefundResponse的成功只能说明请求受理，不代表退款资金已经到账。真正确认退款是否成功，要看支付宝异步通知（退款也有异步通知）或者调用退款查单接口。
所以我的设计是：
- 退款申请后先更新本系统退款申请单状态为“处理中”。
- 然后调用支付宝退款查单接口确认状态，如果
refund_status为REFUND_SUCCESS，更新退款单为已成功；如果是不存在记录，可能还没处理完，等异步通知或者定时任务重试。
退款查单的代码：
public void refundQuery(String orderNo, String refundRequestNo) { AlipayTradeFastpayRefundQueryRequest request = new AlipayTradeFastpayRefundQueryRequest(); JSONObject bizContent = new JSONObject(); bizContent.put("out_trade_no", orderNo); bizContent.put("out_request_no", refundRequestNo); request.setBizContent(bizContent.toJSONString()); AlipayTradeFastpayRefundQueryResponse response = alipayClient.execute(request); if (response.isSuccess()) { String refundStatus = response.getRefundStatus(); if ("REFUND_SUCCESS".equals(refundStatus)) { // 更新退款单为成功，记录支付宝退款单号 } } }幂等设计：在退款申请单上建out_request_no唯一索引，同一退款请求多次调用只会落一条记录。即使用户反复点击退款按钮、后端重复收到退款请求，数据库的唯一约束会挡在业务逻辑之前。这是退款链路最关键的防线。
注意：退款金额可以做累加限制。部分退款多次操作时，要校验累计退款金额不能超过订单实付金额，否则用户发起多次退款时，最后一次会因余额不足而失败，脏数据就出来了。
4.3 退款异步通知与对账
支付宝针对退款也提供了异步通知，通知URL和支付通知共用同一个notify_url也是允许的，但建议区分逻辑，通过参数里的refund_fee、out_request_no字段识别退款通知。退款通知的验签流程和支付通知一模一样，只是业务处理不同。
对账方面，实践中会引入每日对账任务：调用支付宝的对账单下载接口，获取前一日的交易明细，和本地订单表逐一比对状态和金额。手工对账的精髓在于：凡是本地是“已支付”但支付宝账单里没有成功记录的交易，需要标记异常；反过来，支付宝账单有成功记录但本地是“待支付”的，需要主动查单并修正。这套机制看起来很重，但对金额敏感的业务是值得的，建议至少每天跑一次。
5. 常见问题与排错实战
5.1 手机端唤起支付宝收银台失败
这类问题通常表现为：用户点击付款后没有跳转到支付宝，而是停留在一个空白页或者阿里云的错误页。
先在沙箱环境复现，然后按这个顺序排查：
- 确认
product_code是不是QUICK_WAP_WAY，H5支付填错产品码最常见。 - 确认前端有没有把form字符串正常写入DOM。很多前端项目的安全策略会拦截
document.write和HTML注入，需要改用外部div的innerHTML赋值。 - 确认网关地址有没有配置错，沙箱和正式网关地址不一样，SDK初始化时网关地址填错就是莫名白屏。
- 确认请求参数中的
out_trade_no没有下划线和特殊字符之外的内容，订单号里如果带了中文或空格，网关直接拒绝。
5.2 回调验签失败
验签失败先看日志里支付宝回传的sign字段和参与验签的参数列表。常见原因是回调参数不是纯字符串类型，比如total_amount在部分SDK版本会被解析成JSON number，导致签名串拼接不一致。解决方法是取参数时统一用String.join(",", values)，不要直接用request.getParameter()拿到的数组，也不要对参数做JSON格式转换。
另外注意SDK版本差异：高版本SDK里rsaCheckV1传入参数必须包含sign，但sign不需要在params里额外传入。做日志脱敏时别把sign给打了星号，否则你没法排查签名串。
5.3 金额误差、时区与乱码
金额问题两条经验：
- Java端所有金额运算用
BigDecimal，数据库存分为整数也可以，支付宝交互时统一转成元为单位的字符串，保留两位小数。 - 回调校验金额时禁止用
equals比较BigDecimal，必须用compareTo。原因前面说过了，"1.0"和"1.00"的精度不一致。
时区问题主要出现在对账单解析和交易时间展示上。支付宝接口返回的时间是yyyy-MM-dd HH:mm:ss，时区是GMT+8。服务器如果部署在海外（比如用了Etc/UTC），直接本地解析会相差8小时，导致对账和用户端展示错乱。统一在代码里指定时区解析：
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss").withZone(ZoneId.of("Asia/Shanghai"));乱码问题一般集中在沙箱测试时返回的response.getBody()会包含中文门店名称、商品描述等，在日志里显示乱码。其实这不是业务问题，而是SDK初始化时字符集没有显式配置。DefaultAlipayClient构造方法里字符集一定要传"utf-8"，不要依赖默认值。
5.4 重复通知与服务重启导致回调没收到
重复通知很好验证，在业务处理逻辑前打印日志，观察同一trade_no是否多次到达。处理方案就是幂等更新加状态条件，这是标准解法。
服务重启导致回调丢失，严格说不是支付宝的问题，而是服务不可用时段内支付宝的重试机制。支付宝对异步通知有重试策略，但不能无限等待。应对手段就是主动查单兜底：定时任务扫描待支付订单，调用支付宝查询接口确认实际状态。如果只有回调没有兜底，就等于把系统正确性完全押在网络保障上，风险不可控。
5.5 沙箱环境调试的几个要点
沙箱环境和正式环境完全是两套参数，开发联调时注意以下区别：
appId不一样，需要用沙箱应用ID。- 沙箱网关URL是
https://openapi.alipaydev.com/gateway.do。 - 沙箱环境需要在沙箱控制台配置测试买家账号，并给测试账号充值沙箱余额后才方便完整测试付款和退款流程。
沙箱环境下异步通知经常有延迟，联调时建议结合主动查单一起来验证，不能干等通知。同时沙箱环境不保证和正式环境行为完全一致，部分金额精度和超时策略会略有差异，所以沙箱跑通后，务必要在正式环境小额真钱测试一遍再发布。
6. 项目上线前必须检查的几件事
支付功能不是写完代码就完事，上线前有几个容易忽略的点我每次都要过一遍。
- 回调地址白名单：支付宝后台配置的授权回调地址要和实际生产环境域名严格一致。虽然现在的版本对回调地址限制有所放宽，但配置不一致依然可能导致跳转失败。
- HTTPS强制：支付相关页面和回调地址都必须是HTTPS证书有效的域名，不能用IP裸奔。支付宝回调需要校验传输链路，HTTP容易在运营商层面被篡改。
- 金额单位确认：前后端对接时约定清楚，接口层一律用元，数据库存储可以用分，但转换逻辑要收敛在一个地方，别到处都是
* 100和/ 100，很容易埋雷。 - 日志记录：所有和支付宝交互的请求参数、响应结果、验签结果都要打全量日志，方便对账和排查，但注意对签名、密钥等敏感信息脱敏。
- [敏感词过滤]不展开谈，但支付系统上线的合规审查一定要提前做，不要等上线前才走流程。
再分享一个生产环境很有用的扩展思路：在支付回调入口加一个MQ消息或者本地事件表，把回调内容先落库再异步处理。这样做的好处是回调服务和订单服务解耦，即使订单服务改造升级，回调事件也不会丢失，后续对账排错也更方便。我在项目里就用了事件表模式，效果很好，强烈推荐。
实际跑下来，支付宝H5支付的整个复杂度不在于接口怎么调，而在于状态机怎么设计、幂等怎么做、异常怎么收敛。把支付/退款的通知链路想清楚，所有操作都围绕“最终以支付宝异步通知和查单结果为准”，这套系统就能稳定运行。如果按照这篇把代码写一遍，你会发现踩坑大部分都避开了，剩下的就是拿着日志对照开放平台的错误码文档慢慢磨，那些都只是时间问题。写代码的阶段我已经替你们走完了，剩下的上线验证你们就大胆跑吧。
