简介基于OPNET的移动自组织网络仿真实例包面向网络方向的研究生、通信专业师生以及从事无线网络仿真的工程师可用于理解自组织、无中心、动态拓扑与节点资源受限等MANET核心特点并评估不同路由协议在典型移动场景下的性能表现。压缩包共54个文件以1个prj工程文件为入口配以27个m模型文件、14个seq序列文件和12个ac辅助配置文件整体大小约296KB。文件按多组实验场景组织覆盖AODV、DSR、TORA、OLSR、GRP等主流MANET路由协议提供50节点与100节点规模、站点移动、集群网络、默认参数与降路由开销等多种仿真配置便于对比节点规模、移动性、背景流量对端到端时延、丢包率和吞吐量的影响。研究时可结合自组织、多跳通信、能量效率等真实约束分析协议在负载变化下的适应能力。目前已有838人浏览/学习适合用作OPNET仿真入门练习和MANET协议研究的基础素材。1. 别急着找资源先想清楚 OPNET 里 MANET 仿真实例到底能替你解决什么做无线自组织网络方案预研时最尴尬的情况是你需要在几个路由协议之间选型但手头只有论文里的曲线和静态的拓扑分析拿不出自己环境下的数据。OPNET 里的 MANET 仿真实例解决的就是这个拓扑持续变化带来的量化难题——节点在场景里移动、链路断开重建、路由协议重新收敛这些过程会被离散事件仿真完整记录成延迟、吞吐量、路由开销曲线。标题里这个实例包的价值不是让你跑通一个 Demo 交差而是给你一整套已经组合好的 MANET 场景无线节点模型、路由协议配置、移动轨迹、业务负载和统计量都配好了你只需要改参数、跑仿真、看对比。适合做课程设计的学生、做无线网络方案选型的工程师以及想把 Ad Hoc 协议对比做成可复现实验的开发者。但拿到资源只是起点搞不懂场景里每个模块在干什么跑完也只能得到几张说不清含义的图。2. 拆开 MANET 实例的模型栈OPNET 里哪些模块决定了仿真能不能出数2.1 节点模型manet_station 不是一台路由器而是一台完整的协议栈在 OPNET 里部署 MANET 节点最常见的模型是 manet_station。我习惯把它叫协议栈打包机因为它把应用层、传输层、网络层、MAC 层和物理层一次性打包在一个节点里。展开节点的进程域能看到 TCP、UDP、IP、MANET 路由进程、WLAN MAC以及一对无线收发机接收机 rx 和发射机 tx。这意味着你跑一次 Ad Hoc 仿真其实是在同时验证七个模块的配合。理解这一点很多配置错误就有了解释。比如有 A 同学在 manet_station 里只配了路由协议应用层什么都没挂跑完发现全网零流量。为什么因为 MANET 仿真里的数据包需要上层业务产生路由协议只负责按表转发自己不产生包。manet_station 的协议栈完整不代表它会自动帮你发包。另一个认知误区是把 manet_station 当普通路由器给它加一堆有线接口。实际上 MANET 节点默认依靠无线接口通信节点之间通过 IP 层是否可达来决定路由行为不是靠拓扑图上的连线。所以配置节点时盯住的是无线参数组而不是画布上的链路。从实操角度看我拿到一个实例场景第一步永远是先把节点模型认全先看节点属性里有哪些模块组再看每个模块组里哪些参数暴露出来了。这一遍花十分钟能避免后面所有现象无法解释的问题。MANET 仿真里的奇怪结果十个有八个不是随机数问题而是模型栈里某一层配置错位了。2.2 路由协议在 OPNET 里的真实身份进程模型与属性表MANET 实例里最核心的可变量就是路由协议。在 OPNET 中AODV、DSR、OLSR 这些协议并不是安装进去的插件而是以进程模型的形式挂在节点网络层之下的独立进程。配置入口通常在 manet_station 节点属性里的 MANET 或 Ad Hoc Routing 分组下下拉框里能看到 AODV、DSR、OLSR 等选项。这里有一个新手必踩的认知差下拉框选了 AODV不等于 AODV 真的在跑。路由协议要生效网络层IP必须知道应该把路由决策交给这个 MANET 进程。常见做法是把节点属性里 IP 协议组的配置项保持为使用 MANET 路由而不是默认的静态或动态路由。如果 IP 层设置和 MANET 协议不一致仿真能跑但所有节点之间互不可达抓包看全是路由错误消息数据业务一条都送不出去。选协议不只是选名字。AODV 和 DSR 都是按需路由OLSR 是表驱动路由它们对 Hello 包间隔、路由缓存时间、TC 消息周期的敏感度完全不同。在实例里这些参数字段都平铺在协议对应的属性组下。所以后面讲参数配置时协议类型决定结果大趋势参数取值决定曲线细节。做对比实验时这两层要分清楚不要混在一起改。2.3 移动模型为什么 Random Waypoint 是默认项以及它绑在哪一层MANET 仿真和固定网络仿真最大的区别是节点位置随时间变化、链路会断。OPNET 里控制这个行为的是移动模型最常用的是 Random Waypoint节点随机选一个目标点、按某个速度匀速移动、到达后停留一段时间再选下一个目标点。这个模型实现简单、结果可复现所以绝大多数 MANET 实例默认用它。移动轨迹在 OPNET 里的配置位置在节点属性的 Trajectory 或 Mobility 分组下。选 Random Waypoint 后会出现一组参数开始移动时间、移动速度范围、暂停时间、移动范围。速度范围可以设成 Uniform(5, 20) 这种分布也可以用 Constant 固定值。移动范围默认是整个场景节点会在边界内随机游走。我强调一下绑在哪一层移动模型挂在节点级别不是挂在路由协议里。它影响的是节点地理位置路由协议通过位置变化去判断链路可用性。所以调试时检查顺序是先看节点有没有移动再看路由协议有没有收敛最后才查业务配置。另外一个容易被忽略的点Random Waypoint 有著名的速度衰减现象长时间运行后节点平均速度会偏低。如果目标是仿真高速移动场景建议改用 Random Direction 或自定义带方向的轨迹向量而不是把 Random Waypoint 的速度范围调得很大。仿真时长有限节点可能还没跑出几次完整移动统计窗口就结束了这时曲线代表的是低速段的表现而不是你想要的高速段表现。2.4 网络拓扑与业务模型节点数、场景范围、业务强度三者要一起调MANET 实例里常见的默认配置是几十个节点、一个 1km 见方的场景。但很多人直接照搬这个规模结果发现丢包率极高或路由开销占比离谱。问题不在随机数而在三个量之间的匹配关系节点数决定网络密度场景范围决定通信距离业务强度决定信道竞争压力。举例来说同样 30 个节点放在 500m×500m 场景里节点平均距离近、链路可用性好丢包主要来自 MAC 层竞争放到 1500m×1500m 场景里平均距离拉远大量链路处于覆盖半径边缘丢包主要来自物理层不可达。这两种情况下的最优路由参数完全不同。所以拿到实例后第一件事不是改协议而是确认场景尺寸和节点数量是否匹配你想要的网络密度。一个快速检查法是算节点平均邻居数低于 3 到 5 个时任何路由协议都很难维持可靠通信。业务模型同样影响判断。实例里一般用 Application Config 和 Profile Config 定义业务比如在指定节点对之间跑 FTP 或轻量 HTTP。业务一重路由开销占比和端到端延迟都会被显著拖高。做协议对比时所有场景要使用完全相同的业务配置否则你比较的不是协议差异而是业务强度的差异。这个坑我见过太多次后面避坑章节专门展开。3. 把 MANET 仿真实例跑起来从建场景到导出结果的 6 个落地步骤3.1 新建工程与场景模板怎么选决定后面少踩多少坑以你手头的 MANET 实例资源为例常见做法是先在 OPNET 里建一个工程再新建一个场景。场景向导里如果提供无线或 Ad Hoc 相关模板优先用模板没有模板就直接选空场景从对象面板切换到 MANET 支持的模型库再拖节点。模板的价值在于它会把全局统计量、仿真时长、默认业务配置一次性初始化好减少后续遗漏。工程命名我建议直接用协议名做区分比如 AODV_scene、OLSR_scene不要在同一个场景里反复切换协议。OPNET 场景一旦建好很多统计量按场景名存储场景名混乱后面批量对比结果时会非常被动。这个命名习惯我从第一次跑 MANET 仿真用到现在没吃过亏。3.2 部署 MANET 节点并绑定移动轨迹从对象面板拖入 manet_station放置足够数量的节点然后统一选中右键编辑属性。这里有一个效率技巧先把一个节点的属性配置完整确认无误后复制粘贴出其余节点再统一微调位置和名称。逐个配置几十个节点不仅慢而且容易漏项。复制出来的节点会继承全部属性包括移动轨迹和路由协议这是批量部署最快的方式。绑定移动轨迹的操作选中节点在属性里找到 Trajectory 或 Mobility 项设为 Random Waypoint然后展开子属性。速度范围、暂停时间、移动范围这三项是必调的。速度建议按场景尺度设置小场景里速度超过 20m/s 会导致节点频繁跑出边界后掉头统计里会出现大量瞬时断链这些数据点会污染延迟曲线。配置完移动属性后建议先做一次极短仿真比如 10 秒仿真时间确认节点坐标真的在变化。这一步能提前暴露轨迹没绑上的问题省得跑完长仿真才发现。3.3 选好并激活路由协议AODV 与 OLSR 的配置入口在节点属性里找到 MANET 路由协议配置组把协议类型切到 AODV 或 OLSR。注意这一步只是选择协议进程还要同步确认网络层配置用的是 MANET 路由决策。常见做法是把两者放在一起检查一侧是协议下拉框另一侧是 IP 层转发决策配置两个都到位了AODV 才算真正激活。只改协议不改 IP 层配置是路由不生效类问题的头号来源。选 AODV 时重点看这几个参数Hello 间隔、路由表超时时间、路由请求重试次数。Hello 间隔决定邻居发现速度默认值偏保守高移动场景下建议调小路由表超时时间决定失效路由的清理速度调长了会转发到过期路径上。选 OLSR 时重点看 Hello 间隔、TC 消息周期和邻居表超时时间。OLSR 是主动协议TC 周期直接决定全网路由收敛速度和开销。一个参数技巧做对比实验时AODV 和 OLSR 的 Hello 间隔尽量保持同一数量级避免把参数差异误读成协议差异。协议类型是自变量参数尽量对齐才是干净的对照实验。3.4 配置业务负载Application 与 Profile 的绑定关系业务负载是 MANET 实例里最容易跑飞的部分。先拖入 Application Config 节点定义业务类型比如 FTP 或轻量 HTTP再拖入 Profile Config 节点把应用挂到 Profile 下面最后选中 MANET 节点在属性里把 Application 配置成支持指定 Profile。三者的绑定关系是应用定义内容Profile 定义使用方式节点决定谁在用。业务负载的两个关键参数请求间隔和包大小。请求间隔决定业务密度包大小决定单包传输时长。做低负载与高负载对比时优先调请求间隔因为它对信道竞争的影响更直接。包大小影响的是分片和重传行为调它容易把问题引入 MAC 层那是另一个深坑。初次跑实例时先用低负载把链路跑通确认路由和移动都正常再加负载。直接上高负载结果里全是拥塞和冲突你分不清是协议问题还是业务强度问题。3.5 选择统计量全局统计与节点统计分开看运行仿真之前先把统计量选好。常见错误是仿真跑完再去找统计量结果发现某些指标没勾选只能重跑。我一般会同时勾两组全局统计里选路由开销和端到端延迟节点统计里选 WLAN 的吞吐量和丢包率。全局统计回答网络整体表现如何节点统计回答某一跳链路是否健康。两组合起来才能判断现象是协议层面的还是链路层面的。举例来说端到端延迟高全局能看出来但延迟是排队导致还是重传导致要看节点的队列长度和重传次数。勾完统计量后在场景上确认统计量列表里能看到MANET 相关统计这一层级确认协议进程的统计量真的暴露出来了。有些实例包会把路由统计默认关闭不在这一步打开后面导出结果时你会发现自己只有业务延迟没有路由开销对比实验的结论单薄一半。3.6 运行 DES 并导出数据时长、种子与结果输出配置好仿真后进入 DES 设置项把仿真时长设置成业务稳定运行的分钟数比如 600 秒仿真时间。注意仿真时长是模型世界里的时间不是墙钟时间。仿真种子建议跑多个比如 5 个种子最后结果取平均做对比时曲线不会因为单次随机性失真。前期调试用短时长和单种子快速验证逻辑确认无误后再加长时长和多种子跑正式数据。仿真结束后在 View Results 里查看曲线。需要导数据时右键曲线图选择导出为文本或表格文件。导出的数据是带时间戳的序列。我习惯用一个小的批处理把每次运行的结果归档避免后面对比时找错文件for scene in AODV_scene OLSR_scene; do mkdir -p results/$scene cp $scene/packet_delay.txt results/$scene/ 2/dev/null cp $scene/throughput.txt results/$scene/ 2/dev/null done这个脚本做的事是把每个场景跑出来的延迟和吞吐量结果按场景归档到 results 目录。cp 命令的源路径取决于你导出文件时保存的位置实际使用时换成你导出文件所在的目录。2/dev/null 的作用是忽略不存在的文件报错因为不同版本导出的统计量文件名会有差异先跑通归档流程再回头补缺失项。导出数据时还有一个小习惯每个统计量文件里通常带注释行以 # 或引号开头解析时要把这些行过滤掉这个细节留到第六章的脚本里处理。4. 一份可以照抄的 MANET 仿真参数表无线、路由、业务、仿真四层4.1 无线参数数据速率、发射功率与接收门限的匹配关系MANET 节点之间的通信质量主要由三组无线参数决定。数据速率决定单包传输时间发射功率决定覆盖半径接收门限决定误码容忍度。三者必须匹配发射功率调大但接收门限不变覆盖半径变大但接收灵敏度没变边缘链路的实际吞吐反而是下降的。我见过有人只调功率不调门限结果丢包率不降反升这类问题最难查因为参数本身看起来都是合理的。参数常用初始值调整方向观察指标数据速率11 Mbps802.11b 基线高移动场景可降至 5.5Mbps吞吐量、重传次数发射功率0.005 W约 20dBm节点密度低时增大丢包率接收门限-95 dBm 左右边缘链路多时收紧误码率、丢包率信道频率2.4 GHz不做对比实验时别改干扰水平这里提醒一句发射功率不是越大越好。功率大覆盖远但信道竞争范围也变大相距较远的节点对之间会互相干扰。做参数扫描时功率按倍数步进而不是线性步进效果更容易看清。无线参数的核心思路是先确定你想要的覆盖半径再反推功率和门限而不是先给个功率看结果。4.2 路由协议参数AODV 的 Hello 间隔与 OLSR 的 TC 周期AODV 属按需路由只在需要通信时才发起路由发现。它的关键参数是路由请求RREQ重发次数和路由表超时时间。重发次数太少弱链路环境下路由发现成功率低太多广播风暴会把低带宽信道打满。我一般从默认值开始把重发次数加一倍同时在低负载场景下验证开销增量再决定要不要保留。OLSR 属表驱动路由全网节点周期性交换 Hello 消息和 TC 消息。Hello 间隔决定邻居发现精度TC 周期决定全网拓扑同步速度。TC 周期越短路由收敛越快但控制开销越大。高移动场景下TC 周期缩短带来的收益往往比调 Hello 间隔更明显因为 OLSR 的路径质量依赖全网拓扑的新鲜度。下表是我在一组模拟场景里用过的初始参数可以直接抄协议参数低移动场景建议高移动场景建议AODVHello 间隔默认值缩小约一半AODV路由表超时默认值缩短避免过期路径OLSRHello 间隔默认值保持或略缩OLSRTC 周期默认值缩短到一半以内OLSR邻居超时默认值按 Hello 间隔比例同步做协议对比时有个原则除了协议类型这个自变量其他参数尽量对齐。AODV 的 Hello 间隔和 OLSR 的 Hello 间隔如果差一个数量级你得出的差异可能是参数差异而不是协议差异这个结论拿到评审会上会被一句话问倒。4.3 业务参数发包间隔比包大小更影响结果MANET 仿真的业务参数里发包间隔对结果的影响远大于包大小。原因是 MANET 信道是共享的每个节点都在竞争同一片频谱。发包间隔短同时竞争的业务流就多MAC 层退避和重传显著增加。包大小主要影响单次传输时间和分片概率在大包场景下才需要重点关注。业务参数低负载中负载高负载请求间隔2-5 秒1 秒左右0.2-0.5 秒包大小512 字节1024 字节1024-1500 字节连接数5 对10 对15 对以上做协议对比时业务参数在所有场景里保持一致这是对照实验的基本要求。如果你发现两个协议曲线差异巨大先检查业务配置是否被某个场景的 Profile 覆盖了。这个错误很隐蔽因为场景复制时 Profile 配置可能被带了过去但节点的支持 Profile列表未必同步更新。检查方法是选中节点看属性确认每个节点挂的 Profile 名字完全一致。4.4 仿真控制参数时长、种子与预热期仿真控制参数是最容易被忽略的一层。仿真时长太短业务还没进入稳定状态曲线就结束了太长一台机器要跑好几个小时。种子数决定随机性覆盖多个种子取平均才能压掉单次随机性的噪声。预热期让路由协议完成邻居发现和路由表建立这期间的数据不应该计入统计。我一般这样配仿真时长 600 秒前 60 秒算预热期种子至少 5 个路由协议的统计量在全局统计里打开业务级别统计在节点统计里打开。前期调试用短时长单种子确认逻辑无误后再用长时长多种子跑正式数据。两种参数配置分开存用场景名后缀区分比如 AODV_scene_dbg 和 AODV_scene_final避免正式跑的时候误用了调试参数。5. MANET 仿真实例避坑指南5 个让我白熬一周夜的坑5.1 节点一动不动移动轨迹配了等于没配现象仿真跑完动画里所有节点静止在原地生成的轨迹图上节点位置始终不变。但节点属性明明选了 Random Waypoint。原因有两种。一是移动属性配在了节点上但仿真运行视图的轨迹刷新被关闭节点其实在动只是画面没更新二是移动配置层选错了某些版本里节点属性存在两个移动相关的层级一个是轨迹向量一个是漫游配置只填了其中一个进程根本没读取到。解决先确认视图设置里开启了轨迹显示再看属性层级。我习惯在节点属性里直接搜 mobility 关键词把所有移动相关属性摊开逐一检查。确认无误后用极短仿真时长比如 10 秒快速验证节点坐标是否变化比直接跑长仿真节省大量时间。这一步放在场景配置完成后立刻做不要等到正式仿真跑完才发现。5.2 路由协议选了但没生效协议与网络层配置不匹配现象节点属性里选了 AODV仿真跑完发现全网数据包投递率几乎为零但路由进程的统计量里有事件发生。原因MANET 协议进程在跑但 IP 层没有把路由决策权交给它。IP 层可能还在用静态路由或默认路由导致 AODV 计算出的下一跳根本没被用于转发决策。解决把节点属性里 IP 层相关配置改为使用 MANET 的转发决策同时确认协议进程绑定的模块是网络层对应的那个进程槽位。不同版本里这个配置项的路径不一样但关键词基本是 IP 和 MANET 的组合。排查时用抓包或路由表视图看一下节点上有没有生成去往目的地的动态路由条目能直接确认协议是否生效。这个检查比看统计量更快更准。5.3 仿真结果全为零统计量没勾对或者采集窗口太短现象仿真正常结束、无报错但延迟和吞吐量曲线全是水平直线数值为零。原因统计量根本没勾选或者业务在预热期结束后还没开始发包采集窗口内就没有数据包被统计到。解决打开统计量配置重新勾选全局统计里的路由延迟和 WLAN 吞吐量。同时检查业务 Profile 的起始时间确保业务在统计采集窗口内已经激活。我踩过一次最冤枉的业务 Profile 配置里起始时间设了 1000 秒仿真只跑了 600 秒整个仿真期间业务从未启动所有业务统计量当然为零。这个参数在节点属性里不显眼但极其致命。查看方式选中业务源节点展开 Application 属性看 Profile 的起始时间和持续时间。5.4 高丢包却不报错覆盖范围与节点密度失配现象仿真能跑、业务也能发但端到端丢包率高达 50% 以上而且不同随机种子之间差异巨大。原因场景尺寸和节点数量不匹配。场景范围太大节点通信覆盖半径覆盖不到几个邻居路由发现经常失败场景范围太小所有节点都在互相的干扰范围内信道竞争导致大量冲突丢失。解决先做连通性检查。统计节点平均邻居数MANET 仿真里平均邻居数低于 3 到 5 个时链路层基本处于不可靠状态任何路由协议都救不回来。根据这个指标反推场景尺寸邻居太少就缩小场景范围或增加节点数邻居太多就适当降低业务强度。记住一个原则路由协议解决的是选哪条路的问题解决不了这条路根本不存在的问题。这个坑的隐蔽之处在于没有任何报错你只会看到很高的丢包率容易误判成协议问题。5.5 场景数量一多就跑不动DES 的 Sim Efficiency 与内存取舍现象单个场景仿真很快但批量跑多个场景时后面的场景越跑越慢某几个场景甚至卡死几个小时。原因OPNET 的离散事件仿真DES有一个 Sim Efficiency 设置项它控制事件处理的优化程度。某些参数组合下模拟可能退化成逐事件模拟速度急剧下降。另外场景数量多但内存有限系统开始用交换分区仿真速度会断崖式下跌。解决批量跑之前把所有场景的 Sim Efficiency 统一设置到同一档保证对比公平也避免个别场景设置差异导致耗时爆炸。内存方面我习惯一次只打开一个场景运行或者按顺序批量跑而不是同时开多个工程。如果单个场景节点的进程特别多先检查业务负载是否太高高负载会让事件数量指数增长这时候减少节点数比加内存更有效。这个坑最磨人单个场景跑起来一切正常批量跑才会暴露且报错信息几乎没有只能靠观察资源占用和耗时长来判断。6. 让实例真正值钱的收尾动作用多场景批量对比 AODV 与 OLSR到这里单场景的仿真链路已经通了但实例的真正价值要等对比实验跑完才体现出来。我建议把 AODV 和 OLSR 各复制一个场景出来分别改协议类型业务参数和无线参数保持完全一致然后批量运行最后用脚本汇总结果。复制场景常见做法是使用场景管理功能右击场景标签复制场景改名为 OLSR_scene然后在这个副本里只动路由协议这一项。这一点非常重要——只动自变量其他全部不动。如果你连节点数量或业务 Profile 都改了后面任何差异都解释不清。复制完场景后逐个确认移动轨迹、业务配置、统计量勾选是否和原场景一致这三项是场景复制时最容易丢配置的地方。跑完后把每个场景的导出文件汇总到一张对比表里。下面这个 Python 脚本是我常用的汇总方式假设每个场景导出了 packet_delay.txt 和 throughput.txt 两个文本文件每行是时间 数值import glob def load_numeric(path): xs, ys [], [] with open(path, encodingutf-8, errorsignore) as f: for line in f: line line.strip() if not line or line.startswith(#): continue parts line.split() if len(parts) 2: continue try: x float(parts[0]) y float(parts[-1]) except ValueError: continue xs.append(x) ys.append(y) return xs, ys def avg(ys, skip0): seg ys[skip:] if skip 0 else ys return sum(seg) / len(seg) if seg else 0.0 for path in glob.glob(results/*/packet_delay.txt): xs, ys load_numeric(path) print(f{path.split(/)[1]:20s} delay_avg{avg(ys):.4f} n{len(ys)})这个脚本做了三件事按行读取文本结果跳过以 # 开头的注释行和解析失败的噪声行取每行最后一个字段作为数值计算平均延迟跳过预热期数据。split() 解析依赖文件用空格分隔时间与数值如果你的导出文件是 CSV 格式把 line.split() 改成 line.split(,) 即可。glob.glob 里的路径按你实际归档目录调整。把这个脚本稍加扩展把 throughput 也读进来就能生成一张AODV和OLSR在延迟、吞吐量、丢包率上的对比表。对比时先看总体趋势再看参数敏感度比如高移动场景下 AODV 的延迟峰值出现在什么时刻、OLSR 的开销曲线是否平坦。这一步跑完你手里的就不再是实例包照跑了一遍而是一组能支撑结论的完整证据。最后说一个我自己的教训曾经做协议对比跑完发现 AODV 场景的延迟单位是毫秒OLSR 场景的延迟单位是秒两个场景的统计量单位不一致直接对比得出了完全错误的结论。从那以后我每次跑完第一件事是看统计量的单位列确认两边一致再谈对比。这个动作花不了十秒却能避免把整周的仿真结果变成废数据。如果你手里的 MANET 实例资源还躺着没动我的建议是别急着把它当黑匣子跑一遍就交差。照着这里的步骤拆一遍模型栈、配一遍参数、跑一次对比你会发现协议选型的说服力比翻十篇文献都实在。希望帮到你。本文还有配套的精品资源点击获取
