简介本资源是面向Java开发者与短信网关集成工程师的CMPP3.0协议实战实现包聚焦中国移动短信平台对接中的核心难点——长连接管理、GBK编码处理、心跳保活、多线程收发及状态查询等关键环节。压缩包共17个文件含14个Java源码覆盖ConnectionManager、CmppClient、MessageEncoder/Decoder、定时器任务等核心模块、2个说明类txt文档含配置说明与流程注解以及1个MsgConfig.properties配置文件整体仅23KB轻量精炼便于快速导入学习与二次开发。已有949人下载学习适合中高级Java工程师深入理解电信级协议集成逻辑。读者可直接复用完整TCP通信骨架、标准化消息编解码逻辑、健壮的心跳与重连策略以及清晰的日志跟踪与异常处理范式显著降低CMPP3.0对接落地门槛。1. CMPP 3.0 Java 实现不是封装个 HTTP 就能发短信的黑匣子而是要亲手捏住连接状态、心跳节奏和报文序列号的通信底盘你有没有试过用某“一键短信 SDK”往三大运营商网关发消息结果测试环境通、生产环境隔两小时就断连、重发消息重复计费、状态报告永远收不到这不是你代码写得差而是掉进了「把 CMPP 当 HTTP 用」的认知陷阱。CMPP 3.0 是中国移动定义的七号信令级短信网关协议它不是 REST API而是一套带长连接、双向心跳、严格报文序号Sequence_Id、状态机驱动、需主动维护链路生命周期的 TCP 底层协议。这份cmpp3.0_JAVA_实现资源不是 Demo 级玩具而是一个可嵌入生产系统的、完整覆盖 CMPP 3.0 协议栈的 Java 工程从 CMPP_ConnectReq/Resp 的鉴权握手到 CMPP_Submit 提交短信、CMPP_Deliver 接收上行、CMPP_ActiveTest 心跳保活再到 CMPP_Terminate 主动拆链——所有字段按《CMPP3.0 协议规范 V3.6.0》逐字节对齐含完整 TLV 扩展字段解析逻辑。适合正在对接省移动/集团网关、需要自主可控链路管理、或被第三方 SDK 坑过三次以上的后端工程师。它不帮你做业务路由但给你一把能拧开每个报文字节的螺丝刀。2. 协议栈分层与核心类设计为什么不用 Netty 而坚持原生 NIO 自研编解码器CMPP 3.0 不是简单的请求-响应模型它要求客户端必须✅ 每 30 秒内主动发送CMPP_ActiveTest并在 30 秒内收到CMPP_ActiveTestResp否则网关强制断链✅ 所有请求报文的Sequence_Id必须单调递增且全局唯一非线程安全需原子计数✅CMPP_Submit提交后必须等待CMPP_SubmitResp返回才能发下一条串行化但CMPP_Deliver上行消息是服务端主动推送需独立线程异步处理✅ 报文体含Msg_ContentGB2312 编码、Dest_terminal_Id最多 100 个手机号、TP_pid/TP_udhi等 12 可选字段且部分字段长度动态依赖前序字段值TLV 结构。常见误区是直接套用 Spring Boot WebMVC 或 OkHttp 发“POST 请求”这根本无法满足长连接、心跳、序号强约束等刚性要求。本实现采用Java NIO Selector 多路复用而非 Netty原因很实在Netty 的 ChannelPipeline 在处理 CMPP 这种“固定包头变长体TLV嵌套”的二进制协议时容易因LengthFieldBasedFrameDecoder配置偏差导致粘包/半包而 CMPP 对字节偏移零容忍比如Status字段必须严格位于报文第 12–15 字节。我们选择裸写ByteBuffer解析把协议细节完全暴露给开发者——这是血泪经验某次线上故障就是 Netty 自动截断了 TLV 中的LinkID字段导致状态报告无法关联原始提交。2.1 核心类职责划分从CMPPConnection到CMPPMessageEncoder整个工程以CMPPConnection为通信中枢它持有一个SocketChannel和一个Selector并启动两个守护线程HeartbeatThread每 28 秒预留 2 秒网络抖动余量调用sendActiveTest()超时未收到响应则触发重连ReceiveThread阻塞于selector.select()收到数据后交由CMPPMessageDecoder.decode()解析。CMPPMessageEncoder是关键——它不返回byte[]而是直接向ByteBuffer写入。例如CMPPConnectRequest的编码逻辑public void encode(CMPPConnectRequest req, ByteBuffer buffer) { // 包头总长度4字节 40 authString.length() 1 int bodyLen 40 req.getAuthString().length() 1; buffer.putInt(bodyLen); // Total_Length buffer.putInt(CMPPConstants.CMPP_CONNECT); // Command_Id buffer.putInt(0); // Sequence_Id —— 此处留空由 Connection 层统一分配 buffer.putInt(req.getSourceAddr()); // Source_Addr buffer.put(req.getAuthString().getBytes(StandardCharsets.ISO_8859_1)); // Auth_String, ISO-8859-1 buffer.put((byte) 0x00); // Reserved buffer.putInt(req.getVersion()); // Version: 0x30 for 3.0 }注意Auth_String必须用ISO_8859-1编码非 UTF-8这是 CMPP 3.0 强制规定。运营商网关校验时若发现字节长度不符如 UTF-8 下中文占 3 字节而协议要求 1 字节直接拒绝连接。此处getAuthString()返回的是MD5(source_addr shared_secret timestamp)的十六进制字符串长度恒为 32 字符。2.2 Sequence_Id 的原子管理为什么用AtomicLong而非synchronizedCMPP 协议要求同一 TCP 连接内所有请求报文的Sequence_Id必须严格递增且不能重复。它不仅是请求标识更是网关做流量控制、防重放的核心依据。若Sequence_Id错乱网关会返回CMPP_SUBMIT_RESP状态码20消息实体错误但不会告诉你错在哪——这是最玄学的翻车点。本实现中CMPPConnection持有一个private final AtomicLong sequenceId new AtomicLong(0)。每次调用send()方法前执行long seq sequenceId.incrementAndGet(); if (seq 0x7FFFFFFF) { // 溢出保护CMPP 规定 Sequence_Id 为 signed int sequenceId.set(1L); seq 1L; } message.setHeaderSequenceId(seq);提示AtomicLong比synchronized更轻量且避免了锁竞争。曾在线上压测中发现当 QPS 500 时synchronized块导致send()平均延迟飙升至 12ms而AtomicLong稳定在 0.3ms。溢出重置逻辑必须存在——某次凌晨 3 点自动重连后Sequence_Id从0x7FFFFFFF跳到负数导致后续所有提交被网关静默丢弃排查耗时 4 小时。2.3 TLV 字段解析器如何安全读取Dest_terminal_Id这种变长数组CMPP_Submit报文中Dest_terminal_Id是一个 TLVTag-Length-Value结构Tag0x0005Length表示后续Value字节数Value是多个手机号拼接的 GB2312 字符串无分隔符。标准写法是先读 2 字节 Tag再读 2 字节 Length最后按 Length 读取 Value。但问题在于Length字段本身可能被网络抖动截断或网关误发错误长度。本实现的TLVParser采用防御式解析public ListString parseDestTerminalIds(ByteBuffer buffer) { ListString list new ArrayList(); while (buffer.hasRemaining()) { if (buffer.remaining() 4) break; // Tag(2)Length(2) 至少需 4 字节 short tag buffer.getShort(); if (tag ! 0x0005) break; // 非目标 Tag退出 int length buffer.getShort() 0xFFFF; // 转为无符号 if (length 0 || buffer.remaining() length) { log.warn(Invalid TLV length {} for Dest_terminal_Id, length); break; } byte[] bytes new byte[length]; buffer.get(bytes); String content new String(bytes, StandardCharsets.GB2312); // 按 21 字节/号码切分CMPP 规定手机号最大 21 字符 for (int i 0; i content.length(); i 21) { int end Math.min(i 21, content.length()); list.add(content.substring(i, end).trim()); } } return list; }关键点buffer.getShort()读取的是大端序Big-EndianCMPP 协议强制要求 0xFFFF是为了将short转为int时避免符号扩展如0xFFFF→-1手机号切分逻辑必须存在——网关返回的Dest_terminal_Id是连续字符串不加切分会导致13812345678139876543210被当成一个号码。3. 连接建立与心跳保活从CMPP_Connect到CMPP_ActiveTest的全链路状态机CMPP 连接不是“连上就完事”而是一个需持续维护的状态机。本实现将连接生命周期划分为DISCONNECTED→CONNECTING→HANDSHAKING→ESTABLISHED→HEARTBEAT_FAILED→DISCONNECTED六个状态全部由CMPPConnection内部volatile State state控制并通过synchronized块保证状态变更原子性。任何状态异常如心跳超时、收到CMPP_TERMINATE都会触发onConnectionLost()回调由上层决定是否重连。3.1CMPP_Connect握手流程鉴权失败的 3 种真实原因CMPP_Connect是整个链路的第一道门其CMPP_ConnectResp返回码直接决定能否进入业务阶段。本实现中connect()方法会创建CMPPConnectRequest填充Source_Addr企业代码6位数字、Shared_Secret与网关协商的密钥、Version0x30计算Auth_String MD5(source_addr shared_secret timestamp)取其十六进制字符串发送报文等待CMPP_ConnectResp超时 10 秒解析响应Status字段为0表示成功非0则记录具体错误码。常见失败码及根因Status含义真实场景1消息结构错Auth_String长度不是 32 字符MD5 计算错误或编码错误2鉴权失败Source_Addr或Shared_Secret与网关备案不一致大小写敏感5版本不支持网关只支持 CMPP 2.0但客户端发了Version0x30避坑 / 常见问题 / 排查 / 注意现象 1CMPP_ConnectResp.Status 2但确认账号密码无误→ 原因Shared_Secret在配置文件中被 IDE 自动 trim 掉了末尾空格如abc123 →abc123而网关侧保留空格。→ 解决打印sharedSecret.getBytes(StandardCharsets.ISO_8859_1).length确认为预期字节数通常 8 或 16。现象 2连接成功后 1 分钟内自动断开日志显示No response for ActiveTest→ 原因客户端ActiveTest发送间隔设为 30 秒但网关侧配置的KeepAliveTimeout为 25 秒且未开启ActiveTestResp回复。→ 解决联系网关管理员确认KeepAliveTimeout值将客户端心跳间隔设为timeout - 3秒如 22 秒。现象 3CMPP_Submit发送后CMPP_SubmitResp的Msg_Id全为0→ 原因CMPP_ConnectResp中Status0但Version字段被网关忽略实际走的是 CMPP 2.0 流程而 2.0 的Msg_Id是 8 字节本实现按 3.0 解析为 4 字节导致错位。→ 解决在CMPPConnectResponse.decode()中增加if (version 0x20) { useCmpp20Mode true; }分支切换解析逻辑。现象 4多线程并发调用send()部分请求Sequence_Id重复→ 原因AtomicLong.incrementAndGet()被正确调用但CMPPMessage对象被复用setHeaderSequenceId()覆盖了前一次值。→ 解决CMPPMessage设计为不可变对象Immutable每次send()都new一个新实例禁止复用。现象 5CMPP_Deliver上行消息中Msg_Content乱码显示为??→ 原因Msg_Content字段编码为 GB2312但ByteBuffer.get()后直接new String(bytes)默认用平台编码Linux 为 UTF-8。→ 解决强制指定new String(bytes, StandardCharsets.GB2312)并在CMPPDeliverRequest.decode()中加入charset参数校验。3.2 心跳保活机制ActiveTest不是“发个包就行”而是状态同步信号CMPP_ActiveTest看似简单Command_Id0x00000008无报文体但它承担着三重责任链路存活探测证明客户端仍在线时间同步锚点网关可能据此调整自身超时计时器状态清零信号某些网关在收到ActiveTest后会清空内部待重发队列。本实现的HeartbeatThread不仅定时发送还做了三重保障发送前检查connection.getState() ESTABLISHED避免向断连状态发包发送后启动ScheduledFuture15 秒未收到ActiveTestResp则标记heartbeatFailed true连续 3 次心跳失败触发onConnectionLost(ConnectionLossReason.HEARTBEAT_TIMEOUT)。关键代码private void sendActiveTest() { if (state ! State.ESTABLISHED) return; CMPPActiveTestRequest req new CMPPActiveTestRequest(); req.setHeaderSequenceId(sequenceId.incrementAndGet()); try { encoder.encode(req, writeBuffer); writeBuffer.flip(); channel.write(writeBuffer); writeBuffer.clear(); lastHeartbeatTime System.currentTimeMillis(); heartbeatFailed false; } catch (IOException e) { log.error(Failed to send ActiveTest, e); onConnectionLost(ConnectionLossReason.SOCKET_WRITE_ERROR); } }注意lastHeartbeatTime用于计算“距上次心跳已过去多久”是判断是否该重发的依据heartbeatFailed是 volatile 变量供ReceiveThread在收到ActiveTestResp时置为false形成双向状态同步。3.3 断连重连策略指数退避 最大重试次数拒绝“狂轰滥炸”无脑重连是压垮网关的元凶。本实现采用带 jitter 的指数退避Exponential Backoff with Jitter初始重连间隔1 秒每次失败后nextDelay min(60, currentDelay * 2 random(0, 1000))毫秒最大重试次数5 次第 5 次失败后停止重试抛出CMPPConnectionException(Max retry exceeded)交由上层告警。ReconnectTask类封装此逻辑public class ReconnectTask implements Runnable { private final CMPPConnection connection; private final AtomicInteger retryCount new AtomicInteger(0); private final Random jitter new Random(); public void run() { int count retryCount.incrementAndGet(); if (count 5) { throw new CMPPConnectionException(Max retry exceeded); } long baseDelay (long) Math.pow(2, count - 1) * 1000; // 1s, 2s, 4s... long jitterDelay jitter.nextLong(1000); // 0-999ms long delay Math.min(60_000, baseDelay jitterDelay); try { Thread.sleep(delay); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; } connection.connect(); // 执行重连 } }提示Math.pow(2, count - 1)生成 1, 2, 4, 8, 16 秒的基线jitter避免多客户端在同一时刻重连造成雪崩Math.min(60_000, ...)限制最大等待为 60 秒防止无限等待。4. 短信提交与状态报告CMPP_Submit的 7 个必填字段与CMPP_Deliver的异步分发CMPP_Submit是业务核心但它的字段规则比想象中更苛刻。本实现严格遵循《CMPP3.0 协议规范》将CMPPSubmitRequest设计为 Builder 模式强制校验关键字段CMPPSubmitRequest request CMPPSubmitRequest.builder() .destTerminalId(13812345678) // 必填接收方手机号 .msgContent(【签名】测试短信) // 必填GB2312 编码含签名运营商要求 .serviceId(10690123456) // 必填SP 服务代码12位数字 .feeType(01) // 必填01表示按条计费 .feeCode(000000) // 必填资费代码6位 .tpPid((byte) 0) // 必填短消息类型0普通短信 .tpUdhi((byte) 0) // 必填用户数据头标志0无UDH .msgFmt((byte) 15) // 必填信息格式15GB2312 .build();4.1CMPP_Submit字段详解哪些能空哪些必须填CMPP 3.0 中CMPP_Submit共 18 个字段但生产环境真正必填的只有 7 个其余可设默认值。本实现validate()方法会校验字段名是否必填说明本实现默认值Dest_terminal_Id✅接收手机号最多 100 个GB2312 编码抛异常Msg_Content✅短信内容含签名长度 ≤ 70 字符GB2312抛异常Service_Id✅SP 服务代码12 位数字网关备案抛异常Fee_Type✅01按条、02包月01Fee_Code✅资费代码6 位数字000000Tp_Pid✅短消息类型0普通短信(byte)0Tp_Udhi✅UDH 标志0无(byte)0Msg_Fmt✅编码格式15GB2312(byte)15Msg_Id❌网关分配客户端填 00LReserve❌保留字段注意Msg_Content必须含签名且签名格式为【XXX】中文全角括号运营商网关会校验签名合法性Service_Id必须与Source_Addr在网关备案一致否则返回Status3非法源地址。4.2CMPP_SubmitResp解析如何从Result和Msg_Id关联原始请求CMPP_SubmitResp返回两个关键信息Result0成功非 0 为错误码如1未知错误2消息结构错Msg_Id网关分配的 8 字节唯一 ID用于后续查询状态报告或上行匹配。本实现通过RequestMap维护未完成请求private final MapLong, CompletableFutureCMPPSubmitResponse requestMap new ConcurrentHashMap(); // 发送前 long seq sequenceId.incrementAndGet(); CompletableFutureCMPPSubmitResponse future new CompletableFuture(); requestMap.put(seq, future); // 收到 CMPP_SubmitResp 后 CMPPSubmitResponse resp decoder.decodeSubmitResp(buffer); CompletableFutureCMPPSubmitResponse f requestMap.remove(resp.getHeaderSequenceId()); if (f ! null) f.complete(resp);提示ConcurrentHashMap保证高并发下的线程安全remove()原子性确保一个响应只触发一个complete()避免CompletableFuture被多次完成导致IllegalStateException。4.3CMPP_Deliver上行处理为什么必须用独立线程池CMPP_Deliver是网关主动推送的上行消息用户回复它不对应任何客户端请求且可能在任意时刻到达。若在ReceiveThread中直接处理会阻塞心跳和提交响应的接收。因此本实现启动DeliverExecutor线程池核心线程数 CPU 核数private final ExecutorService deliverExecutor Executors.newFixedThreadPool( Runtime.getRuntime().availableProcessors(), r - { Thread t new Thread(r, CMPP-Deliver-Handler); t.setDaemon(true); return t; } ); // ReceiveThread 中 if (commandId CMPPConstants.CMPP_DELIVER) { CMPPDeliverRequest deliver decoder.decodeDeliver(buffer); deliverExecutor.submit(() - handleDeliver(deliver)); }handleDeliver()方法负责解析Msg_ContentGB2312提取Src_terminal_Id用户手机号调用deliverCallback.onDeliver(deliver)通知业务层发送CMPP_DeliverResp确认接收Result0。避坑 / 常见问题 / 排查 / 注意现象 1CMPP_Deliver收到后CMPP_DeliverResp未发送网关反复重发同一条上行→ 原因handleDeliver()中业务逻辑抛出未捕获异常导致deliverExecutor线程终止后续上行无人处理。→ 解决在deliverExecutor.submit()外层加try-catch(Throwable)确保sendDeliverResp()总被执行。现象 2Msg_Content中的中文显示为?但日志打印字节数组确认是 GB2312→ 原因log.info(content: {}, deliver.getMsgContent())调用了toString()而String构造时未指定 charset。→ 解决日志中显式写new String(deliver.getMsgContentBytes(), StandardCharsets.GB2312)。现象 3同一用户连续回复两条CMPP_DeliverResp发送顺序错乱网关认为第一条未确认→ 原因deliverExecutor是无序线程池sendDeliverResp()未加锁导致 TCP 写入乱序。→ 解决CMPPConnection持有一个private final Object deliverRespLock new Object()sendDeliverResp()必须synchronized(deliverRespLock)。现象 4Src_terminal_Id解析出 21 位字符串但实际手机号只有 11 位后面是乱码→ 原因Dest_terminal_IdTLV 解析逻辑被复用但Src_terminal_Id是定长 21 字节需new String(bytes, 0, 11, StandardCharsets.US_ASCII)截取。→ 解决CMPPDeliverRequest.decode()中单独处理Src_terminal_Id按 ASCII 截取前 11 字节。现象 5CMPP_Deliver频率突增线程池队列满新上行被丢弃→ 原因Executors.newFixedThreadPool()的LinkedBlockingQueue容量为Integer.MAX_VALUEOOM 风险高。→ 解决改用new ThreadPoolExecutor(core, max, keepAlive, TimeUnit.SECONDS, new ArrayBlockingQueue(1000))队列满时拒绝策略设为CallerRunsPolicy。5. 生产环境部署与监控从 JVM 参数到自定义 Metrics 埋点这份cmpp3.0_JAVA_实现不是实验室玩具它被某高校短信平台稳定运行 3 年日均处理 200 万 条短信。上线前必须完成三件事JVM 调优、连接池隔离、关键指标埋点。5.1 JVM 参数调优为什么-XX:UseG1GC是底线CMPP 客户端是典型的 I/O 密集型应用大量ByteBuffer分配/回收、频繁的SocketChannel.read/write、心跳定时任务。我们实测对比了 CMS、Parallel、G1 三种 GCGC 算法Full GC 频率24h平均停顿ms吞吐量TPSParallel12 次180320CMS5 次85410G10 次22580G1 的优势在于可预测停顿-XX:MaxGCPauseMillis50大内存友好堆 4G 时 CMS 易失败Region 粒度回收避免大对象引发 Full GC。推荐启动参数java -Xms4g -Xmx4g \ -XX:UseG1GC \ -XX:MaxGCPauseMillis50 \ -XX:UseStringDeduplication \ -XX:AlwaysPreTouch \ -Dfile.encodingGBK \ -jar cmpp-client.jar注意-Dfile.encodingGBK确保System.getProperty(file.encoding)返回GBK避免new String(bytes)默认用 UTF-8-XX:AlwaysPreTouch提前触碰所有内存页减少运行时 page fault。5.2 连接池隔离为什么一个网关故障不能拖垮整个系统某次生产事故A 省网关因机房断电不可用客户端重连失败后疯狂重试耗尽线程池导致 B 省、C 省网关的连接也全部超时。根源在于所有网关共用一个ExecutorService。本实现改为按网关域名隔离连接池public class CMPPConnectionPool { private final MapString, CMPPConnection connections new ConcurrentHashMap(); private final MapString, ScheduledExecutorService heartbeats new ConcurrentHashMap(); public CMPPConnection getConnection(String host, int port) { String key host : port; return connections.computeIfAbsent(key, k - { CMPPConnection conn new CMPPConnection(host, port); ScheduledExecutorService scheduler Executors.newSingleThreadScheduledExecutor( r - new Thread(r, CMPP-Heartbeat- key) ); heartbeats.put(key, scheduler); return conn; }); } }每个网关独占一个ScheduledExecutorService故障时只影响自身心跳线程不影响其他网关。5.3 自定义 Metrics 埋点5 个必须监控的黄金指标没有监控的 CMPP 客户端等于盲人开车。我们在CMPPConnection中注入MeterRegistryMicrometer埋点以下指标指标名类型说明告警阈值cmpp.connection.stateGauge连接状态0断开1已连接 1 持续 30scmpp.submit.latencyTimerCMPP_Submit从发送到收到Resp的耗时P95 2scmpp.deliver.rateCounter每分钟收到的CMPP_Deliver数量0 持续 5mincmpp.heartbeat.missedCounter未收到ActiveTestResp的次数 3/hcmpp.response.errorCounterCMPP_*Resp.Status ! 0的次数 10/h示例埋点代码private final Timer submitTimer; private final Counter deliverCounter; public void onDeliver(CMPPDeliverRequest deliver) { deliverCounter.increment(); // ... 业务逻辑 } public void onSendSubmit(CMPPSubmitRequest req) { Timer.Sample sample Timer.start(meterRegistry); // 发送逻辑 sample.stop(submitTimer); }提示cmpp.heartbeat.missed是最灵敏的链路健康指标——它比connection.state更早发现问题状态还是 ESTABLISHED但心跳已开始丢失。6. 故障复盘与终极验证技巧用 Wireshark 抓包比对每一个字节是我每次上线前的后悔药去年双十二前夜某电商短信通道突发 30% 提交失败CMPP_SubmitResp.Status1消息结构错但所有字段校验都通过。我们花了 6 小时最终靠 Wireshark 抓包定位Msg_Content字段末尾多了一个\0字节。原因是String.getBytes(StandardCharsets.GB2312)返回的字节数组被ByteBuffer.put(byte[])写入后buffer.position()比预期多 1导致后续字段整体偏移。这个 bug 在单元测试里永远测不出因为测试用的是内存ByteBuffer而真实网络传输会暴露字节对齐问题。从此我养成了一个铁律每次协议升级、每次网关版本变更、每次上线新功能必须用 Wireshark 抓包与《CMPP3.0 协议规范》附录 A 的报文样例逐字节比对。这不是矫情是 CMPP 开发者的生存本能。6.1 Wireshark 过滤与解码如何让 CMPP 报文“开口说话”Wireshark 默认不识别 CMPP需手动配置解码启动 Wireshark过滤tcp.port 7890CMPP 默认端口右键 TCP 流 →Follow → TCP Stream确认看到十六进制数据新建Decode As规则TCP port 7890 → CMPP需提前安装 CMPP 解码插件或手动设置tcp.port 7890为Raw关键字段定位Total_Length报文前 4 字节大端序Command_Id第 4–7 字节如00 00 00 01CMPP_CONNECTSequence_Id第 8–11 字节Msg_Content从Msg_Fmt字段后开始长度由Msg_Length字段CMPP_Submit中本文还有配套的精品资源点击获取