企业官网建设流程全解析

简介：JEDEC JESD79-5（2020年7月正式版）DDR5 SDRAM标准全文，面向内存芯片设计、硬件验证、固件开发、系统平台选型及高校相关课程人员，提供从协议定义到电气与封装实现的统一参考。文档共492页，系统覆盖DDR5特性、功能描述、AC/DC参数、封装和球/信号分配、寻址与命令时序等内容，并涉及Bank Group、片上ECC、模块内PMIC、ODT与ZQ校准等关键机制，可用于理解初始化流程、状态转换和信号完整性要求。资源包为1个PDF文件，大小8.89MB，保留完整目录与条款编号，便于检索、打印和离线查阅。已有384人学习下载。读者可据此对照官方条款开展控制器与PHY验证、内存模块设计、BIOS调试和互操作问题定位，也可作为DDR4向DDR5迁移时的差异核对、寄存器配置与测试用例设计底稿，适合需要反复查阅原始规范的中高级硬件工程师和研究生。

1. DDR5 JESD JEDEC SDRAM 这份 492 页标准，一半篇幅并没有在讲“速度”

“DDR5 JESD JEDEC SDRAM”这几个词摆在一起，多数人第一反应是：这是一份讲频率、时序和电气参数的规范。真正翻开会发现顺序是反的——封装、引脚、球距只占开头十几页，剩下绝大部分篇幅铺给模式寄存器定义、训练模式和错误管理。一份本该回答“能跑多快”的文档，为什么把一半以上写成了寄存器手册？

原因在于 DDR5 把一件原本不属于标准的事收了进来：信号完整性的调校。DDR4 时代，怎么调 ODT、怎么扫参考电压、怎么对齐 DQS，是主板固件里的经验值，各家自己攒。DDR5 把这些动作统一成 DRAM 必须响应的接口行为——颗粒自己产生测试图样、自己记录错误行地址、自己提供均衡抽头。搞懂这套机制，才能理解为什么同一颗颗粒在不同板子上表现能差一个数量级。

2. 从 POWER-ON 到第一条 MRR：初始化为什么是一份时序合约

2.1 上电之后，DRAM 并没有“准备好”

DDR5 的上电不是“通电即用”。规范把这段过程拆成三块独立的时序区块：电源爬升（3.3.3 输入电压上电与掉电序列）、复位释放（3.3.2 稳定电源下的复位初始化）、以及完整的初始化流程（3.3.1 上电初始化序列）。三者的关系是串行还是并行，取决于 RESET_n 的释放时机和电源稳定标志，而这两者在规范里写得相当死。

把这几段拆开看，每一段等待都在解决一个具体的物理问题。电源爬升阶段要等的是片上电压调节和参考电压生成电路稳定——DDR5 的 VrefDQ、VrefCA、VrefCS 都是内部 DAC 产生的，DAC 上电到输出稳定需要时间。复位释放之后等的是内部延迟锁定和 ZQ 校准，ZQ 校准决定输出驱动器的阻抗精度，它没完成之前任何读写都没有意义。

规范用一张简化状态图（3.1）把这些收敛成几个状态：复位、初始化、正常操作、自刷新。状态之间的迁移条件基本都挂在“等够多久”上，这就是它在工程上被称为“合约”的原因——不是建议，是违约就出错的硬约束。

提示：初始化失败最常见的形态不是报错，而是“能读能写但误码率高得离谱”。这时候先回头核对初始化等待时间，而不是急着调时序参数。

2.2 MRR 与 MRW：8 位地址线怎么变成一条控制通道

DDR5 没有独立的寄存器总线。模式寄存器的读写复用地址线 MA[7:0]：写的时候，MA[7:0] 是寄存器索引，DQ 上送进来的是寄存器内容；读的时候，MA[7:0] 依然是索引，结果从 DQ 返回。这套机制分别叫 MRW（Mode Register Write，3.4.2）和 MRR（Mode Register Read，3.4.1）。

关键约束有两条。第一条：MRW 之后必须等 tMRW 才能认为写入生效，这个时间不是“大概等一下”，而是规范明确要求的延迟，写完之后立刻发起访问会读到旧值。第二条：MRR 是有返回延迟的读操作，它的结果出现在 DQ 上的时刻与普通读不同，控制器必须单独建一条返回路径。

规范还专门给了模式寄存器的真值表和时序约束（3.4.4），以及一个特例——DFE 模式寄存器写更新时序（3.4.3）。这个特例的存在本身就说明问题：DFE 那批寄存器数量多、改动频繁，如果每次都按普通 MRW 的延迟走，训练过程会被拖得极长，所以规范单独放宽了它的更新规则。

一段典型的读-改-写流程长这样：

/* 以 MR4 刷新配置为例：先读，只改目标位，再写回 */ uint8_t mr4 = ddr5_mrr(0x04); /* MRR: MA[7:0]=04H，结果经 DQ 返回 */ mr4 = (mr4 & ~0x07u) | 0x02u; /* 只动低 3 位，其余位保持原值 */ ddr5_mrw(0x04, mr4); /* MRW: 写回同一索引 */ udelay(tMRW); /* 规范要求的生效延迟，不能省 */

这里“读-改-写”不是洁癖。DDR5 的模式寄存器里大量位是 RFU（Reserved for Future Use），规范明确要求这些位保持复位默认值。直接整字节覆盖写，等于把厂商预留的配置一起改掉，轻则行为异常，重则进入未定义状态。读回来、只动目标位、再写回去，是唯一安全的做法。

ddr5_mrr和ddr5_mrw这两个封装内部要处理的是命令编码和 DQ 方向切换；tMRW的取值直接决定你的初始化流程能不能过，写短了会读到脏数据，写长了只是浪费时间，所以工程上一般按规范给的上界取。

2.3 MR0 到 MR13：可编程能力是分层铺开的

模式寄存器不是一堆平铺的开关，它按“影响范围”分层。最底层是决定基本工作方式的 MR0（突发长度与 CAS Latency），往上是功能模式（MR2）、刷新策略（MR4）、IO 配置（MR5）、写恢复时间与 tRTP（MR6），再往上才是训练、均衡、错误管理这些高级功能。

MR13 值得单独拎出来说。DDR5 按 Bank Group 组织存储阵列，同一 Bank Group 内的行缓冲器和敏感放大器是共享的，所以连续访问同组内不同行时需要一个更长的间隔；跨组访问则可以更紧凑。tCCD_L 就是把这个“组内间隔”变成可编程参数。控制器的调度器如果不知道这个值，就没法判断哪些请求可以背靠背发、哪些必须拆开，吞吐量会凭空掉一截。

这套分层设计带来的直接后果是：DDR5 的初始化流程不能写成一段固定代码，它必须按“读全部 MR → 按目标配置改写 → 回读校验”的顺序走一遍。厂商在 RFU 位里藏了什么、默认值是多少，只有实际读出来才知道。

3. 片上 ECC 与错误地址登记：DDR5 把“体检报告”写进了寄存器

3.1 透明 ECC：纠错不占位宽，代价藏在延迟里

DDR5 把 ECC 做进了颗粒内部，对外表现为“透明”——主机不需要额外分配 ECC 位宽，也不需要发额外的读命令去取校验码。配置入口是 MR14（透明 ECC 配置），阈值管理在 MR15（每 Gb 存储单元的透明 ECC 阈值，以及自刷新中的自动 ECS）。

“透明”这个词容易让人误以为没有成本。实际机制上，常见的实现思路是在 die 内部按固定分组对数据做单比特纠错、双比特检错的编码，纠错动作发生在读出路径上。读出时如果发现可纠正错误，硬件直接改掉再送出去，主机完全无感；如果发现不可纠正错误，才会通过状态位上报。

代价体现在两处。第一处是延迟：带纠错的读出路径比裸读出长，这个差异在高频下不可忽略。第二处是带宽：部分配置下写入需要读-改-写，因为校验位要跟着数据一起更新，一个不完整的写操作必须先读回原数据算出新校验码。规范把这类行为收在 MR14 的配置位里，具体开不开、开哪一档，是可以选的。

MR15 里还有一个容易被忽略的机制：自动 ECS（Error Check and Scrub）。它允许 DRAM 在自刷新期间自己扫一遍存储阵列，把可纠正错误修掉。这个动作对主机完全不可见，但它会拉长自刷新周期，如果控制器把自刷新窗口算得太紧，就会在低功耗场景下翻车。

3.2 MR16 到 MR20：错误不是计数，是定位

大多数器件的错误统计只给一个计数器，DDR5 给了一整套地址登记簿：MR16、MR17、MR18 分别记录三个出错最多的行地址，MR19 记录最大错误行对应的错误计数，MR20 是总的错误计数。

这个设计不是冗余。ECC 能纠单比特，意味着单比特错误本身不致命，真正致命的是“同一行反复出错”——这说明那一行的某个存储单元正在退化。只统计错误次数，你只知道“这颗颗粒不太行”；记录了行地址，你才知道“该修哪一行”。

这三个地址寄存器和后面的 PPR 是配套的。PPR（Post Package Repair，封装后修复）的粒度就是行：发现某一行坏得厉害，就用一颗备用行把它替换掉。没有精确的行地址，PPR 就无从下手。所以 MR16~MR20 的定位从一开始就不是监控，而是为修复提供目标。

读取这套信息的流程大致是：

/* 扫描错误登记簿：先看总计数，再决定要不要读具体行地址 */ uint8_t ec = ddr5_mrr(0x14); /* MR20：错误计数 */ if (ec > ec_threshold) { uint8_t row0 = ddr5_mrr(0x10); /* MR16：错误最多的行地址 1 */ uint8_t row1 = ddr5_mrr(0x11); /* MR17：错误最多的行地址 2 */ uint8_t row2 = ddr5_mrr(0x12); /* MR18：错误最多的行地址 3 */ uint8_t maxc = ddr5_mrr(0x13); /* MR19：对应的最大错误计数 */ ppr_candidate_record(row0, row1, row2, maxc); }

ec_threshold没有标准答案，它取决于你的可靠性预算和 PPR 资源还剩多少。读 MR20 是廉价操作，读三个行地址寄存器也不贵，真正贵的是误判——把一颗还在正常范围内的颗粒判定为需要修复，会白白消耗掉有限的备用行。

3.3 PPR、hPPR 与 RFM：从“知道坏了”到“把坏行换掉”

PPR 的入口是 MR23（PPR 设置）和 MR24（PPR 保护密钥）。保护密钥这个设计很有意思：它不是加密，而是一道防误触发的闸门。行替换是不可逆的资源消耗，一旦写错地址，一条好行就被永久占用。所以规范要求先写入特定的密钥图样，再写目标地址，两步都对了才真正执行。

hPPR（MR54~MR57 描述的资源）是另一类修复资源，它按 Bank Group 划分，允许在不同组内做更灵活的替换。这几个寄存器记录的是“还剩多少资源”，属于只读信息——你在规划修复策略之前应该先读一遍，否则会出现“以为能修，结果资源已耗尽”的尴尬。

RFM（Refresh Management）是第三层保险，入口在 MR58，配套 MR59 的 RAA 计数器。它针对的是行锤一类的问题：某些访问模式会反复激活同一行，导致相邻行的电荷泄漏加速。等错误真的发生了再去修，已经晚了，所以 RFM 的思路是让 DRAM 自己统计激活次数，超过阈值就主动插入额外刷新。RAA 计数器记录的就是这个累计值，控制器读它来判断是否需要调整调度策略。

这三层是递进的：ECC 负责纠当下的错，PPR 负责修已经坏掉的行，RFM 负责不让新的行坏掉。缺任何一层，可靠性都会塌一个台阶。

4. 信号完整性被拆成可编程参数：ODT、Vref、DFE 与训练模式

4.1 四种终端电阻：为什么一个 RTT 不够用

DDR5 的片上终端（ODT）不是一个值，是一组：MR34 管 RTT_PARK 和 RTT_WR，MR35 管 RTT_NOM_WR 和 RTT_NOM_RD，MR32 管 CK 与 CS 的 ODT，MR33 管 CA 与 DQS_PARK 的 ODT，MR36 是 RTT 环回。

分开的原因在于“谁在驱动”这件事一直在变。读操作时 DRAM 是驱动端，主机是接收端，此时 DRAM 这侧不需要终端，主机侧需要；写操作时角色互换。而总线在两次操作之间还有一段空闲期，空闲期如果完全不加终端，走线上的反射会一直荡着，等到下一次操作开始时还没停下来。RTT_PARK 就是为这段空闲期准备的常驻终端。

RTT_NOM 是“正常工作时的终端”，RTT_WR 是“写操作期间的终端”，两者的切换不是瞬时的——终端电阻的开关有延迟，所以需要提前量。这就是 MR37、MR38、MR39 存在的理由：它们分别定义写操作、非目标写、非目标读的 ODTL 控制偏移。控制器提前多少个时钟周期打开终端，直接决定数据眼图的开合。

MR40 是读 DQS 的偏移时序，逻辑类似但作用在选通信号上。这几个偏移量在 DDR4 时代是控制器固件里的固定常数，DDR5 把它们变成了寄存器——因为频率上去之后，同一个常数在不同板子上不再成立。

/* 按 rank 配置终端：目标 rank 写、非目标 rank 驻留 */ ddr5_mrw(0x22, RTT_PARK_CODE | (RTT_WR_CODE << 4)); /* MR34 */ ddr5_mrw(0x23, RTT_NOM_WR_CODE | (RTT_NOM_RD_CODE << 4)); /* MR35 */ ddr5_mrw(0x25, ODTL_WR_OFFSET); /* MR37：写 ODT 提前量，单位是时钟周期 */

RTT_*_CODE是从规范给出的阻抗档位表里查出来的编码，不是欧姆数直接写进去。ODTL_WR_OFFSET取值偏小会导致终端还没建立就开始传输，偏大则会让总线在数据到达前就被拉低，两种错法的现象都是误码率上升，但眼图表现完全不同——这是区分方向的重要线索。

4.2 VrefDQ 与 VrefCA：参考电压为什么要校准

接收端判断一个位是 0 还是 1，靠的是把输入电压和一个参考电压比较。这个参考电压就是 Vref。DDR5 把 Vref 的生成搬进了颗粒内部，用 DAC 实现，配置入口是 MR9（VREF 配置）、MR10（VrefDQ 校准值）、MR11（VrefCA 校准值）、MR12（VrefCS 校准值）。

三个独立的 Vref 不是设计冗余。DQ 总线是双向的、负载重、翻转频繁；CA 总线是单向的、负载分布完全不同；CS 信号又是另一套走线。三条通道的最优参考点天然不同，共用一个值必然有一路要妥协。

DDR4 时代 Vref 靠板上电阻分压，精度受电阻公差和温漂限制。频率提到 DDR5 这个量级之后，分压网络的噪声已经和信号摆幅处在同一个数量级，再靠外部电阻就调不动了。搬进片内用 DAC 生成，好处是精度可控、可以逐 lane 校准，坏处是校准本身变成了一道必须走的流程——上电默认值只是“能工作”，不是“工作得好”。

注意：Vref 校准要在 ODT 配置完成之后做。终端阻抗会改变走线上的直流电平，先校 Vref 再改 ODT，等于白校。

4.3 LFSR 训练模式：让 DRAM 自己出考题

读训练的核心问题是：主机怎么知道 DQ 上收到的每一位是对的？外部给图样，要走一遍板级走线，图样本身就可能被延迟和衰减污染，测出来的结果分不清是 DRAM 的问题还是板子的问题。

DDR5 的解法是让 DRAM 自己产生图样。MR25 是读训练模式设置，MR26、MR27 是读图样数据与 LFSR 种子，MR28、MR29 负责按字节反转图样，MR30 定义 LFSR 的分配方式，MR31 指定训练模式的地址。

LFSR（线性反馈移位寄存器）在这里的作用是产生伪随机序列。固定图样（比如全 0、全 1、棋盘格）只能测到特定的码间干扰模式，伪随机序列能覆盖更广的跳变组合。而“图样在 die 内生成”这个设计，把板级走线从“误差来源”变成了“被测对象”——DRAM 送出的每一位都是已知的，主机收到的每一位都可以比对。

这套机制还解决了另一个问题：多 lane 并行。MR30 的 LFSR 分配允许不同 lane 用不同的种子，这样一次训练就能覆盖多种图样组合，不用逐个切换。MR31 的地址则让训练可以针对特定存储区域进行，避免和正常数据冲突。

4.4 DFE 抽头与写 CRC：高频下模拟层被写进数字寄存器

判决反馈均衡（DFE）的本质是用“刚刚判决过的位”去修正“当前位的采样阈值”。信号在走线上传输时，前一个位会在当前位的位置留下残余能量，这就是码间干扰。DFE 保留最近若干个判决结果，按权重叠加到当前比较阈值上，把残余抵消掉。抽头数就是“回看几个位”。

DDR5 把这套均衡参数全部暴露成寄存器：MR103 到 MR110 是 DQSL_t、DQSL_c、DQSU_t、DQSU_c 分别对应 IBCLK、QCLK、QBCLK 的 DCA 配置，MR111 是 DFE 全局设置，MR112 到 MR116 描述增益偏置和 Tap-1 到 Tap-4，MR248 到 MR252 用另一段地址重复同样的四项。

两段地址并存这件事本身值得注意。同一类参数出现在两个地址区间，通常意味着它按 lane 或按子通道分别寻址——也就是说不存在“写一次全生效”这回事，两组都要覆盖，漏掉一组，另一半 lane 会保持默认值继续跑。

/* DFE 配置顺序：全局使能 -> 增益偏置 -> 逐级抽头 */ ddr5_mrw(0x6F, DFE_GLOBAL_EN); /* MR111：全局开关，先关后配更安全 */ for (int lane = 0; lane < DFE_LANES; lane++) { ddr5_mrw(0x70 + lane, dfe_cfg[lane].gain_bias); /* MR112 段：增益偏置 */ ddr5_mrw(0x71 + lane, dfe_cfg[lane].tap1); /* MR113 段：Tap-1 */ ddr5_mrw(0x72 + lane, dfe_cfg[lane].tap2); /* MR114 段：Tap-2 */ ddr5_mrw(0x73 + lane, dfe_cfg[lane].tap3); /* MR115 段：Tap-3 */ ddr5_mrw(0x74 + lane, dfe_cfg[lane].tap4); /* MR116 段：Tap-4 */ } ddr5_mrw(0x6F, DFE_GLOBAL_EN | DFE_TRAIN_DONE); /* 配置完成后统一使能 */

DFE_LANES和dfe_cfg的具体取值来自训练扫描结果，不是查表能查出来的。配置顺序上先关全局使能再逐级写参数，是为了避免中间态被应用到实际采样上——DFE 抽头在切换过程中如果短暂失配，可能直接把眼图关死，而且这个错误不会自愈。

MR50 到 MR52 是写 CRC 相关配置。写方向加校验，主机发数据时附带 CRC，DRAM 收到后校验，错了就报。MR51、MR52 的自动禁用阈值和窗口是个实用设计：当错误率高到一定程度，继续报错只会淹没真正的问题，不如在一段窗口内自动关掉 CRC，让链路先跑起来。MR53 的环回模式则把 DRAM 的接收路径直接接回发送路径，用于隔离故障——到底是板子的问题还是颗粒的问题，一环回就清楚了。

5. DDR5 调试避坑：五个“寄存器读出来都对，就是跑不起来”的场景

5.1 现象：初始化能过，第一次读写就挂

现象是初始化流程一路绿灯，MRR 回读的值和写入值完全一致，但第一次真实读写就返回全 0 或者全 F。

原因通常不在寄存器，而在 MRW 之后的等待。写进去的值和真正生效是两个时刻，tMRW 没等够，控制器就开始发读写命令，DRAM 内部还在切换配置状态，命令被吞掉或者被错误解析。

解决方式是逐条核对初始化流程里的每一处延迟，尤其是那些“看起来不需要等”的寄存器切换。稳妥做法是在初始化末尾加一次全量 MRR 回读，把这个回读当作配置真正生效的标志，而不是写完就算完。

5.2 现象：单 rank 测试全过，双 rank 一插就错

现象是单条内存跑压力测试毫无问题，插满之后误码率飙升，而且错误位置随温度漂移。

原因指向 ODT。双 rank 配置下，非目标 rank 在总线上的存在会改变阻抗特性，如果 RTT_PARK 和 RTT_NOM 还是按单 rank 时调出来的值配的，非目标 rank 就变成了一个不匹配的负载，反射直接把眼图吃掉一半。

解决方式是重新扫一遍终端配置，重点是非目标 rank 的驻留终端档位。判断方向的办法很简单：把非目标 rank 拔掉，如果错误消失，就是终端问题而不是时序问题。

5.3 现象：打开 DFE 之后误码率反而更高

现象是训练阶段扫出来的 DFE 抽头系数看起来合理，使能之后 BER 不降反升，而且只在特定数据图样下出现。

原因是抽头的符号或者极性方向理解反了。DFE 的修正是“减去”前一位的残余，如果系数符号搞错，等于把干扰放大了一倍。另一个可能是使能时机太早——在训练模式还没跑完、通道特性还没摸清的时候就打开了全局使能。

解决方式是把配置顺序固定成：先关全局使能、先跑 LFSR 训练模式拿到基线误码率、再逐 lane 写抽头、最后统一使能。每一步之间做一次误码率对比，哪一步变差了就回退哪一步，不要一次改一堆参数。

5.4 现象：PPR 执行了，但坏行还在报错

现象是按照 MR16 记录的行地址发了 PPR，重新扫描发现同一行仍然在错误登记簿里。

原因有三个常见方向。一是保护密钥 MR24 没按规范要求写入，PPR 根本没执行，但也没有报错机制告诉你它没执行。二是 hPPR 资源已经耗尽，MR54 到 MR57 读出来就是剩余量，发命令之前应该先看一眼。三是 PPR 的粒度理解错了，修的是行，但错误其实分布在多个行上，修一行解决不了问题。

解决方式是把 PPR 做成一个带前置检查的流程：读资源余量、写保护密钥、写目标行地址、回读确认、重新扫描验证。跳过任何一步，你都不知道是真修好了还是命令被丢弃了。

5.5 现象：打开片上 ECC 后带宽掉得比预期多

现象是启用透明 ECC 之后，实测带宽下降幅度远超按“校验位占比”估算出来的值。

原因在于读-改-写。部分写入场景下，DRAM 必须先读回整块数据、算出新校验码、再整体写回，这个过程占用两倍的访问周期。如果业务负载本身以小颗粒随机写为主，命中率会非常高，带宽看起来就像被腰斩。

另一个隐藏因素是 MR15 的自动 ECS。它会在自刷新期间扫阵列，扫的时候自刷新周期被拉长，低功耗场景下表现为唤醒延迟变大，而不是带宽下降——这个更难定位。

解决方式是先按负载特征评估：写密集且写入粒度小于纠错分组时，ECC 的代价是结构性的，只能靠调整访问粒度来缓解。同时把 MR15 的阈值调高，减少自动 ECS 的触发频率，但要清楚这是用可靠性换性能，不能无脑调。

6. 标准真正给的是“可验证的假设”：DDR5 设计取舍的边界

把这份规范当成一份“参数表”来读，会漏掉它最核心的东西：JESD79-5 实际上是在用寄存器定义一套可验证的假设。每一条 MR 背后都对应一个“如果不这么配，会出什么问题”的判断，而这些问题在 DDR4 时代是靠各家固件团队口口相传的血泪经验积累的。

这套设计有明显的取舍。把所有信号完整性参数做成可编程，好处是同一颗颗粒能适配不同的板级环境，BOM 成本降下来、兼容性上去了；坏处是把复杂度从硬件转移到了固件，初始化流程从“上电、等一会、开跑”变成了几百步的寄存器舞蹈，任何一步顺序错了都可能是偶发误码而不是明确报错。透明 ECC 也是同理，它用带宽和延迟换可靠性，值不值取决于你的业务是吞吐敏感还是可靠性敏感。PPR 更是典型的“一次性后悔药”——资源有限、不可逆、还带保护密钥，设计意图就是让你在动手之前想清楚。

从验证角度，我一般会把 DDR5 的上板流程切成分层递进：第一步全量 dump 模式寄存器，确认默认值和厂商预留位符合预期；第二步跑 LFSR 训练模式，在不依赖外部图样的前提下确认 DQ/DQS 映射正确；第三步扫 Vref 和 ODT，把眼图打开；第四步才开 DFE 和写 CRC；最后才是 ECC 和 PPR 这些可靠性功能。每一层都独立验证，出问题时能立刻定位到是哪一层引入的。

这套顺序救过我很多次。早些年调内存，习惯是“一次配到底然后看能不能跑”，结果每次出问题都要从几百个参数里大海捞针。从那以后我每次上板都强制走一遍分层验证，哪怕看起来浪费时间——因为省下来的时间最后都会加倍还给调试。这份 492 页的规范值得放在手边反复翻，它不是用来通读的，是用来在每次卡住的时候回去查的。希望帮到你。

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