企业官网建设流程全解析

简介：ARINC825-2007协议是面向航空电子、机载网络与CAN总线工程领域的技术标准文档，适合飞机制造商、设备供应商、航空公司维修站以及从事机载通信设计、测试和适航评估的工程师查阅。文档围绕机载控制器局域网络（CAN）总线协议的通用标准化展开，给出设备间数据交换的技术要求与实施边界，并说明其出口管理属性、免责声明及自愿性标准定位，可用于指导相关组件、系统和设备的测试、评估、安装与操作。资源包共1个PDF文件，约1.96MB，保留AEEC起草、ARINC出版的规范原文，便于按条款核对定义与技术细节。已有295人学习，读者可借此理解航空级CAN总线的兼容性要求、标准术语含义及供应商合规声明的边界，为机载网络方案论证和资料查证提供依据。

1. 机载 CAN 的难点不在波特率，而在「谁在什么时候能说话」

很多人第一次翻 ARINC825 会有点失望：位定时、仲裁、CRC、错误帧，几乎全是 CAN 2.0B 和高速 CAN 电气规范里的老熟人。真正值钱的地方，是它把这套东西从「能跑就行」抬到了「可以被审查、可以被证明」：网络先划域再接线，29 位标识符按固定位段切分，采样点位置和传播裕度要算出来，错误计数器涨到什么程度节点必须停止发送，健康状态多久广播一次、载荷里放什么。车上的 CAN 追求的是成本与灵活，机上的 CAN 追求的是可验证的最坏情况。同一颗控制器，放在两个场景里，配置参数、裕度计算、故障处理逻辑几乎是两套东西。

2. 物理层不是接线图：位定时、端接与地偏移如何决定误码率

物理层这一层最容易被当成「照着参考设计抄一遍」的活儿，实际上它承担了整个协议的确定性底座。

2.1 先划网络域，再谈线和速率

标准在第 2 章先讲网络域、跨域数据流、拓扑和协议架构，然后才进物理层参数，这个顺序并非随意安排。CAN 是共享介质、广播式、无交换机的总线，任何一处电气故障、任何一个节点持续输出显性电平，都会波及整个域内的所有通信。先划域，本质是先定「故障域半径」——域内节点数量、线缆总长、支线长度、端接点位置、位速率，都是互相牵制的变量，脱离域边界去谈某个参数合不合格没有意义。

域一旦定下来，几个量就基本锁死了：域内节点数决定总线负载电容和等效阻抗，线缆总长决定单向传播延迟，支线长度决定反射能量，而这三者又共同决定位时间里能留多少传播段余量。所以物理层参数不是「查表抄一个」，而是从域的几何结构反推出来的。

跨域数据流是另一个容易被低估的点。域与域之间通过网关衔接，网关做的不是简单转发：两端位速率可能不同，标识符分配空间各自独立，数据格式（分辨率、偏移、字节序）也可能不一致。常见的实现思路是网关内部维护一张映射表，把源域的标识符和周期重映射成目的域的形态，并在速率不匹配时做缓冲和降采样。这里翻车的典型场景是直接透传——源域 10 ms 周期的事件帧进了目的域，瞬间把目的域的带宽吃掉一大块。域边界上的网关，更像是协议翻译器而不是路由器。

2.2 一个位时间里塞了什么：同步段、传播段与两个相位缓冲段

CAN 的位时间不是一个方波周期，而是被切成四段：同步段（固定 1 个时间份额）、传播段、相位缓冲段 1、相位缓冲段 2。采样点落在相位缓冲段 1 结束的位置。这个结构存在的唯一理由，是要在一个位时间内容纳「信号从发送节点出发、跑到最远节点、再跑回来」的往返延迟，同时留出再同步的余量。

传播段必须覆盖两倍的物理延迟：收发器内部回环延迟加上线缆单向传播延迟，再乘 2。原因在于仲裁期间，一个节点发出显性位后，必须在自己的采样点之前看到最远节点的电平状态，否则两个节点会就「谁赢了仲裁」产生分歧，进而导致位错误。这是 CAN 最硬的一条时序约束，也是长线缆、多节点、慢收发器场景下最容易配错的地方。

/* 以 500 kbit/s、CAN 时钟 8 MHz 为例的位定时配置 */ typedef struct { uint32_t prescaler; /* 分频：8 MHz / 1 = 8 MHz 的时间份额时钟 */ uint32_t prop_seg; /* 传播段：吸收收发器延迟 + 线缆传播 + 节点间相位差 */ uint32_t phase_seg1; /* 相位缓冲段 1：采样点之前的再同步余量 */ uint32_t phase_seg2; /* 相位缓冲段 2：采样点之后的再同步余量 */ uint32_t sjw; /* 再同步跳变宽度：一次最多调整几个时间份额 */ } can_bit_timing_t; static const can_bit_timing_t arinc825_500k = { .prescaler = 1, /* 1 个时间份额 = 125 ns */ .prop_seg = 8, /* 8 个时间份额 = 1.0 us，覆盖最坏往返传播 */ .phase_seg1 = 4, /* 4 个时间份额 */ .phase_seg2 = 3, /* 3 个时间份额 */ .sjw = 3 /* 不超过 phase_seg2，工程上一般也不超过 4 */ }; /* 位时间 = 1 + 8 + 4 + 3 = 16 个时间份额 = 2 us，对应 500 kbit/s * 采样点 = (1 + 8 + 4) / 16 = 81.25% */

这段配置里有三个参数值得单独说。prescaler决定时间份额的粒度，粒度越细，采样点位置越能精细调整，但对时钟抖动更敏感；prop_seg是唯一一个「必须按物理尺寸算」的参数，节点越多、线越长，它就越不能省；sjw决定再同步时一次能纠正多少相位偏差，上限受相位缓冲段 2 约束，配大了会在强干扰下把采样点拽到危险位置。

采样点位置是另一个常被忽略的量。车规场景里 75% 左右很常见，机载长线缆和级联收发器会带来更大的累积抖动，一般会把采样点往 80% 之后推。这不是玄学，是抖动预算算出来的：所有节点的振荡器容差、收发器延迟不对称、线缆传播差异叠加起来，必须落在采样点之前的裕度里。

2.3 端接与地偏移：差分电压之外还有一条共模红线

高速 CAN 的端接规则很朴素：总线物理两端各一个 120 欧姆，中间节点不允许再并端接，支线尽量短。两个 120 欧姆并联后，驱动器看到的是 60 欧姆负载，这个值决定了显性电平的电流和差分幅度。多并一个端接，负载阻抗掉到 40 欧姆，差分幅度被压低、上升沿变缓、反射加剧，通信距离和误码率一起变差。这类问题在台架上往往看不出来，因为线短、节点少，一上整机就原形毕露。

地偏移是机载环境里更隐蔽的一条线。CAN 收发器看的是差分电压，但它的输入级有一个有限的共模范围，经典高速 CAN 器件大致在负几伏到正几伏这个量级。机上不同设备各自就近接地，接地阻抗、回流路径、屏蔽层处理方式都不一样，两个节点之间的地电位差可能远超台架上的想象。一旦共模电压把收发器推出线性区，差分判决就会出错，表现是零星的位错误和错误帧，而不是干脆断链——这种「偶发、不可复现、换个位置就好」的故障，最消耗联试时间。

标准里把线缆特性、连接器与触点特性、安装与接地特性、网络端接、地偏移放在同一节讲，逻辑就在这里：它们不是五个独立参数，而是一套共模与阻抗预算的不同侧面。

2.4 dominant timeout 与未供电节点：两条最容易被漏掉的硬件防线

有一条故障模式在实验室里几乎不会出现，但在整机上后果极重：某个节点的收发器损坏，持续往总线上输出显性电平。因为显性是「线与」的支配态，整条总线会被永久拉低，所有节点都无法发出哪怕一个隐性位，通信彻底停摆。这类故障靠软件无法恢复，只能靠收发器内部的显性超时保护：检测到发送端连续输出显性超过设定时间，就自动切断发送通路，把总线释放出来。

另一条是未供电节点。设备断电后，如果它的总线引脚呈现低阻，就会像一个负载一样挂在总线上，把差分线拉死。合格的设计要求收发器在掉电时总线引脚呈高阻，必要时还要串隔离电阻或加隔离器件。这一条在台架上几乎不会被测到，因为台架上的设备都通着电。

注意：整机联试前，务必做一次「断电节点挂总线」测试，把每个节点单独断电后观察总线波形与错误计数，这项测试能提前暴露大部分硬件层隐患。

3. 数据链路层：仲裁、滤波与错误遏制是怎么一起工作的

数据链路层是 ARINC825 里技术密度最高的部分，几乎所有联试问题最终都会归结到这里的某一条机制上。

3.1 非破坏性仲裁的代价：优先级是设计出来的，不是碰运气

CAN 的仲裁靠「线与」实现：显性覆盖隐性，标识符数值越小优先级越高，冲突的节点在逐位比较中自动退出，赢家继续发送且不损失时间——这就是「非破坏性」的含义。这套机制很优雅，但代价明确：优先级完全由标识符数值决定，一旦分配下去，低优先级报文的最坏响应时间就只能靠离线计算来保证。

在机载场景里，这意味着标识符分配本身就是一次设计活动。哪些参数是飞行控制回路里的、哪些是状态显示用的、哪些是维护数据，必须在分配阶段就分层，而不能等联试时发现某个参数更新抖动再回头改。事件型报文（故障上报、离散量变化）如果频率不受控，很容易在短时间内占满仲裁窗口，把周期型关键帧饿死。常见的工程做法是给事件帧加最小发送间隔，并在带宽预算里为关键周期帧预留固定份额。

3.2 验收滤波：把 CPU 从中断风暴里捞出来

总线上的每一帧对每个节点都是可见的，但一个节点通常只关心其中很少一部分。如果所有帧都触发中断，CPU 会被中断风暴淹没，尤其在 500 kbit/s 满载时每秒上千帧的情况下。硬件验收滤波器解决的就是这个问题：它在控制器内部对标识符做位掩码比较，只有匹配的帧才进入接收 FIFO 并触发中断。

/* 典型的掩码+比较值滤波器：mask 为 1 的位必须与 code 一致，为 0 的位忽略 */ typedef struct { uint32_t code; /* 期望的标识符位型 */ uint32_t mask; /* 关心哪些位 */ } can_filter_t; /* 只想接收源地址字段等于 0x21 的报文，其余位全部放行 */ static const can_filter_t filter_src_0x21 = { .code = (0x21u << SRC_ADDR_SHIFT), .mask = (0x1Fu << SRC_ADDR_SHIFT) /* 假设源地址占 5 位 */ };

这段代码的意义要结合标识符结构来读。掩码滤波能生效的前提，是「想过滤的字段」在标识符里占据固定位段。ARINC825 把源地址、目的地址这类字段钉在固定位置，正是为了让硬件滤波器可以按发送方或接收方做粗筛，而不必把所有帧都搬进内存再软件判断。这也解释了为什么标识符结构一旦定下来就极难改动：它同时约束了硬件滤波器配置、驱动层分发逻辑和上层软件的路由表。

实际配置时还有个细节：滤波器通常成组存在，一组的 code 和 mask 是配对的，改组配置前必须先让该组退出工作状态，否则会出现短暂的「收错帧」窗口。这个窗口极短，但在高负载总线上足以漏掉关键帧。

3.3 五类错误识别：错误帧为什么能被所有节点「同时」发出

CAN 定义了五类错误：位错误、位填充错误、CRC 错误、格式错误、应答错误。位错误是发送节点回读到的电平与自己发出的不一致；位填充错误是连续五个相同电平之后第六位没有按规定反转；CRC 错误是接收方算出的校验与帧内 CRC 字段不符；格式错误是固定格式位段出现了非法电平；应答错误是发送节点在应答槽没有收到任何节点的显性应答。

这套机制的精妙之处在于「全局一致」：任何检测到错误的节点都会在紧接着的位时间里发出错误标志，而错误标志本身会破坏当前的位填充规则，从而让所有其他节点也检测到错误并加入。最终结果是，一次局部错误被放大成一次全网可见的、时间上对齐的错误事件，出错帧被所有节点一致丢弃，发送方自动重传。这就是 CAN 不需要逐帧确认却能保证数据一致性的底层原因。

错误标志分两种形态：错误主动节点发 6 个连续显性位，错误被动节点发 6 个连续隐性位。后者不会破坏总线上的其他通信，这是被动状态的设计意图——一个自身可靠性存疑的节点，不应该再有权力去打断别人的正常通信。

3.4 TEC/REC 与 bus-off：一个节点什么时候必须不再发送

每个节点维护两个计数器：发送错误计数 TEC 和接收错误计数 REC。规则很简单也很有效：发送出错 TEC 加 8，接收出错 REC 加 1，成功发送 TEC 减 1，成功接收 REC 减 1（有条件）。计数器的值决定节点状态：两者都低于 128 是错误主动，任一达到 128 进入错误被动，TEC 超过 255 则进入 bus-off——节点必须从总线上完全退出，不再发送任何内容。

/* 错误遏制状态机核心判断，阈值取自 CAN 错误计数规则 */ typedef enum { ERR_ACTIVE, ERR_PASSIVE, BUS_OFF } node_state_t; static void can_error_update(node_ctx_t *n, int tec_delta, int rec_delta) { n->tec = clamp(n->tec + tec_delta, 0, 256); /* 上限截到 256 */ n->rec = clamp(n->rec + rec_delta, 0, 256); if (n->tec >= 256) { n->state = BUS_OFF; /* 发送错误越界：必须退出总线 */ n->bus_off_since = now_ms(); /* 记录时刻，供受控恢复使用 */ } else if (n->tec >= 128 || n->rec >= 128) { n->state = ERR_PASSIVE; /* 只能发隐性错误标志，不再干扰总线 */ } else { n->state = ERR_ACTIVE; } }

TEC 加 8 而 REC 加 1 的不对称设计，体现了「谁的错谁承担」的思路：发送方对总线的影响更大，所以惩罚更重，这样能更快把持续发送失败的节点隔离出去。进入被动状态的节点在发送完一帧后还必须额外等待一段挂起传输时间，才有资格参与下一次仲裁，进一步降低它对总线的干扰。

bus-off 之后的恢复策略，是这份规范里比较有工程智慧的一处。汽车领域常见做法是检测到总线空闲就自动恢复，代价是一个存在硬件故障的节点会反复「复活—出错—再退出」，把总线周期性搅乱。机载场景更倾向受控恢复：延迟一段时间再尝试，同时限制单位时间内的恢复次数，超过阈值就锁定在 bus-off 并上报。

/* 受控恢复：延迟 + 次数上限，避免抖动节点反复污染总线 */ #define BUS_OFF_RECOVERY_DELAY_MS 1000u #define BUS_OFF_MAX_RETRY 3u static void bus_off_recovery_tick(node_ctx_t *n, uint32_t now) { if (n->state != BUS_OFF) return; if (now - n->bus_off_since < BUS_OFF_RECOVERY_DELAY_MS) return; if (n->retry_count >= BUS_OFF_MAX_RETRY) { n->locked_out = 1; /* 锁定并上报，等待维护介入 */ return; } n->retry_count++; can_controller_reset(n); /* 重新初始化并等待 128 次 11 位隐性 */ }

4. 标识符与互操作：ARINC825 真正「航空化」的那部分

前面三章讲的是 CAN 的共性，这一章讲的是 ARINC825 把通用 CAN 改造成航空可用协议时动的手脚。

4.1 29 位 ID 的分段：为什么源地址要放在固定位段

通用 CAN 只规定标识符是 11 位或 29 位，怎么用完全自由。自由带来的后果是每家供应商一套编码，联试时先花两周对齐标识符含义。ARINC825 的核心动作之一，就是把 29 位扩展标识符按语义切成若干固定字段：功能或参数码、源节点地址、目的节点地址（广播时用特定值表示），并预留优先级相关位。

字段宽度和精确位置以标准正文为准，但设计逻辑是清晰的：一旦这些字段的位置固定，硬件滤波器、驱动层路由、上层参数表就可以三层解耦。硬件按源地址粗筛，驱动按参数码分发，应用层只认参数名。这种分层在节点数量上去之后价值极大——新增一个节点不需要改动其他节点的接收逻辑，只要它发送的参数码在全局分配表里。

# 按固定位段拆解 29 位标识符，字段宽度为示意，实际以标准正文为准 SRC_SHIFT, SRC_BITS = 8, 5 DST_SHIFT, DST_BITS = 13, 5 PARAM_SHIFT, PARAM_BITS = 18, 11 def decode_can_id(can_id: int) -> dict: return { "src": (can_id >> SRC_SHIFT) & ((1 << SRC_BITS) - 1), "dst": (can_id >> DST_SHIFT) & ((1 << DST_BITS) - 1), "param": (can_id >> PARAM_SHIFT) & ((1 << PARAM_BITS) - 1), "prio": can_id & 0x1F, # 低位参与仲裁，数值越小越优先 }

这段代码在联试阶段非常实用：抓包日志里全是十六进制标识符，人眼根本看不出是哪个节点在发哪个参数，先解一遍再打印，排障效率完全不同。

4.2 数据格式、轴系与符号约定：把「正负号」写进标准

数据载荷的互操作性问题是航空电子领域的老问题。同一个物理量，不同供应商可能用不同的分辨率、不同的偏移量、不同的字节序，甚至对正方向的定义都相反——俯仰角抬头为正还是低头为正，横滚角左滚为正还是右滚为正，这类约定不统一，联试时看到的现象是「数值对但符号反」，排查方向会一路跑偏到传感器上。

标准用两件事解决它：一是定义统一的数据格式，包括编码类型、分辨率、偏移和无效值标记；二是定义轴系与符号约定，把「正方向朝哪」写进规范。它还按飞机功能和物理单位组织 profile，把「这个参数用哪个单位、什么量程、什么精度」固定下来。常见的实现思路是在参数表里为每个参数写清单位、缩放因子、偏移、有效范围和无效值编码，接收方先判断有效性再做缩放，而不是拿到原始字节直接乘系数。

这里有一条血泪经验：无效值一定要显式定义并单独判断。用全 1 表示「数据不可用」是常见做法，但如果接收方没做这个判断，就会把无效值当成一个极大的合法数值送进控制回路，后果比丢帧严重得多。

4.3 周期节点健康状态：把错误计数器从本地黑匣子搬上总线

CAN 的 TEC 和 REC 本来是节点私有的，只影响自己的状态机。总线出问题时，维护人员能看到「错误帧变多」，却无法回答「是谁在制造这些错误帧」。ARINC825 的做法是要求节点周期性地广播自身健康状态，载荷里包含当前的 TEC、REC 值和节点状态机状态。

这个设计看似平淡，实际解决了一个非常实际的定位问题：错误是全局可见的，但错误源是局部的。把局部计数器搬到总线上之后，任何接入总线的分析设备都能直接看到「某个节点的 TEC 在持续上涨」，从而把排查范围从整条总线收缩到一个设备。这是把可观测性做进协议本身，而不是依赖外挂的诊断工具。

import struct def parse_node_health(payload: bytes) -> dict: """周期健康状态载荷解析，字段布局为示意，实际以标准正文为准""" tec, rec, state = struct.unpack_from("<BBB", payload, 0) return { "tec": tec, # 发送错误计数，持续上涨说明本节点发不出去 "rec": rec, # 接收错误计数，上涨说明本节点收不对 "state": state, # 0=错误主动 1=错误被动 2=bus-off "healthy": state == 0 and tec < 64 and rec < 64, }

解读这份数据有个技巧：TEC 涨而 REC 不涨，问题多半在这个节点自己的发送通路（收发器、端接、线序）；REC 涨而 TEC 不涨，问题在它听到的总线质量（别的节点在拉低信号，或者地偏移）；两个都涨，通常是物理层共性问题。这套判读方法比单纯看「错误帧计数」精确得多。

5. 联试现场最常见的五个坑：从现象倒推机制

5.1 采样点按车规配，长线缆上偶发位错误

现象：台架上一切正常，装到整机上以后，每隔几分钟出现一批错误帧，位置随机，节点不固定，重启后消失。

原因：位定时沿用了车规模板，采样点落在 75% 附近，传播段只留了很小的余量。整机线缆长度和节点数量上来之后，往返传播延迟超出了传播段覆盖范围，最远节点在发送节点的采样点之后才把电平送回来，仲裁阶段出现「两个节点都以为自己赢了」的情况，回读电平不一致就报位错误。

解决：按实际线长和收发器延迟重新计算传播段，把采样点推到 80% 以上，同时确认再同步跳变宽度不超过相位缓冲段 2。改完之后要用示波器在总线最远端的节点上实测采样点位置，而不是只看配置寄存器。

5.2 多并了一个 120 欧姆，波形幅度直接掉一半

现象：总线差分幅度明显偏低，上升沿变缓，通信距离缩短，负载重的时候错误帧集中出现。

原因：某个节点的电路板上焊了板载端接电阻，整机集成时没有跳开，总线上出现了三个甚至更多端接点，等效负载阻抗从 60 欧姆掉到 40 欧姆以下。

解决：明确规则——端接只保留物理两端，中间节点一律断开板载电阻。集成检查清单里加一条「断电测总线电阻」，两个端接点时测得的直流电阻应该在 60 欧姆左右，明显偏低就说明多并了。

5.3 某个节点一断电，整条总线跟着瘫

现象：单独给某个设备断电，整条总线通信中断，重新上电后恢复正常。

原因：该设备的收发器在掉电状态下总线引脚不是高阻，把差分线拉在某个固定电平上，或者通过内部保护二极管形成低阻通路。这类问题在台架上测不出来，因为台架上的设备都通着电。

解决：选型阶段确认收发器的掉电高阻特性，必要时串隔离电阻或采用隔离型收发器。整机联试前把「逐个断电、观察总线」列为必做项，每个节点都过一遍。

5.4 bus-off 后无限自动重连，总线周期性抽风

现象：总线每隔一段时间出现密集错误帧，持续几百毫秒后恢复，反复循环，日志里能看到某个节点频繁进出 bus-off。

原因：节点配置成了检测到总线空闲就自动恢复。存在硬件隐患的节点每次恢复后短时间内再次出错，TEC 迅速涨回 255，再次退出，每次进出都往总线上喷一批错误帧。

解决：改成受控恢复——延迟一段时间再尝试，限制单位时间内的恢复次数，超过阈值锁定并上报。同时把健康状态报文里的 TEC/REC 接进监控，锁定节点后能直接定位到设备，而不是靠拔线试。

5.5 ID 随手分配，低优先级周期帧被饿死

现象：某些参数的更新周期忽长忽短，负载低的时候正常，一旦有事件上报就出现明显抖动甚至丢帧。

原因：标识符分配时没做优先级规划，事件帧拿到了数值更小的 ID。事件密集触发时，事件帧在仲裁中持续获胜，周期帧一直退让。CAN 的非破坏性仲裁只是「不浪费带宽」，并不保证公平。

解决：按参数关键度分层分配标识符数值，事件帧设置最小发送间隔，并在设计阶段做一次最坏响应时间计算，确认关键周期帧在满负载叠加事件风暴的情况下仍能满足周期要求。

6. 设计取舍：标准给的是边界，验证方法才是落地的那一半

把这份规范读透之后会发现，它真正提供的是可审查的边界，而不是现成的实现方案。仲裁、位定时、错误遏制这些机制在通用 CAN 里早就存在，ARINC825 做的是把它们参数化、把裕度要求写清楚、把可观测性做进协议，让「这套网络在最坏情况下仍然可控」变成一件可以被论证的事。

由此产生几组必须自己权衡的取舍。确定性与灵活性：固定标识符分段换来了硬件滤波和三层解耦，代价是参数码分配表成为全局资源，任何新增参数都要走协调流程，这在快速迭代阶段会显得笨重。本地处理与全网可见：把 TEC/REC 广播上总线提升了可诊断性，代价是每个节点都要周期性占用带宽发送健康状态，节点数多的时候这笔开销不能忽略。自动恢复与受控恢复：前者可用性高，后者可控性好，机载场景通常选后者，但这意味着必须配套设计一套锁定后的维护流程，否则锁死的节点没人管。

验证方法上，有三件事我建议固定下来：一是位定时不要只靠配置工具算，要在最远端实测采样点；二是整机联试前做断电节点测试和多端接检查；三是把健康状态报文接入长期记录，事后回溯时能直接看到哪个节点的计数器在涨。这三件事覆盖了物理层、硬件集成层和协议层最常见的失效路径。

说个自己的教训。早些年做一个模拟项目，台架上一切正常，装到整机上以后每隔十几分钟冒一批错误帧，位置随机，重装一遍就好，过一阵又出现。当时把软件翻了个底朝天，最后用示波器挂在总线最远端的节点上才看到采样点位置偏得太靠前，传播延迟把余量吃干净了。从那以后我每次配位定时，都强制走一遍「算传播段、定采样点、最远端实测」的流程，哪怕配置工具给出的默认值看起来完全合理。希望帮到你。

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