尧图网页设计 
简介IEEE 802.1AS-2020.pdf 是 IEEE 官方发布的局域网时间同步标准文档面向从事 TSN时间敏感网络协议研究、工业自动化与车载以太网开发的工程师及高校师生用于解决分布式系统中时钟同步、时序传输与恢复等核心问题。资源包内仅含 1 个 PDF 文件大小约 6.2MB完整收录标准正文涵盖同步时间传输、最佳主时钟选择、相位与频率偏差指示等协议、过程及管理对象定义并涉及 Grandmaster Clock、PTP 实例、时间感知系统等关键术语。该标准是 TSN 协议族中时序同步的基础规范读者可据此深入理解时钟同步机制、时序信息封装与重传、管理对象配置等知识点为协议实现、设备开发与测试验证提供权威依据。目前已有 475 人学习下载适合需要查阅原始标准条款、对照协议细节进行技术攻关的读者。1. 从一份 802.1AS-2020 文档说起TSN 时间同步到底卡在哪做车载以太网、工业实时控制或者音视频桥接的兄弟大概率都经历过这种场面交换机配置全对PTP 报文也抓到了但示波器上两路时钟就是差那么几百纳秒反复重启偶尔又能对上。这种玄学问题十有八九是没把 IEEE 802.1AS 的细节吃透。802.1AS 是 TSN时间敏感网络里负责时间同步的核心标准2020 版相比 2011 版在 gPTPgeneralized PTP基础上补了大量工程细节比如多域支持、更细的时钟质量分级、以及和 802.1Qbv 门控调度的配合。这份 PDF 就是标准原文不是教程但它是所有 TSN 时间同步实现的最终依据。适合谁看写交换机固件的、做域控制器时间同步的、调 AVB 音频链路的以及被 gPTP 收敛问题折磨过的测试工程师。它解决的不是“怎么装软件”而是“为什么你的时间同步不收敛、抖动大、主从切换慢”。2. 802.1AS-2020 的时钟模型与报文机制先搞懂 BMCA 和 Sync 怎么走2.1 为什么 2020 版把时钟质量拆得更细2011 版的 802.1AS 用一套相对简单的优先级向量选主时钟到了 2020 版标准把 clockClass、clockAccuracy、offsetScaledLogVariance 这几个参数的语义写得更死。原因很直接车载和工业场景里一个域里可能同时存在 GPS 驯服时钟、晶振保持时钟、以及从网络恢复的普通时钟如果不把质量等级分清楚BMCABest Master Clock Algorithm就会选出一个“看起来优先级高但实际抖动大”的节点当主时钟整个域跟着遭殃。标准里把 clockClass 从 6 到 255 分了多档常见工程取值6 表示主参考如 GPS 锁定7 表示保持模式52 表示普通晶振。clockAccuracy 用 0x20 到 0x31 表示从 25ns 到 10s 的精度范围。offsetScaledLogVariance 则描述抖动。这三个值一起塞进 Announce 报文BMCA 按优先级向量比较。我一般会在代码里把这三个参数做成可配置而不是硬编码因为不同硬件方案差别太大。提示如果你的设备没有 GPSclockClass 不要填 6否则一旦 GPS 失锁BMCA 不会自动降级整个域会跟着漂。2.2 Sync/Follow_Up 与 P2P 延迟测量的报文交互802.1AS 的时间同步靠三组报文Announce 选主、Sync/Follow_Up 传时间、Pdelay_Req/Pdelay_Resp/Pdelay_Resp_Follow_Up 测链路延迟。2020 版明确要求使用 P2PPeer-to-Peer延迟测量机制而不是端到端的 Delay_Req。这意味着每个端口都要和邻居端口独立测延迟而不是只跟主时钟测。一次完整的同步过程大致是主时钟发 Sync记录发送时间 t1如果支持硬件时间戳t1 可以塞进 Sync 的 originTimestamp 字段否则发 Follow_Up 带 t1。从时钟收到 Sync 时记录接收时间 t2收到 Follow_Up 后拿到 t1。然后通过 Pdelay 机制算出链路延迟 d。最终从时钟调整自己的时间offset t2 - t1 - d这个公式看着简单但 d 的测量精度直接决定同步精度。Pdelay 交互里 requester 发 Pdelay_Req 记录 t3responder 收到记录 t4回 Pdelay_Resp 带 t4再发 Pdelay_Resp_Follow_Up 带 t5即 Pdelay_Resp 的发送时间。requester 收到 Pdelay_Resp 记录 t6。链路延迟d ((t4 - t3) (t5 - t6)) / 2注意 t3 和 t6 是 requester 的本地时间t4 和 t5 是 responder 的本地时间两者时钟频率不同所以标准要求用 ratio 来补偿频率差。2020 版对 ratio 的计算和传递写得更细这也是很多实现翻车的地方。2.3 用 Python 模拟一次 Pdelay 计算下面这段代码模拟一次 Pdelay 测量输入是四个时间戳和频率比输出链路延迟。实际固件里用 C但逻辑一样。# Pdelay 链路延迟计算单位纳秒 def calc_pdelay(t3, t4, t5, t6, ratio): t3: requester 发送 Pdelay_Req 的本地时间 t4: responder 接收 Pdelay_Req 的本地时间 t5: responder 发送 Pdelay_Resp 的本地时间 t6: requester 接收 Pdelay_Resp 的本地时间 ratio: responder 时钟频率 / requester 时钟频率 # 先补偿频率差把 responder 的时间戳折算到 requester 时基 t4_corr t4 / ratio t5_corr t5 / ratio # 往返延迟取平均 d ((t4_corr - t3) (t5_corr - t6)) / 2 return d # 示例t31000, t41200, t51300, t61500, ratio1.000002 print(calc_pdelay(1000, 1200, 1300, 1500, 1.000002))逻辑说明ratio 是邻居时钟频率相对本地的比值通常由 Pdelay_Resp_Follow_Up 携带的 cumulativeScaledRateOffset 换算。参数 t3 到 t6 必须来自硬件时间戳软件时间戳的抖动会让 d 误差到微秒级同步精度直接崩。如果 ratio 填 1.0 而实际有偏差长时间跑下来 offset 会线性漂移。3. 把标准落到代码gPTP 状态机与时间戳的工程实现3.1 端口状态机Master、Slave、Passive 怎么切802.1AS 的端口状态机比 1588 简单一些但 2020 版增加了多域场景下的状态隔离。每个端口在每个域里独立跑 BMCA状态有 Master、Slave、Passive、Disabled 等。工程上最容易出问题的是 Passive 状态当两个端口都收到更优的 Announce 时一个变 Slave另一个变 Passive防止环路。但如果 Passive 端口没正确关闭 Sync 转发就会形成时间环路offset 震荡。我一般会在状态机里加一条硬规则进入 Passive 后立即停止发送 Sync 和 Follow_Up并且清空本地保存的邻居时间戳。这条规则标准里没写死但不加就等着抓包看到重复 Sync。3.2 硬件时间戳的获取与校准软件时间戳的精度受中断延迟影响通常只有微秒级而 TSN 要求亚微秒甚至纳秒级。所以必须用 MAC 层硬件时间戳。常见做法是在 PHY 和 MAC 之间加一个时间戳单元发送时在 SFD 第一个字节处打戳接收时同样位置打戳。Linux 下用SO_TIMESTAMPING套接字选项配合PTP_SYS_OFFSETioctl 校准。# 查看网卡是否支持硬件时间戳 ethtool -T eth0 # 输出示例 # Time stamping parameters for eth0: # Capabilities: # hardware-transmit # hardware-receive # hardware-raw-clock # PTP Hardware Clock: 0如果hardware-transmit和hardware-receive都有说明支持。PTP Hardware Clock: 0表示有独立的 PHC 设备通常是/dev/ptp0。接下来用phc2sys把 PHC 同步到系统时钟或者反过来。# 把 PHC 时间同步到系统时钟-s 指定源-c 指定目标 phc2sys -s /dev/ptp0 -c CLOCK_REALTIME -O 0 -m # 如果 PHC 是主时钟反向同步 phc2sys -s CLOCK_REALTIME -c /dev/ptp0 -O 0 -m参数-O 0表示 offset 为 0-m打印测量值。实际调试时我会先跑pmc看端口状态再抓包确认 Sync 间隔。3.3 用 tcpdump 抓 gPTP 报文并过滤gPTP 报文走二层EtherType 是 0x88F7目的 MAC 是 01:80:C2:00:00:0E。抓包命令# 抓取 gPTP 报文-i 指定接口-w 保存文件 tcpdump -i eth0 -w gptp.pcap ether proto 0x88f7 # 只看 Announce 报文 tcpdump -i eth0 -v ether proto 0x88f7 and ether[14] 0x0b逻辑说明ether[14]是 gPTP 报文里 messageType 字段的偏移0x0b 对应 Announce。Sync 是 0x00Follow_Up 是 0x08Pdelay_Req 是 0x02Pdelay_Resp 是 0x03。抓完用 Wireshark 打开看 Announce 里的 grandmasterIdentity 和 stepsRemoved如果 stepsRemoved 一直涨说明有环路。注意抓包时网卡必须支持混杂模式且不能开硬件时间戳过滤否则报文可能被网卡直接吞掉。4. 避坑与排查gPTP 不收敛的五个血泪现场4.1 现象offset 一直在正负几百纳秒跳不收敛原因Pdelay 测距不准通常是软件时间戳或 ratio 没补偿。解决确认ethtool -T显示硬件时间戳已启用检查 Pdelay_Resp_Follow_Up 里的 cumulativeScaledRateOffset 是否被正确解析。如果 ratio 字段一直是 0说明对端没填需要手动在驱动里补。4.2 现象主从切换后时间跳变超过 1 秒原因新主时钟的 clockClass 和旧主一样BMCA 没触发重新计算或者切换时没有平滑过渡。解决在状态机里加 holdover 逻辑切换前先进入 holdover 模式用本地晶振维持收到新主的 Sync 后再逐步调整而不是直接跳。4.3 现象Announce 报文收不到但 Sync 能收到原因交换机把目的 MAC 01:80:C2:00:00:0E 的报文过滤了。很多商用交换机默认不转发这个 MAC。解决换支持 TSN 的交换机或者在交换机上配置静态 MAC 表项允许该 MAC 泛洪。4.4 现象多域场景下域 0 同步正常域 1 完全不动原因2020 版支持多域但很多实现只处理 domainNumber 为 0 的报文。解决检查代码里是否对 domainNumber 做了过滤确保每个域独立跑 BMCA。如果用的是开源 gPTP 栈看gptp.c里domainNumber的判断条件。4.5 现象系统时钟和 PHC 偏差越来越大原因phc2sys没跑或者跑的时候没加-O参数导致 offset 累积。解决用pmc -u -b 0 GET TIME_STATUS_NP查看 PHC 和系统时钟的 offset如果超过 1 微秒重新校准。我习惯在启动脚本里加一条phc2sys的守护用 systemd 管理挂了自动重启。5. 进阶用 802.1AS-2020 的 cumulativeScaledRateOffset 做频率补偿标准里有个容易被忽略的字段cumulativeScaledRateOffset。它描述的是沿同步路径累积的频率偏移单位是 ppb十亿分之一。2020 版明确要求每个节点在转发 Sync 时更新这个值。如果你只调 offset 不调频率同步会一直有残余误差因为本地晶振和对端晶振频率不同offset 会线性漂移。具体做法从时钟收到 Sync 后除了算 offset还要用 cumulativeScaledRateOffset 调整本地时钟的频率。Linux 下可以用adjtimex或clock_adjtime系统调用把频率补偿值写进内核。#include sys/timex.h // 设置频率补偿单位是 scaled ppm1 ppm 65536 struct timex tx {0}; tx.modes ADJ_FREQUENCY; tx.freq (long)(rate_offset_ppb * 65536 / 1000); if (adjtimex(tx) 0) { perror(adjtimex); }参数说明rate_offset_ppb是从 cumulativeScaledRateOffset 换算来的 ppb 值。65536是内核的缩放因子1000是把 ppb 转成 ppm。注意tx.freq是 long 类型范围有限如果偏移太大需要分步调整。验证方法跑pmc -u -b 0 GET TIME_STATUS_NP看freq_offset是否稳定在几十 ppb 以内。如果一直几百 ppb说明补偿没生效。我一般会同时抓phc2sys的日志看它输出的频率调整值是否和预期一致。从那以后我每次调 gPTP都强制先跑一遍ethtool -T和tcpdump确认硬件时间戳和报文路径再动状态机。希望帮到你。本文还有配套的精品资源点击获取 IEEE 802.1AS-2020 时间同步实战：从 BMCA 到 gPTP 不收敛排查
简介IEEE 802.1AS-2020.pdf 是 IEEE 官方发布的局域网时间同步标准文档面向从事 TSN时间敏感网络协议研究、工业自动化与车载以太网开发的工程师及高校师生用于解决分布式系统中时钟同步、时序传输与恢复等核心问题。资源包内仅含 1 个 PDF 文件大小约 6.2MB完整收录标准正文涵盖同步时间传输、最佳主时钟选择、相位与频率偏差指示等协议、过程及管理对象定义并涉及 Grandmaster Clock、PTP 实例、时间感知系统等关键术语。该标准是 TSN 协议族中时序同步的基础规范读者可据此深入理解时钟同步机制、时序信息封装与重传、管理对象配置等知识点为协议实现、设备开发与测试验证提供权威依据。目前已有 475 人学习下载适合需要查阅原始标准条款、对照协议细节进行技术攻关的读者。1. 从一份 802.1AS-2020 文档说起TSN 时间同步到底卡在哪做车载以太网、工业实时控制或者音视频桥接的兄弟大概率都经历过这种场面交换机配置全对PTP 报文也抓到了但示波器上两路时钟就是差那么几百纳秒反复重启偶尔又能对上。这种玄学问题十有八九是没把 IEEE 802.1AS 的细节吃透。802.1AS 是 TSN时间敏感网络里负责时间同步的核心标准2020 版相比 2011 版在 gPTPgeneralized PTP基础上补了大量工程细节比如多域支持、更细的时钟质量分级、以及和 802.1Qbv 门控调度的配合。这份 PDF 就是标准原文不是教程但它是所有 TSN 时间同步实现的最终依据。适合谁看写交换机固件的、做域控制器时间同步的、调 AVB 音频链路的以及被 gPTP 收敛问题折磨过的测试工程师。它解决的不是“怎么装软件”而是“为什么你的时间同步不收敛、抖动大、主从切换慢”。2. 802.1AS-2020 的时钟模型与报文机制先搞懂 BMCA 和 Sync 怎么走2.1 为什么 2020 版把时钟质量拆得更细2011 版的 802.1AS 用一套相对简单的优先级向量选主时钟到了 2020 版标准把 clockClass、clockAccuracy、offsetScaledLogVariance 这几个参数的语义写得更死。原因很直接车载和工业场景里一个域里可能同时存在 GPS 驯服时钟、晶振保持时钟、以及从网络恢复的普通时钟如果不把质量等级分清楚BMCABest Master Clock Algorithm就会选出一个“看起来优先级高但实际抖动大”的节点当主时钟整个域跟着遭殃。标准里把 clockClass 从 6 到 255 分了多档常见工程取值6 表示主参考如 GPS 锁定7 表示保持模式52 表示普通晶振。clockAccuracy 用 0x20 到 0x31 表示从 25ns 到 10s 的精度范围。offsetScaledLogVariance 则描述抖动。这三个值一起塞进 Announce 报文BMCA 按优先级向量比较。我一般会在代码里把这三个参数做成可配置而不是硬编码因为不同硬件方案差别太大。提示如果你的设备没有 GPSclockClass 不要填 6否则一旦 GPS 失锁BMCA 不会自动降级整个域会跟着漂。2.2 Sync/Follow_Up 与 P2P 延迟测量的报文交互802.1AS 的时间同步靠三组报文Announce 选主、Sync/Follow_Up 传时间、Pdelay_Req/Pdelay_Resp/Pdelay_Resp_Follow_Up 测链路延迟。2020 版明确要求使用 P2PPeer-to-Peer延迟测量机制而不是端到端的 Delay_Req。这意味着每个端口都要和邻居端口独立测延迟而不是只跟主时钟测。一次完整的同步过程大致是主时钟发 Sync记录发送时间 t1如果支持硬件时间戳t1 可以塞进 Sync 的 originTimestamp 字段否则发 Follow_Up 带 t1。从时钟收到 Sync 时记录接收时间 t2收到 Follow_Up 后拿到 t1。然后通过 Pdelay 机制算出链路延迟 d。最终从时钟调整自己的时间offset t2 - t1 - d这个公式看着简单但 d 的测量精度直接决定同步精度。Pdelay 交互里 requester 发 Pdelay_Req 记录 t3responder 收到记录 t4回 Pdelay_Resp 带 t4再发 Pdelay_Resp_Follow_Up 带 t5即 Pdelay_Resp 的发送时间。requester 收到 Pdelay_Resp 记录 t6。链路延迟d ((t4 - t3) (t5 - t6)) / 2注意 t3 和 t6 是 requester 的本地时间t4 和 t5 是 responder 的本地时间两者时钟频率不同所以标准要求用 ratio 来补偿频率差。2020 版对 ratio 的计算和传递写得更细这也是很多实现翻车的地方。2.3 用 Python 模拟一次 Pdelay 计算下面这段代码模拟一次 Pdelay 测量输入是四个时间戳和频率比输出链路延迟。实际固件里用 C但逻辑一样。# Pdelay 链路延迟计算单位纳秒 def calc_pdelay(t3, t4, t5, t6, ratio): t3: requester 发送 Pdelay_Req 的本地时间 t4: responder 接收 Pdelay_Req 的本地时间 t5: responder 发送 Pdelay_Resp 的本地时间 t6: requester 接收 Pdelay_Resp 的本地时间 ratio: responder 时钟频率 / requester 时钟频率 # 先补偿频率差把 responder 的时间戳折算到 requester 时基 t4_corr t4 / ratio t5_corr t5 / ratio # 往返延迟取平均 d ((t4_corr - t3) (t5_corr - t6)) / 2 return d # 示例t31000, t41200, t51300, t61500, ratio1.000002 print(calc_pdelay(1000, 1200, 1300, 1500, 1.000002))逻辑说明ratio 是邻居时钟频率相对本地的比值通常由 Pdelay_Resp_Follow_Up 携带的 cumulativeScaledRateOffset 换算。参数 t3 到 t6 必须来自硬件时间戳软件时间戳的抖动会让 d 误差到微秒级同步精度直接崩。如果 ratio 填 1.0 而实际有偏差长时间跑下来 offset 会线性漂移。3. 把标准落到代码gPTP 状态机与时间戳的工程实现3.1 端口状态机Master、Slave、Passive 怎么切802.1AS 的端口状态机比 1588 简单一些但 2020 版增加了多域场景下的状态隔离。每个端口在每个域里独立跑 BMCA状态有 Master、Slave、Passive、Disabled 等。工程上最容易出问题的是 Passive 状态当两个端口都收到更优的 Announce 时一个变 Slave另一个变 Passive防止环路。但如果 Passive 端口没正确关闭 Sync 转发就会形成时间环路offset 震荡。我一般会在状态机里加一条硬规则进入 Passive 后立即停止发送 Sync 和 Follow_Up并且清空本地保存的邻居时间戳。这条规则标准里没写死但不加就等着抓包看到重复 Sync。3.2 硬件时间戳的获取与校准软件时间戳的精度受中断延迟影响通常只有微秒级而 TSN 要求亚微秒甚至纳秒级。所以必须用 MAC 层硬件时间戳。常见做法是在 PHY 和 MAC 之间加一个时间戳单元发送时在 SFD 第一个字节处打戳接收时同样位置打戳。Linux 下用SO_TIMESTAMPING套接字选项配合PTP_SYS_OFFSETioctl 校准。# 查看网卡是否支持硬件时间戳 ethtool -T eth0 # 输出示例 # Time stamping parameters for eth0: # Capabilities: # hardware-transmit # hardware-receive # hardware-raw-clock # PTP Hardware Clock: 0如果hardware-transmit和hardware-receive都有说明支持。PTP Hardware Clock: 0表示有独立的 PHC 设备通常是/dev/ptp0。接下来用phc2sys把 PHC 同步到系统时钟或者反过来。# 把 PHC 时间同步到系统时钟-s 指定源-c 指定目标 phc2sys -s /dev/ptp0 -c CLOCK_REALTIME -O 0 -m # 如果 PHC 是主时钟反向同步 phc2sys -s CLOCK_REALTIME -c /dev/ptp0 -O 0 -m参数-O 0表示 offset 为 0-m打印测量值。实际调试时我会先跑pmc看端口状态再抓包确认 Sync 间隔。3.3 用 tcpdump 抓 gPTP 报文并过滤gPTP 报文走二层EtherType 是 0x88F7目的 MAC 是 01:80:C2:00:00:0E。抓包命令# 抓取 gPTP 报文-i 指定接口-w 保存文件 tcpdump -i eth0 -w gptp.pcap ether proto 0x88f7 # 只看 Announce 报文 tcpdump -i eth0 -v ether proto 0x88f7 and ether[14] 0x0b逻辑说明ether[14]是 gPTP 报文里 messageType 字段的偏移0x0b 对应 Announce。Sync 是 0x00Follow_Up 是 0x08Pdelay_Req 是 0x02Pdelay_Resp 是 0x03。抓完用 Wireshark 打开看 Announce 里的 grandmasterIdentity 和 stepsRemoved如果 stepsRemoved 一直涨说明有环路。注意抓包时网卡必须支持混杂模式且不能开硬件时间戳过滤否则报文可能被网卡直接吞掉。4. 避坑与排查gPTP 不收敛的五个血泪现场4.1 现象offset 一直在正负几百纳秒跳不收敛原因Pdelay 测距不准通常是软件时间戳或 ratio 没补偿。解决确认ethtool -T显示硬件时间戳已启用检查 Pdelay_Resp_Follow_Up 里的 cumulativeScaledRateOffset 是否被正确解析。如果 ratio 字段一直是 0说明对端没填需要手动在驱动里补。4.2 现象主从切换后时间跳变超过 1 秒原因新主时钟的 clockClass 和旧主一样BMCA 没触发重新计算或者切换时没有平滑过渡。解决在状态机里加 holdover 逻辑切换前先进入 holdover 模式用本地晶振维持收到新主的 Sync 后再逐步调整而不是直接跳。4.3 现象Announce 报文收不到但 Sync 能收到原因交换机把目的 MAC 01:80:C2:00:00:0E 的报文过滤了。很多商用交换机默认不转发这个 MAC。解决换支持 TSN 的交换机或者在交换机上配置静态 MAC 表项允许该 MAC 泛洪。4.4 现象多域场景下域 0 同步正常域 1 完全不动原因2020 版支持多域但很多实现只处理 domainNumber 为 0 的报文。解决检查代码里是否对 domainNumber 做了过滤确保每个域独立跑 BMCA。如果用的是开源 gPTP 栈看gptp.c里domainNumber的判断条件。4.5 现象系统时钟和 PHC 偏差越来越大原因phc2sys没跑或者跑的时候没加-O参数导致 offset 累积。解决用pmc -u -b 0 GET TIME_STATUS_NP查看 PHC 和系统时钟的 offset如果超过 1 微秒重新校准。我习惯在启动脚本里加一条phc2sys的守护用 systemd 管理挂了自动重启。5. 进阶用 802.1AS-2020 的 cumulativeScaledRateOffset 做频率补偿标准里有个容易被忽略的字段cumulativeScaledRateOffset。它描述的是沿同步路径累积的频率偏移单位是 ppb十亿分之一。2020 版明确要求每个节点在转发 Sync 时更新这个值。如果你只调 offset 不调频率同步会一直有残余误差因为本地晶振和对端晶振频率不同offset 会线性漂移。具体做法从时钟收到 Sync 后除了算 offset还要用 cumulativeScaledRateOffset 调整本地时钟的频率。Linux 下可以用adjtimex或clock_adjtime系统调用把频率补偿值写进内核。#include sys/timex.h // 设置频率补偿单位是 scaled ppm1 ppm 65536 struct timex tx {0}; tx.modes ADJ_FREQUENCY; tx.freq (long)(rate_offset_ppb * 65536 / 1000); if (adjtimex(tx) 0) { perror(adjtimex); }参数说明rate_offset_ppb是从 cumulativeScaledRateOffset 换算来的 ppb 值。65536是内核的缩放因子1000是把 ppb 转成 ppm。注意tx.freq是 long 类型范围有限如果偏移太大需要分步调整。验证方法跑pmc -u -b 0 GET TIME_STATUS_NP看freq_offset是否稳定在几十 ppb 以内。如果一直几百 ppb说明补偿没生效。我一般会同时抓phc2sys的日志看它输出的频率调整值是否和预期一致。从那以后我每次调 gPTP都强制先跑一遍ethtool -T和tcpdump确认硬件时间戳和报文路径再动状态机。希望帮到你。本文还有配套的精品资源点击获取