简介：这款PHP扩展包以支付宝官方Alipay Easy SDK为基础，单独裁剪出仅包含PHP语言的Composer依赖包，删除了其他语言代码包，使PHP项目不再携带冗余资源。包体约125KB，体积小巧，通过composer require alphasnow/alipay-easysdk-php即可直接安装，并借助.gitattributes在安装时忽略test/文件夹，保持工作区干净。SDK延续了官方版本的设计理念，对开放能力API做了贴近现代场景的精心设计与裁剪，自动完成证书校验、加签、验签、HTTP请求等非功能性流程，让开发者只需关注业务参数；版本号同样跟随官方SDK保持一致，便于后续升级维护。该资源面向中高级PHP工程师，尤其适合电商、支付类应用快速接入支付宝常用能力，也可作为学习官方SDK内部封装逻辑的参考，帮助理解从请求构造到验签返回的完整链路。当前已有928人学习下载，是一份轻量化、易集成的PHP支付宝SDK解决方案。

1. 从 easysdk 拆包说起：alipay-easysdk-php 解决了 PHP 支付接入的什么痛点

做 PHP 后端的人大概率都经历过这一幕：项目里要接支付宝，打开官方文档发现 easysdk 是一个多语言混排的工程，Java、Python、PHP 的代码堆在同一个仓库里；真要收编进自己的 composer 项目，还得想办法过滤掉一堆用不上的目录。alipay-easysdk-php 这个包就是为了终结这种局面——它把 easysdk 中 PHP 侧的能力单独分离成包，客户端初始化、参数签名、同步验签、异步通知处理这些固定动作全部封装好。你只需要在配置里填应用 ID、应用私钥、支付宝公钥三个值，就能在业务代码里调用支付下单、退款、查询，再不用手工拼 sign、timestamp、biz_content 那一大串。适合谁？PHP 电商、SaaS、小程序的开发者，尤其是换过几个项目、每回都要重新粘一遍 SDK 的那批老手。

2. 拆包后的目录与依赖设计：composer 包是怎么组织签名、配置与请求链路的

2.1 目录结构和 PSR-4 自动加载

拿到的包按职责拆成了几个清晰的目录。以我拆过的主流版本为例，大致是这种布局：

src/ Config.php // 配置对象：app_id、私钥、公钥、网关地址 Client.php // 对外的支付宝客户端门面 Payment/ TradeService.php // 下单、查询、退款、关闭等交易接口 NotifyHandler.php // 异步通知验签与报文解密 Security/ Signer.php // RSA2 签名与验签 Decryptor.php // AES 内容解密（证书/密钥模式时用到） tests/ SignerTest.php TradeServiceTest.php composer.json README.md

这个结构刻意把安全相关的代码和业务接口分开。签名验签属于基础设施，会被所有交易接口引用；TradeService 只在做网络请求时依赖 Signer，业务方不会直接碰签名类。命名空间一般设计为Alipay\EasySDK\...这种形式，composer.json 里用 PSR-4 注册：

{ "name": "alipay/easysdk-php", "description": "alipay-easysdk separate php package", "require": { "php": ">=7.2", "ext-openssl": "*", "ext-curl": "*" }, "autoload": { "psr-4": { "Alipay\\EasySDK\\": "src/" } } }

这里有几个值得留意的点。require 里除了 PHP 版本，还带上了 ext-openssl 和 ext-curl，因为签名算法基于 OpenSSL，请求发送依赖 curl；如果运行环境没装 openssl 扩展，composer install 直接会报环境检查错误，不用等到请求时才黑屏。PSR-4 的配置把根命名空间指向 src，意味着你在源码里只需按目录写命名空间，autoload 机制会自动加载对应文件，不需要维护一长串 classmap。

2.2 配置对象与网关切换

拆包后的配置入口通常是一个 Config 类，把 easysdk 里散落的参数收敛成可复制的对象。构造时接收几个基础参数：应用 ID、应用私钥、支付宝公钥、签名类型、网关地址。生产中常见的两种网关：正式环境固定是 openapi.alipay.com，沙箱环境则换成 openapi.alipaydev.com。这个切换会影响后续所有请求，所以 Config 会把它保存下来，每次请求时拼进 endpoint。

<?php namespace Alipay\EasySDK; class Config { public $appId; public $merchantPrivateKey; public $alipayPublicKey; public $signType = 'RSA2'; public $gatewayHost = 'openapi.alipay.com'; // 沙箱时改为 openapi.alipaydev.com public $protocol = 'https'; public $charset = 'UTF-8'; public function __construct(array $options) { $this->appId = $options['app_id'] ?? ''; $this->merchantPrivateKey = $options['merchant_private_key'] ?? ''; $this->alipayPublicKey = $options['alipay_public_key'] ?? ''; if (isset($options['gateway_host'])) { $this->gatewayHost = $options['gateway_host']; } } public function getEndpoint(): string { return $this->protocol . '://' . $this->gatewayHost . '/gateway.do'; } }

网关域名按环境填好，后续不管是当面付还是手机网站支付，全都走同一个 gateway.do 入口，区别只在 method 参数和 biz_content 内容。私钥和公钥不要写死在代码里，我一般会放到 .env 或配置中心，Config 构造时从环境变量读取，避免私钥不小心被提交到 Git 仓库。这算是接入支付类 SDK 的第一条职业素养，后面避坑章还会再提。

2.3 签名与验签的封装逻辑

签名是整个支付请求最核心的一步，也是拆包前后差异最大的地方。easysdk 原始工程把签名逻辑放在公共模块，拆出来之后 Signer 类变成了可以被单测覆盖的独立单元。RSA2 的签名过程可以拆成三句话：把业务参数按 key 排序，用key=value&拼成待签字符串，然后用应用私钥做 SHA-256 签名，签名结果 base64 编码后放进请求里的 sign 字段。

<?php namespace Alipay\EasySDK\Security; class Signer { public static function sign(array $params, string $privateKey, string $signType = 'RSA2'): string { $stringToBeSigned = self::buildSignString($params); $res = openssl_sign( $stringToBeSigned, $signature, $privateKey, $signType === 'RSA2' ? OPENSSL_ALGO_SHA256 : OPENSSL_ALGO_SHA1 ); if (!$res) { throw new \RuntimeException('签名失败，请检查应用私钥格式'); } return base64_encode($signature); } public static function verify(array $params, string $alipayPublicKey, string $signType = 'RSA2'): bool { $sign = $params['sign'] ?? ''; unset($params['sign'], $params['sign_type']); return self::verifyInternal($params, $sign, $alipayPublicKey, $signType); } public static function verifyResponse(array $node, string $sign, string $alipayPublicKey, string $signType = 'RSA2'): bool { return self::verifyInternal($node, $sign, $alipayPublicKey, $signType); } private static function verifyInternal(array $params, string $sign, string $publicKey, string $signType): bool { $stringToBeSigned = self::buildSignString($params); return (bool) openssl_verify( $stringToBeSigned, base64_decode($sign), $publicKey, $signType === 'RSA2' ? OPENSSL_ALGO_SHA256 : OPENSSL_ALGO_SHA1 ); } private static function buildSignString(array $params): string { ksort($params); $parts = []; foreach ($params as $key => $value) { if ($value === '' || $value === null || $key === 'sign' || $key === 'sign_type') { continue; } $parts[] = $key . '=' . $value; } return implode('&', $parts); } }

这段代码逻辑上要注意三点。第一，buildSignString里排除空值和 sign、sign_type 字段，这是支付宝签名规则里最容易漏掉的一环，漏了之后验签必然失败。第二，签名用私钥，验签用公钥，两边公私钥绝对不能搞混；应用私钥必须 PKCS8 格式，很多同学拿 PKCS1 的私钥直接塞进来，openssl_sign 会静默失败返回 false，现象就是所有请求都报签名错误。第三，参数里的值不能提前做 urlencode，网上有部分教程让先 encode 再拼，实测网关不认，会返回签名不匹配。这些细节拆出包之后全部收敛到 Signer 类里，业务方反而感知不到了。

3. 核心模块拆解：一笔支付从参数组装到异步回调的完整链路

3.1 客户端初始化与请求上下文

TradeService 是业务接触最多的入口，它依赖 Config 和 Signer。初始化之后，调用方只需要传入业务单号和金额，内部会负责把公共参数、业务参数合并，签名后发请求。公共参数包括 app_id、method、charset、sign_type、timestamp、version，每个请求都要带，封装前每次手动拼，封装后由 Client 统一生成。

<?php namespace Alipay\EasySDK; use Alipay\EasySDK\Payment\TradeService; class Client { private $config; public function __construct($config) { $this->config = $config; } public function trade(): TradeService { return new TradeService($this->config); } }

这种门面模式让调用链变得很直觉：$client->trade()->create($params)就是下单，$client->trade()->refund($params)就是退款。TradeService 内部持有 Config，每个方法执行时会拼装请求参数，用 curl 以 POST 方式发往 gateway.do，拿到响应 JSON 后再验签，验签通过才把业务结果返回给调用方。公共参数的产生被收敛在一个私有方法里，业务侧传进来的只有和业务强相关的字段，这对后面二次开发非常友好。

3.2 统一下单：从参数组装到返回验签

以当面付（条码支付）为例，TradeService 的 create 方法长这样：

<?php namespace Alipay\EasySDK\Payment; use Alipay\EasySDK\Security\Signer; class TradeService { private $config; public function __construct($config) { $this->config = $config; } public function create($outTradeNo, $totalAmount, $subject, $scene, $authCode = '') { $bizContent = [ 'out_trade_no' => $outTradeNo, 'total_amount' => $totalAmount, 'subject' => $subject, 'scene' => $scene, ]; if ($authCode !== '') { $bizContent['auth_code'] = $authCode; } $params = $this->buildRequestParams('alipay.trade.create', $bizContent); $params['sign'] = Signer::sign($params, $this->config['merchant_private_key']); $response = HttpClient::post( $this->config['gateway_host'] . '/gateway.do', $params ); return $this->parseResponse($response, 'alipay.trade.create'); } private function buildRequestParams($method, $bizContent) { return [ 'app_id' => $this->config['app_id'], 'method' => $method, 'format' => 'JSON', 'charset' => 'utf-8', 'sign_type' => 'RSA2', 'timestamp' => date('Y-m-d H:i:s'), 'version' => '1.0', 'biz_content' => json_encode($bizContent, JSON_UNESCAPED_UNICODE), ]; } private function parseResponse($responseBody, $method) { $data = json_decode($responseBody, true); $key = str_replace('.', '_', $method) . '_response'; $responseNode = $data[$key] ?? []; $sign = $data['sign'] ?? ''; if (!Signer::verifyResponse($responseNode, $sign, $this->config['alipay_public_key'])) { throw new \RuntimeException('支付宝响应验签失败'); } if (($responseNode['code'] ?? '') !== '10000') { throw new \RuntimeException($responseNode['sub_msg'] ?? '支付宝返回业务错误'); } return $responseNode; } }

说明几个关键参数。out_trade_no是商户侧订单号，必须保证唯一，退款时靠它找到原单；total_amount单位是元，字符串传值，不要传 float，否则后端不同语言浮点精度问题会让你欲哭无泪；scene这个参数在当面付里标识支付场景，bar_code表示用户出示付款码，auth_code就是用户付款码的 18 位数字。biz_content 必须是 JSON 字符串，并且不要做 HTML 转义，json_encode第二个参数加JSON_UNESCAPED_UNICODE就是为了防止中文变成\uXXXX，虽然网关能接受转义后的内容，但后续排查问题对账时你会看得非常痛苦。

响应解析这里有个易错点：alipay.trade.create对应的响应字段名是alipay_trade_create_response，把方法名里的点替换成下划线就能对上。验签时的待验签字符串用的是整个响应节点里的值，和请求签名是同一套算法。业务成功与否要看code字段，10000 表示成功，40004 一般是参数错误或者权限不足，遇到 40004 先去查传的参数是不是少了哪个必填项。

3.3 异步通知：验签、报文处理和业务回调

支付成功后，支付平台会以 POST 形式往商户配置的 notify_url 发送异步通知。通知内容和同步返回不一样，只有业务参数没有 biz_content，签名方式也是对整个参数集验签。NotifyHandler 把这块逻辑收拾干净了：

<?php namespace Alipay\EasySDK\Payment; use Alipay\EasySDK\Security\Signer; class NotifyHandler { public static function handle($postData, $alipayPublicKey) { if (!Signer::verify($postData, $alipayPublicKey)) { throw new \RuntimeException('异步通知验签失败'); } return $postData; } }

调用方拿到处理后的 POST 参数，再去检查trade_status字段。异步通知处理有个必须遵守的协议：验签通过并且业务处理成功后，你的接口必须返回纯文本 success；如果返回其他内容，平台会认为通知失败，然后按递增间隔重新通知，最多重试 8 次。很多新手要么把 response 回成 JSON 格式，要么干脆返回一个 HTML 页面，结果同一笔订单被重复通知处理了多次。所以在业务代码里，接收通知后第一件事是查订单当前状态，如果已经变成已支付，直接返回 success，保证处理动作的幂等。

3.4 退款与查询：金额单位与幂等设计

退款接口是售后链路的主干，TradeService 的 refund 方法在参数上比下单少，但坑更隐蔽：

public function refund($tradeNo, $outTradeNo, $refundAmount, $outRequestNo) { $bizContent = [ 'trade_no' => $tradeNo, 'out_trade_no' => $outTradeNo, 'refund_amount' => $refundAmount, 'out_request_no' => $outRequestNo, ]; $params = $this->buildRequestParams('alipay.trade.refund', $bizContent); $params['sign'] = Signer::sign($params, $this->config['merchant_private_key']); $response = HttpClient::post( $this->config['gateway_host'] . '/gateway.do', $params ); return $this->parseResponse($response, 'alipay.trade.refund'); }

trade_no是支付平台交易号，out_trade_no是商户订单号，两个至少传一个；refund_amount必须小于等于原订单金额，单位同样是元；out_request_no是退款请求号，用来标识一次退款请求，同一笔退款请求号的重复提交不会重复退款，这就是退款场景里的幂等设计。退款失败时返回码可能是 40004 或 10000 但是fund_change为 N，后者表示进入退款流程但资金没有实际变动，不要单纯看 code 判断成功，要连同fund_change一起判断。

这里也顺带说一下订单查询的写法。查询接口alipay.trade.query的 biz_content 只需要 trade_no 或 out_trade_no，返回的字段包含 trade_status、buyer_id、receipt_amount，轮询查支付结果时一般以 trade_status 为 TRADE_SUCCESS 作为终态。注意不要把 TRADE_FINISHED 当作成功终点，TRADE_FINISHED 是过了退款期限之后的终态，对需要做售后的订单来说反而晚了。

4. 落地接入：从 composer 引入到沙箱跑通第一笔支付

4.1 环境准备与沙箱账号

跑这个包需要的 PHP 版本最低在 7.2 左右，推荐 7.4 或 8.0+。必须安装的扩展是 openssl、curl，这两个在主流云服务器的 PHP 发行版里基本默认启用，可以用php -m | grep -E 'openssl|curl'确认。另外如果你用 Docker 跑 PHP 镜像，记得在 Dockerfile 里加上 openssl 和 curl 扩展，容器里的 php.ini 配置也要检查 extension 没有被注释。

支付对接需要三个关键的账号材料：应用 ID、应用私钥、支付宝公钥。沙箱环境在开放平台后台申请即可，里面会给你一套独立的应用 ID 和密钥，和线上完全隔离。拿到材料后，建议立刻把它们写进.env，而不是配置文件里写死：

ALIPAY_APP_ID=202100xxxxxxxxxxxx ALIPAY_PRIVATE_KEY=-----BEGIN PRIVATE KEY-----\n...\n-----END PRIVATE KEY-----\n ALIPAY_PUBLIC_KEY=-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----\n ALIPAY_GATEWAY_HOST=openapi.alipaydev.com

注意 .env 里多行私钥的写法，换行符要用字面量\n而不是真实换行，否则一些 dotenv 解析库会把它截断。我在这里吃过一次亏：把私钥按原样复制进 .env，结果解析出来的字符串没有换行，openssl_sign 一直报无法解析私钥，折腾了半小时才反应过来是换行符被吞了。

4.2 composer 引入与客户端初始化

在项目根目录执行命令，然后确认 autoload 生效。如果是内网环境，记得先把 composer 镜像源配好，否则拉包速度会让人怀疑人生。

composer require alipay/easysdk-php composer install

安装完之后，在项目入口文件写一个最简初始化。我的习惯是在服务容器里注册好 Client，避免每个 controller 都 new 一遍：

<?php require __DIR__ . '/vendor/autoload.php'; use Alipay\EasySDK\Client; use Alipay\EasySDK\Config; $config = new Config([ 'app_id' => getenv('ALIPAY_APP_ID'), 'merchant_private_key' => getenv('ALIPAY_PRIVATE_KEY'), 'alipay_public_key' => getenv('ALIPAY_PUBLIC_KEY'), 'gateway_host' => getenv('ALIPAY_GATEWAY_HOST'), ]); $client = new Client($config);

配置对象创建完成后，整个客户端的生命周期就可以交给容器管理。如果项目用的框架自己有配置中心，把数组换成框架的 config 方法也一样。

4.3 最小支付入口与通知接收页

支付入口路由接收前端传来的订单号和金额，调用 TradeService 创建订单。这里展示的是一个明确的控制面逻辑：业务侧只传订单号和金额，其他的细节由 SDK 消化：

public function pay(Request $request) { $orderNo = $request->input('order_no'); $amount = $request->input('amount'); $result = $this->client->trade()->create( $orderNo, $amount, '模拟商品', 'bar_code', $request->input('auth_code') ); return response()->json(['code' => 0, 'data' => $result]); }

通知接收页是 notify_url 指向的地址，不需要做任何鉴权，平台只会用 POST 请求打过来。业务处理完必须 echo 纯文本 success：

public function notify(Request $request) { try { $data = NotifyHandler::handle($request->post(), getenv('ALIPAY_PUBLIC_KEY')); if (($data['trade_status'] ?? '') !== 'TRADE_SUCCESS') { return 'success'; } // 更新订单状态、触发履约 $this->orderService->markPaid($data['out_trade_no'], $data['trade_no']); } catch (\Throwable $e) { return 'fail'; } return 'success'; }

注意 return 'success' 的内容不能带空格、不能带前后换行，header 也只能是 text/html 或者不加自定义头，否则会被平台判定为非成功响应，触发重试。

4.4 沙箱端到端验证

沙箱环境里可以用官方沙箱客户端扫码支付，也可以用沙箱账号模拟付款。验证步骤按这个顺序走：

第一，调创建订单接口，确认返回 code 为 10000，同时返回的 trade_no 是 64 位以内纯数字，说明请求链路通。第二，用沙箱扫码完成支付，再调查询接口确认订单状态变成 TRADE_SUCCESS。第三，等异步通知到达本地，确认验签通过并更新状态。第四，触发一笔小额退款，确认 fund_change 字段变化。到这里，整条链路就闭环了。

如果查询接口能通但异步通知一直收不到，优先检查两件事：notify_url 必须是外网可访问的地址，沙箱回调不会去请求 localhost；再看看开放平台后台的应用配置里是不是漏填了接口加签密钥。

5. 避坑指南：alipay-easysdk-php 接入中容易翻车的 5 个细节

5.1 私钥格式不对导致全部请求签名失败

现象：所有接口调用都返回「应用签名验证失败」，或者 curl 请求根本没发出去，openssl_sign 返回 false。

原因：开放平台生成的私钥是 PKCS8 格式，文件开头是-----BEGIN PRIVATE KEY-----，而很多工具默认生成的 PKCS1 格式开头是-----BEGIN RSA PRIVATE KEY-----。PHP 的 openssl_sign 解析 PKCS1 会静默失败，不会抛异常，但签名结果是空字符串，所有请求自然就挂了。

解决：检查私钥字符串第一行，如果是 RSA PRIVATE KEY，需要先转换。命令行用openssl pkcs8 -topk8 -inform PEM -in rsa_private_key.pem -outform PEM -nocrypt转成 PKCS8，再填进配置。

5.2 异步通知重复到达导致的重复入账

现象：同一笔订单的 notify 请求收到很多次，订单表里出现重复流水。

原因：平台异步通知本身有重试机制，也可能因为你的 notify 接口返回了非 success 内容而触发服务端重发。重试频率可以递增到几小时一次，哪怕业务代码里明明处理成功了。

解决：数据库层面给 out_trade_no 建唯一索引，业务代码里先查状态再更新，更新语句带 where status = 'pending' 当作乐观锁。通知处理函数里先判断订单是否存在，已经支付过的直接返回 success。

5.3 金额用 float 导致账单对不上

现象：支付成功后商户后台的金额和平台账单相差几分钱。

原因：PHP 里 float 的精度问题，比如 0.1 + 0.2 不等于 0.3。订单金额如果从数据库查出后转成 float 传入 SDK，传输过程中精度丢失，到了网关那边金额就对不上了，严重的会直接提示金额超限。

解决：所有金额在进入 SDK 前保持字符串类型，数据库里用 DECIMAL(10,2) 存储，PHP 里可以用 number_format 保留两位再强转字符串返回。前后端接口传参时也只接受字符串金额，类型校验加上金额范围，能挡住一批手滑的调用。

5.4 biz_content 里出现转义导致支付宝无法识别

现象：下单返回 40004 invalid args，查看网关日志发现 biz_content 里的中文变成了\uXXXX。

原因：PHP 的 json_encode 默认会把非 ASCII 字符转成\uXXXX，网关部分接口能接受，部分接口会直接解析失败，尤其当业务参数里带商品标题、收货人姓名这些中文时特别明显。

解决：json_encode 第二个参数传JSON_UNESCAPED_UNICODE，确保中文保持原样输出。如果遇到回调里的内容需要二次拼接进 biz_content，也要用json_encode($data, JSON_UNESCAPED_UNICODE)后再提交，不要手动拼 JSON 字符串。

5.5 配置里的公钥填得不对导致验签失败

现象：下单接口能通，但响应解析一直报验签失败；或者某些接口正常，某些接口又不正常。

原因：商户侧的配置有两个公钥概念容易混。应用公钥是你自己生成的密钥对里的公钥，用于给平台验证你的请求；支付宝公钥是平台侧生成的公钥，用于你验证平台的响应和通知。SDK 的alipay_public_key配置项必须填支付宝公钥，很多同学把应用公钥顺手粘贴进去，导致验签永远失败。

解决：去开放平台后台的「接口加签方式」页面复制支付宝公钥，重新配置后重启进程。如果开了证书模式，则需要用公钥证书而不是字符串公钥，这一点在使用新老接口时容易踩，别把两种模式搞混。

6. 二次开发思路：给这个包扩展一个查账单接口的改造过程

如果你想在这个包的基础上加一个新接口，比如「查询账单下载地址」alipay.data.dataservice.bill.downloadurl.query，思路其实很简单：不碰 Signer、Config 这些基础设施，只照着 TradeService 的模式添加一个方法。

第一步，确认资金账单类型 bill_type，比如 trade 或 signcustomer；第二步，把上报参数写进 biz_content，调用 buildRequestParams 生成公共参数；第三步，签名、发请求、解析结果。核心代码改动只有两处：

public function downloadUrl(string $billType, string $billDate): array { $bizContent = [ 'bill_type' => $billType, 'bill_date' => $billDate, ]; $params = $this->buildRequestParams('alipay.data.dataservice.bill.downloadurl.query', $bizContent); $params['sign'] = Signer::sign($params, $this->config['merchant_private_key']); $response = HttpClient::post($this->config['gateway_host'] . '/gateway.do', $params); return $this->parseResponse($response, 'alipay.data.dataservice.bill.downloadurl.query'); }

如果不想在 TradeService 里堆太多方法，也可以拆成 BillService，单独负责账单这一类接口。真正要区分的是接口的响应格式：有的接口返回alipay_xxx_response里有 code、sub_code 嵌套，有的直接返回业务字段；parseResponse 已经把通用逻辑收拢，新增接口时只需要保证$key从 method 换算出对应响应节点名。这个模式对支付宝开放平台几十个交易类接口几乎都适用，步骤永远是「确定 method → 组装 biz_content → 签名 → 发请求 → 验签解析」。

如果要自己维护这个包，建议把改动后的包发到公司内部的 composer 仓库，业务项目通过版本约束引用，避免每个项目都 fork 一份源码。版本管理上遵守语义化版本：修 bug 用 patch，加接口用 minor，签名或请求协议变动才升 major。我从第一次把支付 SDK 揉进业务代码、到后来专门拆出独立包给多个项目共用，最大的收获是：支付接入的真正复杂度集中在签名、验签、通知幂等三件事上，而这三件事恰好是拆包之后最容易收敛的部分。从那以后我每次接新项目都强制走一遍「先拆依赖再写业务」这个流程，基本没再因为支付接入加班到半夜。希望帮到你。

本文还有配套的精品资源，点击获取