IPv6地址规划方法论：路由聚合、HD门限与过渡技术避坑指南

简介：《IPv6地址规划方法》文档系统总结了IPv4地址耗尽后IPv6地址规划的科学方法，面向网络规划工程师、运营商技术管理者及高校网络专业学习者，可帮助解决路由膨胀、地址利用率低、管理溯源难等现实问题。压缩包内仅含1个doc文档，约59KB，体量紧凑但要点集中，目前已有222人学习。文档从IPv6地址的全球路由前缀、子网标识和64位接口标识符三层结构出发，提出按骨干网、省网、城域网层次分配地址，在64位前缀中承载地理位置、客户信息和业务类别特征，以增强路由聚合能力；同时引入哈希源地址验证、地址预留比例、顺序或稀疏分配算法、主机密度比率HD等方法，讨论避免语义过载、预留增长空间、及时回收空闲地址段等策略，并对比不同分配算法在各类网络规模下的适用性。读者可据此形成一套兼顾可管理性与可持续发展的IPv6地址规划方案，对实际网络的IPv6部署和未来扩容具有直接参考价值。

1. IPv6 地址规划：IPv4 耗尽后，先决定“怎么切蛋糕”

全球 IPv4 地址池耗尽这件事，今年初已经被 ICANN 和 APNIC 的分配数据证实了，亚太地区成为第一个无法满足新增 IPv4 需求的区域，国内运营商手里的地址只会越来越紧张。我拆这份《IPv6 地址规划方法》时有个很深的感触：多数人以为 IPv6 是“地址多到用不完”，但现实恰恰相反——无规划地给每个终端撒一个 /64、给每个家庭撒一个 /48，地址浪费速度比 IPv4 时代还快，路由表膨胀问题也会原样复制到 IPv6 上。这份文档的价值不在于教你在路由器上敲几行命令，而在于把“IPv6 全面部署前怎么切蛋糕”的方法论讲透了：路由聚合、地址语义、分配算法、组播过渡、DNS 改造，每一块都有取舍逻辑。适合正在做城域网、园区网或 IDC 改造规划的技术人员，也适合刚接手 IPv6 项目、想避开前人踩过的坑的同行。

2. 路由聚合与地址碎片：IPv6 规划的起点不是“够用”，而是“别重蹈 IPv4 覆辙”

2.1 IPv4 留给 IPv6 的三笔债

拆这份文档时，开头几段其实就在复盘 IPv4 的教训。互联网发展初期缺少对地址规划重要性的认知，直接导致三个后果：一是路由膨胀——地址分配缺乏层次结构，大量地址碎片进入 BGP 路由表，路由器 CPU 和内存被无谓消耗；二是地址过早耗尽——32 位地址空间在移动互联网和三网融合面前完全不够用；三是无法有效管理——地址与用户、业务、地理位置没有对应关系，攻击溯源和安全管理只能靠事后人工查。

这三笔债恰好是 IPv6 规划的三个目标。IPv6 把地址从 32 位扩到 128 位，空间不再是瓶颈，但“没有层次结构的分配”一旦在 IPv6 上重演，路由表的膨胀速度只会比 IPv4 更快，因为可用前缀更多、分配的随意性也更大。文档里反复强调的“减少网络地址碎片、增强路由聚合能力”就是这个意思。具体到执行层面，核心动作只有一个：给地理上属于同一范围的子网分配连续的前缀，让路由表能按大段聚合。常见做法是把网络分成骨干、省网、城域网、接入网四层，每一层只向上一层宣告聚合后的前缀，而不是把分散的用户段一个个甩到核心设备上。

2.2 128 位里哪些位可以自己定义

要用好 IPv6 地址空间，先得弄清楚 128 位里哪些是国际机构定的、哪些是规划者能改的。文档给出了明确的三段式结构：全球路由前缀、子网标识、64 位接口标识符。前两者合起来覆盖从第 1 位到第 64 位，其中全球路由前缀由 ICANN、APNIC 这类机构分配；前缀到第 65 位之前的剩余比特位，可以由规划机构、运营商自行划定含义；64 位接口标识符到目前也没有全球统一规则，规划时可以整体利用。

实际操作中，我一般会在拿到 ISP 分配的 /32 或 /48 后，先画一张位分配表：

有位分配表做底，才能把“地理信息写进地址”“业务类型写进地址”这些诉求落到位。做规划时我会先固定一个原则：省与省之间、城域网与城域网之间，不要互相穿插地址段，每一层的子网标识都按数字递增并预留扩展位，否则后续做聚合和 renumber 会非常痛苦。

2.3 地址语义设计：在地址里放位置、业务还是安全信息

IPv6 地址能承载的信息，文档总结了三大类，这也是规划时最需要花时间决策的部分。

第一类是位置信息。根据骨干、省、城域的层次结构分配前缀，使地址本身能体现地理位置，好处是路由聚合能力强、系统稳定性好，便于实现最短路径寻址。这一条几乎适合所有基础网络，也是文档判定为首要任务的方向。

第二类是客户与业务信息。根据用户接入方式携带标识信息，必要时能直接查询用户身份；边缘设备在子网划分时同步完成业务标识注册和策略设置，终端按业务类型拿到对应 IPv6 地址。优点是天然支持 QoS 保障和用户溯源，缺点是业务类型划分很难做到全网统一，而且需要对现有协议做升级改造。

第三类是源地址验证。用哈希算法为源 IPv6 地址生成验证信息，放进源地址验证选项里，管理节点可以据此检验源地址真实性，能有效缓解地址欺骗、身份假冒、拒绝服务这些攻击。但代价也很明显：要占大段地址空间，而且实现机制复杂。

三类方案不是三选一，而是按优先级叠加。文档给了很实际的建议：不要追求“什么信息都塞进地址”，否则会引发语义过载，降低地址利用率，也降低设备的配置灵活性。

2.4 语义过载的取舍：什么信息该带、什么不该带

我拆到这里的时候，觉得这是全文最有工程价值的一段。很多人拿到 IPv6 第一反应是把能想到的信息都编码进地址：地域、运营商、接入方式、业务类型、用户 ID、终端型号……但地址位一旦被业务语义占用，就很难再改，而且会直接限制未来新技术的部署。这种“过载”在 IPv4 里没机会出现，因为位不够；在 IPv6 里位够了，反而更容易踩进去。

文档给出的取舍方案是两个信息必带：位置信息和用户身份标识。位置信息用于路由聚合，这是 IPv4 时代留下的最大教训；用户身份标识用于溯源和安全管理，把 IPv6 地址变成管理抓手。至于 QoS 标记、源地址验证哈希这类信息，可以作为附加方案局部使用，但不要作为全网统一标准。落实到规划里，我会把子网标识段按“省份—城市—接入域”切分，把接口标识段的规划重点放在用户身份映射上，而不是一上来就设计复杂的业务编码方案。这样即使后续业务模型变化，前缀结构也不用推倒重来。

3. IPv6 地址划分实操：前缀拆分、保留率、分配算法与 HD 门限

3.1 从骨干到接入：/48 起步的层次化切分

IPv6 地址规划和 IPv4 规划有个本质差异：IPv4 是省着用，IPv6 是先按结构铺开再逐级细化。文档里给出的典型口径是：家庭网络以 /48 为单位分配前缀，移动通信网络以 /64 为单位为每个 PDP 上下文分配地址前缀。这当中隐含的切分逻辑，值得做一张表记清楚。

以拿到一个 /32 为例（国内运营商申请时通常按 /32 起步），从骨干到接入可以按这样的粒度切：

移动网络每个 PDP 上下文按 /64 分配，相当于 IPv4 时代每次拨号给一个完整子网，这种分配方式的地址利用率非常低。文档点出这个问题，目的不是否定 /64，而是提醒规划者：既然 /64 是 SLAAC 和 IPv6 协议正常工作的前提，那就必须在网段划分时把“必然的浪费”算进预留策略里，而不是事后发现地址不够用。

3.2 100% 与 300% 保留率：预留多少地址才够用

地址预留是规划里最容易被低估的一环。网络规模增长、用户迁移、新业务上线，都会在几年内吃掉大量地址空间；如果按当前需求精打细算地分配，两三年后又得做二次规划。文档引用了巴西的 IPv6 地址分配经验：尽量遵照 100% 或 300% 的保留率。意思是：当某区域当前实际需求是 N 个 /48 时，规划分配时按 2N 或 4N 预留，把未分配空间留在同一个地址池里，而不是散落在各个段的中间。

这里还有个容易混淆的点：保留率不是“每个用户多给几个地址”，而是“地址池相对当前已分配量的冗余”。我见过的翻车案例是：规划时给某个城域网预留了 100% 冗余，但预留位没有连续放在地址池尾部，而是均匀撒在多个 /40 段里，结果后续增长时新段和旧段无法聚合，路由表还是膨胀了。正确的做法是：按“当前已规划量 ×（1 + 保留率）”算出该区域的总空间占用，再从空闲池里按顺序切出整段，保证已分配前缀和预留前缀在拓扑上连续。

3.3 两种分配算法怎么选：顺序分配与稀疏分配

文档专门比较了两种地址分配算法。顺序分配（sequential allocation）直观、简单、地址连续性好，后续要做路由聚合非常容易；但它有个硬伤——如果网络中有多个用户连续申请地址，或者某个用户突然申请一大块地址，顺序分配会难以容纳，导致地址空间碎掉。稀疏分配法（sparse allocation）把空间均分给多个用户，聚合性比较好，但对不同规模用户的适应性差：小用户拿到大段地址造成浪费，大用户申请时空间不够，还会出现不必要的地址冲突和空间分段。

实际选型时，我给三条经验：骨干和城域网之间用顺序分配，因为这一段层级清楚、参与者少、增长可预期；用户接入段用稀疏分配，因为用户规模差异大、增长不可控，稀疏分配能避免频繁重排；混合网络要显式声明“哪一层用哪种算法”，并把算法选择写进地址规划文档，否则后续维护的人无从下手。文档里提到的“周期评价地址消耗速度、及时释放需求少的用户地址段”，也依赖这种分层策略——只有能明确判断某段属于哪个业务域，才能在业务萎缩时安全回收。

3.4 用脚本算 HD：评估地址空间利用率

HD（Host Density，主机密度比率）是文档给出的地址利用率评价指标，公式为：HD = log(已分配目标数) / log(最大可分配目标数)。以 /48 为例，如果按 /64 细分，最多可分配 65536 个 /64 子网；某城域网已经分配了 8800 个 /64，那么 HD 值可以用下面这段脚本算出来：

import math def hd_ratio(allocated: int, max_allocatable: int) -> float: """ 计算 IPv6 地址段的主机密度比率 HD :param allocated: 已分配的目标数量（例如已分配的 /64 子网个数） :param max_allocatable: 该段内最大可分配的目标数量（例如 /48 内可容纳 65536 个 /64） :return: HD 值 """ return math.log(allocated) / math.log(max_allocatable) # 以一个 /48 段为例，细分到 /64，最多 2^16 = 65536 个 /64 子网 max_subnets = 2 ** 16 allocated_now = 8800 # 当前已分配 /64 数量 ratio = hd_ratio(allocated_now, max_subnets) print(f"当前 HD = {ratio:.3f}") print(f"HD 是否达到 0.8 门限: {ratio > 0.8}")

脚本逻辑简单，但参数含义要注意：allocated是“已分配目标数”，不是“已分配地址数”。如果拿一个 /48 段，目标粒度是 /64，那么最大可分配目标数就是 65536；如果拿一个 /40 段做评估，目标粒度同样是 /64，最大可分配目标数就变成 2^(64-40) = 16777216。计算时两个参数必须同粒度，否则 HD 值没有可比性。

文档推荐的 HD 门限是大于 0.8。为什么要卡这个值？因为 IPv6 不像 IPv4 可以 NAT，地址一旦分配出去就很难收回，HD 超过 0.8 说明这段地址的利用率已经接近合理上限，继续分配给新用户会显著增加碎片化风险。这时候的正确动作不是硬塞，而是向上一级申请一段新区，同时把旧段里长期不用的地址做回收评估。我一般会在规划文档里直接给出各段 HD 的季度统计表和触发申请的逻辑：> 提示：HD 只是门限，不是实时利用率。它衡量的是“一个段里目标子网用了多少”，核心目的是判断何时需要申请新段，别把它当成监控指标每时每刻盯着。

4. IPv4-IPv6 组播过渡与 DNS 改造：双栈、转发器、网关和三种解析记录

4.1 过渡期的三个现实约束

IPv6 部署初期的最大误判，是认为“新网络可以整体替换旧网络”。文档明确指出：纯 IPv6 网络会区域性出现，但大量 IPv4 节点会因为业务稳定而继续存在，纯 IPv4、纯 IPv6、双栈网络会长期交错共存。对组播业务来说，这个共存期有三个现实约束，规划时必须考虑。

第一，双栈不是万能的。把源站配置成双栈、同时向 IPv4 组播组和 IPv6 组播组发送数据流，只适用于源少、封闭环境的场景。到了视频会议这种多方收发的场景，一部分参与者是纯 IPv4、另一部分是纯 IPv6，双栈只能保证源能发包，保证不了两端能互访；而且同时发两份组播流量，带宽消耗直接翻倍。第二，隧道技术都基于双栈，纯 IPv6 主机和纯 IPv4 主机之间无法通过隧道直接通信。第三，组播协议（IGMP/MLD、PIM）本身是分协议的，跨协议转换必须落在网络层或传输层，绕不开报头转换和地址映射的设计。

这三点决定了：过渡方案选型，先看业务有哪些参与者、支持什么协议栈，再决定要做协议转换还是双协议并行。文档在地面工程里最常见的做法是：内容分发这类单向流量用双栈，多方实时互通用网关转换。

4.2 组播过渡方案对比：转发器、网关、6over4 与 ALM

文档梳理了四种组播过渡方案，各自适用的场景差异很大。转发器（Reflector）工作在传输层，从一个组接收数据再重新发送到另一个组，典型例子是 VRVS 视频会议系统；它的实现最简单，但性能较差，每个会话都要启用一个实例，即使没有接收者也在执行转发，只适合会话数量有限的场景。网关方案则把网络地址转换的思路搬到组播上，把 IPv4 组播地址通过加“/96”前缀嵌入 IPv6 地址，建立一一映射关系，能真正实现 IPv4 与 IPv6 组播组的相互通信，代价是会对组成员和源的有效期不敏感。

6over4 是把 IPv4 网络当作一条具有组播功能的链路，通过 IPv6 组播地址与 IPv4 组播地址的映射实现邻居发现，但它本身在大规模部署里就没成功过，组播场景下很少被提及。应用层组播（ALM）在应用层构建叠加网，过渡问题最终归结为单播 IPv6 过渡，反而回避了组播转换本身。

4.3 MTG 报头转换：哪些字段等值映射、哪些字段走地址池

文档给出的 MTG（多播转换网关）模型，是目前把网关方案做得最完整的一个原型：部署在 IPv4 和 IPv6 网络边界，IPv4 侧用组播代理（MP4）参与 IGMP，IPv6 侧用组播代理（MP6）作为组播路由器和 RP，中间由组播协议转换器（MT）做报头转换，地址映射器（AM）维护地址池和映射表。关键转换逻辑集中在下面这张表：

执行层面要特别留意两处。一是源地址的转换：非 SSM 场景下，MTG 是“所有 IPv4 数据的重发源”，可用一个固定 IPv6 地址；但 SSM 场景下同一个组可能对应多个源，固定地址无法区分，必须从地址池为每个源分配独立地址，并在映射表登记。二是宿地址的转换：IPv4 组播地址转 IPv6 时用 FFxy::/96 做前缀，低 32 位保留原组地址，x 和 y 按组播管理域规则填值；反过来 IPv6 转 IPv4 时，必须根据 x/y 确定地址类型，再去地址池申请 IPv4 组播组地址，这个申请到的组地址往往和源地址一样，需要同时检查是不是和本地已有组播组冲突。

4.4 DNS 正向与反向解析：AAAA、A6 与 ip6.arpa 的取舍

组播过渡解决的是业务连通，DNS 改造解决的是地址和名字的映射。IPv6 DNS 的正向解析有两种资源记录：AAAA 和 A6。AAAA 是对 IPv4 A 记录的简单扩展，把域名映射到 128 位地址，不支持层次化；A6 则把一个 IPv6 地址拆成多段地址链，每段是一个 A6 记录，支持地址聚集和 renumber（改 ISP 时只要改前缀对应的那一段记录）。文档明确指出了二者的取舍：A6 地址链需要多次递归查询，任何一个环节失败都解析不出完整地址，所以实际部署中 AAAA 是主流，A6 只在需要地址链场景下局部使用。

反向解析也有两种格式：Nibble 格式对应 AAAA 记录，域后缀是 IP6.INT，地址的每个十六进制位逆序排列、用点分隔；Bit-string 格式对应 A6 记录，域后缀是 IP6.ARPA，用二进制串表示并支持 DNAME 委派。BIND 9 已经同时支持这两种格式。规划落地时，我的建议是：正向记录以 AAAA 为主，反向区域直接按 Nibble 格式在 IP6.INT 下建模，只有在明确需要地址链和自动 renumber 的场景才引入 A6 与 Bit-string。简单说——能少一环节就少一环节，IPv6 刚上线时，DNS 链路上的故障点越少越好。

5. IPv6 地址规划常见排查与避坑：四个最容易翻车的现场

5.1 无状态自动配置导致“前缀碎片化”

现象 →某城域网部署 SLAAC 后，BRAS 上出现了上千条零散的 /64 用户段，核心路由器 BGP 表里同一个城域网的前缀条目比规划预期多了近十倍，路由聚合形同虚设。

原因 →SLAAC 本身要求每个链路上有 /64 前缀，终端会根据 RA 通告自动生成地址。如果接入层规划时没有按“楼宇/OLT → 汇聚 → BRAS”做连续分配，而是按业务开通顺序随手从大段里挑一个 /64 下发，地址碎片就从接入层一路传染到核心路由表。这是地址分配缺乏层次结构的典型后遗症，和 IPv4 时代的“地址碎片进入 BGP 路由表”是同一种病，只是换了个协议发作。

解决 →重新按拓扑切分：一个 OLT 区域分配连续的一段 /56，一个汇聚区域分配 /48，一个城域网段内不允许跨层跳号分配；每分配一个 /64，先确认它的父级 /48 和 /40 归属，任何跨段的分配都视为故障处理。做这步时会发现，前期没有留足预留位的网络会非常痛苦，所以新规划必须把“连续”和“预留”当成硬性约束写进分配系统，而不是依赖人工判断。

5.2 HD 算错：把前缀数量当成子网数量，结论直接反转

现象 →用脚本评估某个 /40 段时，把“已分配的 /48 前缀数”当成已分配目标数，算出来的 HD 不到 0.3，规划部门据此判定利用率不足，拒绝申请新段；但实际按 /64 粒度计算，该段已分配的子网数对应的 HD 已经超过 0.85，早就该申请新段了。

原因 →HD 公式里的“已分配目标数”和“最大可分配目标数”必须同粒度。很多人习惯拿“前缀数量”作为目标数，但 /40 段里可分配的 /64 子网数是 2^(64-40)，可分配的 /48 前缀数是 2^(48-40)，两者分母差了 2^16 倍，算出的 HD 自然南辕北辙。逻辑混乱的根源在于没有在规划文档里固定“目标粒度”。

解决 →我的习惯是全网统一以 /64 作为目标粒度，不管是评估 /40 段还是 /48 段，分子和分母都用 /64 数量。脚本里先算出段内最大可分配 /64 数，再统计当前已分配 /64 数，最后同底求对数。HD 只用作申请新段的门限参考，不承担实时监控职能；每个季度按这个口径复核一次，数值异常降低时优先排查统计口径，而不是怀疑网络出了问题。

5.3 A6 地址链解析超时，DNS 反而拖慢 IPv6 体验

现象 →全网启用 A6 记录后，用户首次访问 IPv6 站点经常要等 3～5 秒，部分地区的递归服务器直接解析失败，页面反复超时，业务部门把问题报到了规划组。

原因 →A6 地址链的本质是“把完整 IPv6 地址拆成多段，放到不同区域的多台 DNS 服务器上，解析时必须逐级查询、逐段拼接”。这个设计虽然支持地址层次和 renumber，但每加一级查询就多一次 RTT 和一次故障点；父区域的 A6 记录一旦被误删或超时，整个链就断了。文档里其实已经点过这个缺陷，但在真实网络里它的放大效应比预想更严重——跨省查询时，每一级都要跨运营商，延迟会成倍叠加。

解决 →IPv6 上线阶段，正向解析统一退回 AAAA，不再新建 A6 地址链；已经在用的区域把 A6 记录同步生成 AAAA 副本，过渡期结束后逐步停用 A6。与次同时，把反向区域 IP6.INT/ip6.arpa 的委派检查纳入验收清单，确保每个地址段的反向解析都能从根区一路查到目标服务器。吃过这次亏之后，我所有规划文档里都固定写一条原则：DNS 链路上的环节越少越好，层次化是给路由用的，不是给域名解析用的。

5.4 组播网关的地址映射冲突，RPF 检查失败导致数据不可达

现象 →部署 MTG 做 IPv4/IPv6 组播互通的视频会议中，部分 IPv4 成员在会议开始后一段时间收不到数据流，或者收到重复的组播报文，抓包发现源地址和预期不符。

原因 →这类问题集中在两个映射环节。一是 SAP 会话地址转换：IPv4 的 SAP 全局地址 224.2.127.254 被映射成 FF0E::2:7FFE 后，如果 IPv6 网络里已经存在同组地址的静态配置，新映射就会冲突。二是 SSM 场景：多个源被转换后，如果统一使用 MTG 的固定地址作为源，路由器做 RPF（逆向路径转发）检查时发现源地址的入接口和实际接收接口不一致，直接丢弃报文；必须从地址映射器的地址池为每个源分配独立地址并注册，才能通过 RPF 检查。

解决 →部署 MTG 前，先把 AM 地址映射表同步到所有组播路由器，把已注册的组播组和源地址段做一次全网比对；SSM 源的地址池独立规划，不允许与固定单播地址复用；在组播路由器上放行映射表里的源地址段，并确认 RPF 检查的接口指向 MTG 所在的边界。> 注意：MTG 这类网关方案最大的坑不在转换字段本身，而在地址映射表与全网路由状态的一致性，映射表没有同步到所有设备之前，不要急着开业务。

6. 规划之后：路由表、DHCPv6 租约和 DNS 三招验证地址方案

6.1 在核心路由器上看前缀聚合是否收敛

规划做得再漂亮，最终要落在路由表上。我的习惯是先上核心路由器，把本 AS 宣告的 IPv6 前缀全部导出来，按前 32 位或前 36 位分组统计。在 H3C 或 Cisco 设备上，核心命令格式类似这样：

# 查看本 AS 宣告的 IPv6 前缀（华三设备） display bgp ipv6 unicast routing-table | include 2409: # 按段聚合后检查前缀数量是否符合规划预期 display bgp ipv6 unicast routing-table statistics

正常状态下，一个城域网应只向上层宣告 1～2 条聚合前缀；如果发现同一城域网被拆成几十条 /40 或 /48 宣告，说明接入层的地址分配已经碎片化，需要回查分配记录。这一步也是检验“地址碎片治理”有没有做到位的单一观测点。

6.2 用租约文件和 netsh 命令核对终端实际拿到什么

地址规划是一回事，终端实际拿到什么是另一回事。DHCPv6 场景下，直接统计租约文件里的前缀分布就能看出问题；SLAAC 场景下，在 Windows 终端上执行下面两组命令最直观：

# 查看前缀策略优先级（Windows） netsh interface ipv6 show prefixpolicies # 查看实际分配的 IPv6 地址及前缀长度 ipconfig /all | findstr /i "IPv6"

重点核对两件事：终端拿到的前缀长度是否和规划一致（家庭用户是否为 /56、移动会话是否为 /64），以及前缀的父级归属是否落在正确的城域网段内。经常发现的问题是：DHCPv6 服务配置正确，但接入设备做了二次地址转换，导致终端拿到的前缀和规划段不符——这类问题用租约文件一查就能定位。

6.3 用 dig 验证 AAAA 与 PTR 双向可达

DNS 侧的验证，我会用 dig 同时测正向和反向：

# 正向验证 AAAA 记录 dig @2001:db8::53 主机名 AAAA # 反向验证 PTR 记录（从 IPv6 地址解析主机名） dig -x 2001:db8::1

正向要求返回的 AAAA 记录与地址规划表完全一致；反向要求每个已分配前缀的最后一个地址段都能解析到约定主机名。任何一条失败，都要回到地址分配表查是否登记错漏，而不是在 DNS 服务器上反复重启服务。

这三步现在已经成为我做地址规划验收的固定流程：先看路由表有没有聚合，再看租约有没有按段分配，最后用 DNS 正向反向闭环验证一遍。在经历过一次“规划表完美但现网全部走样”的翻车之后，我每次都会强制把这三步走一遍再交付，希望帮到你。

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