Vitis HLS入门指南：从C代码到FPGA RTL与IP核实践

简介：面向FPGA高层次综合开发者的《Vitis高层次综合用户指南》中文译本，对应UG1399 v2022.2（2022年12月7日发布），适合HLS初学者、算法加速工程师，以及需要把C/C++代码落到可综合硬件上的设计者。全文分七部分：HLS概念与优势、HLS编程指南（FPGA编程三大范例、控制驱动与数据驱动的任务级并行、循环与流水线优化）、Vitis HLS的环境配置与工程创建、命令行选项、C语言测试平台驱动、预置库函数与模板，以及把既有代码与IP移植到HLS环境的策略；目录层级清晰，可按设计进程逐节查阅。

整包为1个PDF文档，约16.41MB，保留原版章节编号与图表，便于检索、批注和打印对照。

已有735人学习下载，可作为日常工具书：遇到并行化、接口综合或移植问题时按目录直达对应章节，结合示例与综合报告理解工具行为，少走弯路。

1. 先搞懂一件事：HLS 到底把 C 代码变成了什么

第一次打开这份 Vitis HLS 用户指南，我猜你和我当初一样，翻两页就懵了：满屏的 pipeline、unroll、m_axi 全是没见过的词，而你要做的却是 FPGA 上的硬件电路。先说句能让你安心的实话：高层次综合（HLS）不是让你绕开硬件知识，而是给你换一种描述硬件的语言——用 C/C++ 写逻辑，让工具替你生成寄存器传输级（RTL）代码。

你可以把它想成一个懂硬件的翻译官。你写的是顺序执行的软件语句，它读完之后，帮你把这些语句排成能在电路里同时跑的流水线，最后吐出一份可以直接打包成 IP 核的硬件设计。这份 Vitis HLS 用户指南（UG1399，v2022.2）就是这位翻译官的使用说明书。它适合两类人：刚接触 FPGA、不想一上来就啃 Verilog 的新手，以及写过软件、想把算法搬上硬件的工程师。

2. 为什么值得学：写 C 和写 Verilog 差在哪里

很多人对 FPGA 的第一印象是“难”。难在哪？难在你得用一个时钟周期一个时钟周期的方式去描述电路：这个信号在上升沿采样、那个状态机要跳转到第几态、握手信号拉高之后几个周期才能读数据。写一个简单的图像滤波，几千行 Verilog 打底是常事，而且改一个参数就可能推倒重来。

HLS 换了个思路：你描述“算什么”，工具负责“怎么排电路”。这不是偷懒，而是把重复的、机械的电路搭建工作交给工具，让你把精力放在算法和数据流上。但这里必须先泼一盆冷水——HLS 不是银弹，它有自己的脾气，写惯软件的人第一次上手，十有八九会翻车。所以下面这几节，我先把“为什么值得学”和“学的时候要注意什么”一起讲清楚。

2.1 FPGA 编程的三大范例：顺序、数据并行、任务并行

指南的第 1 章把 FPGA 编程归纳成三大范例，这个划分非常关键，因为它决定了你写 C 代码时的思维方式。

第一种是顺序执行，也就是控制驱动。你的代码一行一行往下走，硬件里对应的是状态机：做完第一步再做第二步。这是软件工程师最熟悉的模式，也是最容易上手的起点。代价是并行度低，如果你的算法里有很多可以同时做的事，用纯顺序的方式写就浪费了 FPGA 的并行能力。

第二种是数据并行。典型场景是一个循环里对一大堆数据做同样的运算，比如给一张图的每个像素乘一个系数。硬件里可以复制多份运算单元，让多个像素同时算。在 HLS 里，控制这件事的手段就是循环展开（unroll）和流水打拍（pipeline），后面第 4 章会细讲。

第三种是任务并行，也叫数据驱动的任务级并行。一个流程里有多个独立的处理阶段，比如“读数据 → 处理 → 写数据”，每一段各干各的，段与段之间用 FIFO 一样的通道传数据。指南里专门讲了数据驱动和控制驱动两种任务模型，还讲了怎么混用。

新手最容易犯的错，是想在一开始就把三种范例全用上。我的建议很朴素：先用顺序的方式把功能写对、跑通 C 仿真，再考虑给最耗时的那个循环加流水，最后才去想任务级并行。这个顺序，和指南第 1 章“组合三种范例”的思路是一致的。

2.2 换语言到底省了什么：效率、可读性、优化空间

指南在“高层次综合的优势”一节里列了几条，我挑三条对新手最有实感的讲。

开发效率。同样一个矩阵乘，Verilog 要手写乘加单元阵列、地址生成、握手时序；C 版本可能就三层循环。省下来的时间不是一点半点，尤其是你还要反复调参数、改位宽、试不同的并行度的时候，改 C 代码比改 RTL 快一个数量级。

可读性和可维护性。这一点在团队协作里体现得最明显。一个算法工程师看得懂 C，未必看得懂你写的状态机。用 C 描述算法，算法本身成了设计文档，后人接手时不用先反向推理你的电路意图。

优化空间。HLS 工具会自动做流水线、资源分配、位宽推断这些事，而且它会给你一份详细报告，告诉你每个循环的启动间隔是多少、瓶颈在哪。这份报告的价值很高——它把“为什么我的设计跑不快”这个玄学问题，变成了可以逐条排查的清单。我在第一次看到调度查看器里那条长长的、被拉开的时序条时，才真正明白自己那段代码慢在哪。

但优势的另一面就是约束。既然工具要替你推断电路，那它就必须能“看懂”你的代码。凡是它看不懂的写法——动态申请内存、递归调用、函数指针乱飞——它都会直接报错。这不是工具的缺陷，而是这类工具的边界，你得先接受这个边界。

2.3 这份指南的七个部分，对应你的学习顺序

整本指南分成七大部分：HLS 简介、HLS 编程指南、使用 Vitis HLS、命令行、C 语言驱动、HLS 库、HLS 移植。新手看到这个目录容易犯选择困难，我的建议是不要按目录顺序从头读到尾。

前两部分（简介 + 编程指南）是概念地基，值得认真读，但不必一次读完。第三部分“使用 Vitis HLS”是操作手册，是你真正动手时会反复翻的部分，从创建工作、设置时钟频率到跑 C 仿真、做综合、看报告，全在这里。第四、五部分偏向自动化流程和验证，等你手工跑通一遍之后再回来看会轻松很多。第六、七部分的库和移植，属于你有了第一个能跑的工程之后的进阶内容。

如果你只有一小时，那就读第 1 章简介，然后直接跳到第 12 章“创建新的 Vitis HLS 工程”，把工具跑起来。概念这种东西，光看是记不住的，得让它在屏幕上动起来。

3. 第一个例子怎么跑：从一段向量加法到看见综合报告

这一章是全文最“手把手”的部分。我选了一个最朴素的例子：两个数组逐元素相加。它足够简单，简单到你能一眼看懂功能；又足够典型，典型到能把建工程、写顶层函数、加接口约束、跑仿真、做综合这条完整链路走一遍。

3.1 起步前的两件事：环境配置和启动方式

Vitis HLS 有两种用法：图形界面和命令行。新手先用图形界面，因为综合报告、调度查看器这些可视化工具都在界面里，看图比看日志快得多。命令行适合你后面做批量回归，现在不用急。

启动之前要先配置环境。Linux 下通常是执行安装目录里的环境脚本，让工具链的路径进到当前终端：

# 进入工具安装目录，执行环境配置脚本 # 具体路径按你自己的安装位置替换，不要照抄 source <安装目录>/settings64.sh # 配置完成后验证一下，能打印出版本信息就说明环境对了 vitis_hls -version

Windows 下更省事，直接从开始菜单找到 Vitis HLS 的启动项点开就行。这里有个血泪经验：如果你在终端里启动工具，一定要在同一个终端里先 source 环境脚本，否则工具会报找不到器件库或者找不到编译器。我第一次装完就踩了这个坑，折腾了半小时才发现是新开的终端没继承环境变量。

界面打开后，你会看到一个工程浏览区、一个代码编辑区和一个流程导航区（Flow Navigator）。流程导航区那一排按钮——C 仿真、综合、协同仿真、导出——就是你接下来要按顺序点的东西。先记住这个布局，别的先不用管。

3.2 建工程：源文件、测试激励、顶层函数怎么放

新建工程时有几样东西要准备好，缺一样后面都会卡住。

第一是源文件。注意，HLS 综合的是“函数”，不是main。所以你的源文件里应该是一个可以被别人调用的函数，而不是一个自己跑起来的程序。这个函数叫顶层函数，工具会从它开始往下综合。

第二是头文件。把函数声明、常量定义放进去，源文件和测试激励都 include 它，避免两边的接口对不上。

第三是测试激励文件。这是新手最容易忽略的东西。测试激励就是一个带main的 C++ 文件，它负责造数据、调你的顶层函数、比对结果。没有它，你只能做综合，不能做 C 仿真，也就失去了在写硬件之前先把功能验证掉的机会。

第四是顶层函数名。工具需要知道从哪个函数开始综合，这个在工程设置里指定，命令行里对应set_top。

建工程时还会让你选一个解决方案名（solution）。这个概念要提前说清：一个工程下可以挂多个解决方案，每个解决方案有自己的一套约束和编译指示，共用同一份源文件。你后面想试“时钟 10ns 和 5ns 分别是什么结果”“加流水和不加流水差多少”，就是靠建多个解决方案来对比的，不用复制一堆工程。这个设计非常实用，指南第 16 章讲“创建额外解决方案”说的就是这个。

3.3 写第一个能综合的函数

先看顶层函数。这段代码不长，但每一条编译指示（pragma）都有明确作用：

// vec_add.h #ifndef VEC_ADD_H #define VEC_ADD_H #define N 64 void vec_add(const int a[N], const int b[N], int c[N]); #endif

// vec_add.cpp #include "vec_add.h" void vec_add(const int a[N], const int b[N], int c[N]) { // 三个数组各走一个 m_axi 接口，bundle 名字不同表示分成三组总线 #pragma HLS INTERFACE m_axi port=a offset=slave bundle=gmem0 #pragma HLS INTERFACE m_axi port=b offset=slave bundle=gmem1 #pragma HLS INTERFACE m_axi port=c offset=slave bundle=gmem2 // 控制寄存器走 s_axilite，CPU 通过它读写参数、启动和查询状态 #pragma HLS INTERFACE s_axilite port=return bundle=ctrl for (int i = 0; i < N; ++i) { // 让每次迭代都能在上一个迭代还没结束时启动，目标启动间隔 1 个时钟 #pragma HLS PIPELINE II=1 c[i] = a[i] + b[i]; } }

逐条解释一下。#pragma HLS INTERFACE这一组决定的是“这个函数对外长什么样”，也就是它变成 IP 核之后，外部怎么访问它。m_axi表示数组走 AXI 主口，直接对内存读写；offset=slave表示地址偏移由控制寄存器给出，而不是硬编码在电路里，这样同一份硬件可以处理不同地址的数据；bundle=gmem0/1/2表示把三个数组分到三组独立的总线上，避免它们抢同一个端口。s_axilite是控制接口，CPU 通过它启动这个 IP、读状态。PIPELINE II=1是给循环的，意思是希望每 1 个时钟就能启动一次新的迭代。

再看测试激励：

// vec_add_tb.cpp #include <iostream> #include "vec_add.h" int main() { int a[N], b[N], c[N]; // 造一组简单数据，方便人工核对 for (int i = 0; i < N; ++i) { a[i] = i; b[i] = 2 * i; } vec_add(a, b, c); // 逐元素比对，任何一处不对都算失败 int err = 0; for (int i = 0; i < N; ++i) { if (c[i] != 3 * i) { std::cout << "mismatch at " << i << ": " << c[i] << std::endl; err++; } } std::cout << (err == 0 ? "PASS" : "FAIL") << std::endl; return err; }

这份激励的关键在于它返回错误数。很多新手写的测试文件最后只 print 一句“跑完了”，工具根本不知道成功还是失败，后面做自动协同仿真的时候就没法判断。养成习惯：main返回非零表示失败。

3.4 三步走：C 仿真、综合、协同仿真

如果你喜欢命令行，把下面这段存成run_hls.tcl，然后用vitis_hls -f run_hls.tcl跑起来。图形界面里的操作和这段脚本是一一对应的，看懂脚本也就看懂了界面在干什么。

# 创建一个工程，-reset 表示如果已存在就清空重建 open_project -reset prj_vec_add # 指定从哪个函数开始综合 set_top vec_add # 添加源文件和测试激励 add_files vec_add.cpp add_files -tb vec_add_tb.cpp # 创建一个解决方案，指定流程目标 open_solution -reset "solution1" -flow_target vivado # 器件型号按你自己板子上的填，这里只是示例 set_part {xc7z020clg400-1} # 目标时钟周期 10ns，即 100MHz create_clock -period 10 -name default # 第一步：C 语言仿真，先确认功能对不对 csim_design # 第二步：综合，把 C 变成 RTL 并生成报告 csynth_design # 第三步：C/RTL 协同仿真，验证综合出来的电路行为是否和 C 一致 cosim_design # 最后导出成 IP，供上层系统调用 export_design -format ip_catalog

几个参数值得单独说。set_part是器件型号，写错了会直接报错，去查你开发板的型号，不要照抄别人的。create_clock -period 10里的 10 是纳秒，你要 200MHz 就写 5。这个数字不是许愿，工具会尽力去满足，做不到的时候会在报告里告诉你差多少。

csim_design跑的是纯软件仿真，速度快，用来抓逻辑错误。csynth_design是真正的综合，它输出 RTL 和一份综合汇总，里面有几样东西必看：资源占用（LUT、寄存器、DSP、BRAM 各用了多少）、时序估计（目标时钟和估计时钟）、以及每个循环的启动间隔 II。cosim_design最慢，但它能抓住“C 仿真过了、综合出来的电路却不对”这类问题——这种情况在指针、未初始化变量、边界处理上并不罕见。

提示：第一次跑，把cosim_design留着别删。哪怕它慢，它也是你确认“我写的 C 和生成的电路是同一个东西”的唯一手段。

综合跑完之后，界面里会有几个查看器。调度查看器把每个操作放在时间轴上，你能直观看到哪一步占了几个周期、哪里被卡住了。函数调用图给你整体结构。数据流查看器和时间线轨迹查看器在你看任务级并行的时候特别有用。新手先看调度查看器和综合汇总就够了，别一上来被一堆图吓住。

4. 三个绕不开的概念：循环、数组、函数

跑通第一个例子之后，你会发现真正的难点不在工具操作，而在“我这么写，工具会给我生成什么电路”。这一章讲三个最基础也最容易出问题的东西：循环、数组、函数。指南把它们分别放在第 3、4、5 章，我建议连着读，因为它们在真实设计里是缠在一起的。

4.1 循环：流水打拍和展开到底在改什么

循环是 HLS 里最值得花时间的部分，因为你算法里 90% 的时间都花在循环上。

先说流水打拍（pipeline）。默认情况下，一个循环的每次迭代是串行的：第 1 次迭代完全做完，才开始第 2 次。加流水之后，第 2 次迭代可以在第 1 次还没结束时就开始，只要它们用的硬件资源不冲突。衡量指标叫启动间隔 II（initiation interval），II=1 表示每个时钟都能送进一个新数据，这是很多场景下的理想值。

再说展开（unroll）。展开是另一回事：它把循环体复制多份，让多次迭代真正并行执行。一个 4 次迭代的循环完全展开，电路里就有 4 份运算单元同时干活。代价是资源翻倍。所以展开不是越多越好，你得看自己的资源预算。

这两者的区别，新手经常搞混。我的记法是：流水是让活儿错开时间做，展开是让活儿同时做。流水省的是时间，展开花的是资源。

// 流水写法：资源基本不变，吞吐提上来 for (int i = 0; i < N; ++i) { #pragma HLS PIPELINE II=1 c[i] = a[i] * b[i] + c[i]; } // 展开写法：并行度上去，运算单元也翻倍 for (int i = 0; i < 4; ++i) { #pragma HLS UNROLL c[i] = a[i] * b[i] + c[i]; }

除了这两个，指南还讲了循环合并和嵌套循环处理。循环合并是把相邻的、边界相同的两个循环合成一个，减少循环本身的开销，但合并之后流水可能会受更多约束，不一定总是变快。嵌套循环的常见做法是给内层加流水、外层保持顺序，因为外层流水往往会导致资源爆炸。指南里还专门讲了变量循环边界的问题——如果你的循环次数是运行时才知道的，工具没法完全展开，很多优化就用不了，这是新手写代码时特别容易忽略的一点。

跑完综合记得回头看报告里的 II。如果某个循环的 II 是 5 而不是 1，说明有资源冲突，通常就是下一节要说的数组访问问题。

4.2 数组：软件里的一行，硬件里是一块存储器

在软件里写int a[64]，你觉得它就是 64 个格子随便访问。在硬件里不是。默认情况下，这个数组会被映射成一块双端口 BRAM，也就是每个时钟最多只能读两次、写两次。你的循环如果在一个周期里要访问 3 个不同的元素，那就撞墙了，II 直接掉下来。

解决办法是数组分区（array partition）。把一个数组拆成多块小的，或者按元素拆开成独立的寄存器。常见三种拆法：完全拆分（complete，每个元素一个存储单元）、按块拆（block）、交叉拆（cyclic）。拆得越狠，并行访问能力越强，占用资源也越多。

int a[N]; // 完全拆开，每个元素独立存储，适合并行度要求高、元素数不多的场景 #pragma HLS ARRAY_PARTITION variable=a type=complete dim=1 // 按块拆成 4 份，折中方案，元素多的时候更实用 #pragma HLS ARRAY_PARTITION variable=a type=block factor=4 dim=1

数组还有几个新手常踩的点。接口上的数组：顶层函数的数组参数如果不指定接口，工具会给你一个默认接口，很可能和你板子上的总线对不上，导出的 IP 接不进去。数组初始化：在声明时给了初值的数组，综合出来是 ROM，这是省资源的好办法。数组复位：给数组加复位会导致每个元素都要有复位逻辑，资源开销很大，能用初始化解决的就别用复位。

4.3 函数：内联、流水、例化三选一

函数在硬件里对应一块电路。当一个函数被多处调用时，工具默认会共用同一份电路——这省资源，但同一时刻只能服务一个调用者。如果你想让它同时服务多个调用者，就得例化多份。

反过来，如果一个函数很小、调用很频繁，函数调用本身的开销（保存现场、跳转）就很划不来，这时候用**内联（inline）**把函数体直接展开到调用处，省掉调用开销。代价是代码体积变大，如果这个函数在很多地方被调用，电路可能膨胀。

函数也可以加流水。给函数加流水意味着这个函数可以连续接收新的一组输入，而不必等上一组完全算完。这个用法在流式处理里很常见。

// 小函数，内联掉调用开销 inline int square(int x) { return x * x; } // 大函数，允许流水，连续接收新数据 void process(int in, int &out) { #pragma HLS PIPELINE II=1 out = square(in) + 1; }

选择原则很简单：调用点多、函数体小，就内联；需要同时处理多路数据，就例化；数据是流式进来的，就加流水。指南第 5 章和第 10 章里讲的“C++ 类中展开循环”“静态变量对流水的影响”，都是这些原则在具体场景下的延伸，等你能跑通例子之后再回头读会顺很多。

4.4 数据类型：为什么不用 int 而用 ap_int

硬件里位宽就是资源。你写一个int，就是 32 位；如果你的数据实际只用到 8 位，那 24 位就是白扔的。在 FPGA 上，这种浪费会直接体现在 LUT 和寄存器的占用上。

所以 HLS 提供了任意精度类型：ap_int<W>表示 W 位有符号整数，ap_uint<W>是无符号版本，还有ap_fixed表示定点小数。用ap_int<8>代替int处理 8 位数据，资源能省下一大截。

#include <ap_int.h> // 只用 8 位，就声明 8 位，别用 int 浪费 24 位 void scale(ap_uint<8> in, ap_uint<8> &out) { out = in * 2; }

要注意的是，位宽推算得自己心里有数。两个 8 位数相乘，结果是 16 位，如果你还用 8 位接，就会溢出。指南第 6 章讲得很细，包括标准类型、复合类型、任意精度类型、指针、矢量类型和位宽传输，新手先把ap_int和ap_uint用熟就够。另外指针也是新手容易栽的地方：用指针做随机访问，工具分析不出访存模式，流水就做不出来，甚至直接综合失败。

5. 新手避坑：四个把综合结果搞崩的常见操作

这一章列的四个坑，是我见过新手最容易踩、也最难自己定位的。每条我都按“现象 → 原因 → 解决”写，你遇到问题时可以对照着排查。

5.1 现象：综合直接报错，提示不支持某构造

原因：你用了 HLS 不支持的 C/C++ 构造。指南第 7 章专门列了一份清单，包括系统调用、动态内存分配（malloc/new）、递归函数、虚函数、以及某些未定义行为。这些在软件里天经地义，在硬件里没法映射——硬件没有操作系统，也没有可以随时增长的堆。

解决：把动态内存改成静态数组，数组大小在编译期就定下来；把递归改写成循环加显式栈；把系统调用（打印、文件读写）从综合的函数里挪出去，只留在测试激励里。第 7 章那份清单值得在动手前扫一遍，能省很多试错的功夫。

5.2 现象：综合能过，但某个循环的 II 一直是 5 以上，怎么加流水都不降

原因：多半是数组访问冲突。默认的双端口 BRAM 一个周期只能支持有限的访问次数，你的循环在一个周期里要读好几个不同下标的元素，硬件做不到，只能把迭代拉开。也可能是循环里存在跨迭代的依赖，比如后一次迭代要读前一次写的结果。

解决：先看调度查看器，找出是哪几个操作在抢资源。如果是数组访问，考虑加ARRAY_PARTITION；如果是依赖，看看能不能把依赖拆开，或者接受这个 II。还有一种情况是循环边界是变量，工具没法展开，那就把边界固定下来。

5.3 现象：C 仿真通过了，功能看起来没问题，但资源占用高得离谱

原因：位宽写得太大，或者数组没有分区导致工具给你推断了一块巨大的存储器。还有一种隐蔽情况是给数组加了复位，每个元素都要独立的复位逻辑。

解决：把能降到ap_int<8>的数据类型都降下来；检查每个数组的存储实现，该分区的分区，该做成 ROM 的用初始化列表做 ROM；去掉不必要的数组复位。综合汇总里的资源数字要养成习惯去看，别只看“综合成功”四个字就完事。

5.4 现象：C 仿真过、综合也过，上板之后结果就是不对

原因：C 仿真只验证了算法逻辑，它不知道综合出来的电路长什么样。典型问题包括未初始化变量、指针别名、以及边界情况处理不一致。这类问题在纯 C 环境里可能刚好“运气好”跑对了，硬件里就没有这个运气。

解决：跑 C/RTL 协同仿真。它会用你写的测试激励去驱动生成出来的 RTL，把结果和 C 模型对比。这一步慢，但它是唯一能抓住这类问题的手段。另外，协同仿真过不了的时候，去看时间线轨迹，通常能定位到是哪个接口的时序对不上。

注意：把“C 仿真通过”当成“设计完成”，是新手最贵的错觉。三个验证步骤各有各的职责，一个都不能省。

6. 下一步学什么：从跑通例子到能自己调优的路线

跑通第一个例子只是拿到了入场券。接下来怎么走，我给你一条我验证过、也踩过坑的路线，分四个阶段，每个阶段都有明确的“算过关”的标准，别凭感觉判断自己学没学会。

第二阶段最值得投入时间。找一个你自己写过的、带嵌套循环的小算法，比如卷积或者排序，把它搬进来，然后一组一组地改：先只加流水，记录 II 和资源；再加数组分区，再记录；再试着展开。三组数据摆在一起，你对“哪种写法花多少资源换多少性能”就有直觉了。这个直觉比读十遍文档都管用。

第三阶段开始接触接口。新手容易在这里卡住，因为接口选错，后面怎么调都不对。我的建议是先照着指南第 8 章的示例抄一遍，把三种接口各跑通一次，然后再去理解存储器布局模型那些细节。

第四阶段是效率的分水岭。学会用多个解决方案做对比之后，你就不再靠猜了。同一份代码，改一个参数建一个新 solution，跑完把报告里的数字抄到一张表里，谁快谁慢一目了然。

最后说个我自己的教训。我刚开始学的时候，最大的毛病是“改完就跑综合”，从来不回头看报告里的 II 和资源数字，看到“综合成功”就以为万事大吉，结果上板一测性能差得离谱，再回头一点点翻报告，前后浪费的时间够我把整个流程重走三遍。从那以后，我每次改完代码，都强制自己先把综合汇总里的资源占用和每个循环的 II 抄下来，和上一版对比，确认变化符合预期，再去跑协同仿真。这个习惯听起来笨，但它把“玄学调优”变成了可追踪的实验记录。

希望这条路线能帮你少走点弯路，也希望你早点跑出第一个自己的 IP 核。

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