I2C初始化与避坑指南)
简介：面向需要极小尺寸显示方案的STM32开发者，这份工程源码以0.42寸OLED（SSD1306控制器）为核心，提供基于I2C接口的底层驱动与字符显示调试代码，可直接用于智能穿戴、微型仪表盘等空间受限设计。压缩包共1013个文件，以C源代码（561个）和头文件（249个）为主体，另含汇编、链接脚本、Keil工程配置文件（uvprojx、uvoptx）及ioc等STM32CubeMX工程文件，整体12.21MB，完整保留编译输出与库文件，便于自行重建或对比学习。该源码来自实际项目筛选过程，配套博文给出接线与运行说明，适合正在挑选微型OLED并希望复用成熟I2C驱动代码的入门至中级开发者。已有557人浏览学习，从底层寄存器操作到应用层显示函数均有覆盖，可作为轻量化人机交互显示模板。
1. 一块 0.42 寸小屏，为什么值得单独写一篇
STM32 驱动 0.42寸 OLED、控制器是 SSD1306，这两个词凑在一起，通常是做小体积交互设备时的最后一公里。很多开发者第一次点亮 128x64 的 0.96 寸屏很顺利，换成 0.42 寸 72x40 分辨率屏反而翻车：不是黑屏就是显示错位，网上能找到的例程几乎全是给大屏用的。原因不复杂——SSD1306 虽然是同一个控制器，但 72x40 的分辨率、5 页显存布局、特殊的屏体级联方式，跟标准 128x64 的初始化和显存处理完全不是一套逻辑。这篇笔记把 I2C 时序、复位时序、寄存器配置、显存寻址、常见黑屏原因一次讲透，适合手里有 0.42 寸屏但还没点亮的人，也适合想从 SPI 换 I2C 省引脚的人。
2. SSD1306 与 0.42 寸屏的匹配关系：先把屏体结构搞清楚再写代码
2.1 为什么 0.42 寸屏是 I2C 驱动的最好选择
0.42 寸 OLED 在淘宝和立创商城上常见的是 72x40 分辨率，接口有 I2C 和 SPI 两种选择。我一般直接推荐 I2C 版本，原因有两点：一是这块屏本身只有 4 个引脚（VCC、GND、SCL、SDA），在引脚紧张的贴片方案里优势明显；二是 72x40 这个分辨率对刷新率要求不高，I2C 的 400kHz 带宽足够支撑一般菜单和数值刷新。
SSD1306 这个控制器本身最多支持 128x64，0.42 寸屏实际是面板厂商利用 SSD1306 的 128 列驱动能力，只引出了其中 72 列，行方向只用了 40 行。这就带来一个关键差异：标准屏初始化里常见的 0xA8 参数 0x3F（64 行）在这里必须改成 0x27（40 行），否则屏体上半部分正常、下半部分花屏，或者整体滚动异常。
2.2 I2C 从机地址和控制字节：0x78 与 0x7A 的来历
SSD1306 在 I2C 模式下从机地址由 SA0 引脚决定，这个引脚在 0.42 寸屏模组上通常已经固定接死。地址格式是 7 位地址加读写位组成 8 位：SA0=0 时 7 位地址是 0x3C，加上写位 0 变成 0x78；SA0=1 时是 0x3D，加写位后是 0x7A。绝大多数模块默认 SA0=0，也就是往地址 0x78 写。
除开从机地址，I2C 发送的每个包还要带一个控制字节。控制字节 0x00 表示后面跟的是命令，0x40 表示后面跟的是显存数据。这个控制字节特别容易漏写，尤其是之前写过 SPI 版本的人，SPI 是靠 DC 引脚电平区分命令和数据，I2C 没有 DC 引脚，全靠这个控制字节，漏了它整屏黑或乱码。
2.3 上电时序与复位：I2C 黑屏的第一大元凶
SSD1306 的数据手册规定了严格的上电时序：VCC 上电稳定后需要等待至少 100ms，然后拉低 RES 复位引脚至少 3us，再拉高释放。很多 0.42 寸模块把 RES 引脚引出来了，也有部分模块直接绑死在 MCU 的复位上。
我见过一个典型故障：某开发者用电台飞线连了 OLED 的 VCC、GND、SCL、SDA，唯独没接 RES，上电后往 0x78 写初始化序列，I2C 波形完全正常，ACK 也正常，但屏就是黑的。原因就是模块的 RES 悬空，SSD1306 一直停在复位状态。解决方法是把 RES 接到 MCU 的一个普通 GPIO，初始化代码开头先拉低 10ms 再拉高。
#define OLED_RES_PIN GPIO_PIN_3 /* 复位：拉低 10ms，再拉高，等待内部上电稳定 */ HAL_GPIO_WritePin(GPIOA, OLED_RES_PIN, GPIO_PIN_RESET); HAL_Delay(10); HAL_GPIO_WritePin(GPIOA, OLED_RES_PIN, GPIO_PIN_SET); HAL_Delay(100); /* 等待 SSD1306 内部 DC-DC 稳压器稳定 */延时参数说明：RES 低电平时间理论上 3us 就够，但 10ms 是为了抵消电源上电斜率慢带来的不确定性；释放后的 100ms 等待是因为 SSD1306 内部有电荷泵 DC-DC，上电后需要时间建立内部电压，这段不等待容易出现花屏或亮度不均。
3. 用 STM32 的硬件 I2C 点亮 0.42 寸 OLED：从初始化到画点
3.1 硬件接线与引脚选择
我习惯用硬件 I2C 而不是模拟 I2C，虽然模拟 I2C 在换引脚时更灵活，但硬件 I2C 配合 DMA 做全屏刷新时 CPU 占用率低很多，而且中断和错误标志位处理起来更规范。接线就 4 根线：SCL、SDA 接 MCU 的 I2C 引脚，VCC 接 3.3V，GND 共地。
上拉电阻方面，STM32 芯片内部有上拉，但内部上拉阻值约 40kΩ，在 400kHz 下的上升沿会偏慢，波形不够陡峭。我一般外接两个 4.7kΩ 上拉到 3.3V。需要注意有些 0.42 寸模块自带电平转换和上拉电阻，这时候再加外部上拉会让总线驱动电流偏大，出现 SCL 低电平无法拉到底的情况。判断方法是看模块原理图里是否有 R 上拉丝印，不确定就直接测空闲时 SCL 电压是否等于 VCC。
3.2 初始化序列：标准 SSD1306 命令与 0.42 寸屏的差异
72x40 的初始化序列跟 128x64 的差别集中在三个寄存器：0xA8 复用比、0xDA COM 引脚配置、以及起始行地址。下面是我在项目里实际验证过的一套序列：
static void OLED_Init_Seq(void) { uint8_t init_cmds[] = { 0xAE, /* 关闭显示，进入初始化状态 */ 0xD5, 0x80, /* 时钟分频：默认值，保证内部振荡器稳定 */ 0xA8, 0x27, /* 多路复用比：40 行，必须写 0x27，128x64 屏写 0x3F */ 0xD3, 0x00, /* 显示偏移：0 行，默认不偏移 */ 0x40, /* 起始行地址 0：配合偏移量定位 RAM 到屏体映射 */ 0xA1, /* 段重映射：列地址 127~0 映射到 SEG0~SEG127 */ 0xC8, /* COM 扫描方向：从 COM39 到 COM0，配合 0xA1 镜像 */ 0xDA, 0x12, /* COM 引脚配置：0x02 是 128x64 的交替配置 */ 0x81, 0xCF, /* 对比度：0xCF 是 207，亮度偏高，可视环境调节 */ 0xD9, 0xF1, /* 预充电周期：0xF1 对 I2C 慢速写入更友好 */ 0xDB, 0x40, /* VCOMH 电压：0x40 约 0.77xVCC */ 0xA4, /* 关闭整屏点亮：必须确保不是 0xA5 */ 0xA6, /* 正常显示：0xA7 是反色，容易和 A6 混 */ 0xAF /* 打开显示：初始化序列最后一步，漏了必黑屏 */ }; OLED_WriteBuf(init_cmds, sizeof(init_cmds)); }逻辑说明：0xA8 后的 0x27 是这串序列里最关键的差异点，十进制是 39，代表屏体只有 40 行（第 0 到 39 行）。0xDA 后的 0x12 是 0.42 寸屏推荐值，0xDA 0x02 是给 128x64 用的交替 COM 配置，写在 0.42 寸屏上画面会左右分裂。0x81 对比度可以留到后面做菜单调光，不用在初始化阶段锁死。
3.3 写命令和写数据的两个原子函数
I2C 驱动 OLED 的核心就两个发送函数，一个写命令，一个写数据。它们的区别只有一个字节：控制字节是 0x00 还是 0x40。封装得好，后续画点、显示字符串全是基于这两个函数。
void OLED_WriteCmd(uint8_t cmd) { uint8_t buf[2] = {0x00, cmd}; /* 控制字节 0x00 表示命令 */ HAL_I2C_Master_Transmit(&hi2c1, 0x78, buf, 2, 100); } void OLED_WriteData(uint8_t dat) { uint8_t buf[2] = {0x40, dat}; /* 控制字节 0x40 表示显存数据 */ HAL_I2C_Master_Transmit(&hi2c1, 0x78, buf, 2, 100); }参数说明：HAL_I2C_Master_Transmit 的最后一个参数是超时时间，单位毫秒。100ms 看起来很长，但 I2C 总线如果被拉死，这个超时才能让程序从等待中解脱出来。这里有个性能问题：每写一个字节都要发起一次 I2C 传输，传输的数据只有 2 字节，但 I2C 起始条件、地址阶段和控制字节占了大头，实际效率只有 25% 左右。解决思路放到最后一章讲 DMA 时展开。
3.4 显存布局：5 页 x 9 字节，为什么画点要移位
SSD1306 的显存是按页组织的，一页是 8 行，72x40 的屏占 5 页（40/8=5），每页横向 72 个像素，按 8 个像素一组存一个字节，所以每页需要 9 字节（72/8=9），总共 45 字节。写入命令 0xB0 到 0xB4 选择页地址，0x00 到 0x08 选择列地址低 4 位，0x10 到 0x17 是列地址高 4 位。
画一个点的难点在于：一字节里存的是纵向 8 个像素，你要改的是其中某一位，必须先读出原来的字节再改，但 I2C 接口不提供读显存功能，只能在 MCU 侧维护一个 45 字节的 shadow buffer，画点先改 buffer 再整体刷到屏上。这是所有 I2C OLED 驱动的通用做法。
uint8_t oled_ram[5][9]; /* 5 页，每页 9 字节 */ void OLED_SetPixel(uint8_t x, uint8_t y, uint8_t on) { uint8_t page, col, bit; if (x >= 72 || y >= 40) return; /* 边界保护：72x40 分辨率 */ page = y / 8; /* 0~4，决定 0xB0~0xB4 */ bit = y % 8; /* 0~7，决定字节内的位 */ col = x / 8; /* 0~8，实际是字节索引 */ uint8_t mask = 1 << bit; if (on) { oled_ram[page][col] |= mask; } else { oled_ram[page][col] &= ~mask; } }边界保护那个判断必不可少。0.42 寸屏的宽只有 72，但如果你沿用 128x64 的例程，x 超过 71 时 col 会超过 8，显存写穿到下一页甚至直接越界。我调试时遇到过刷新后屏幕出现随机噪点，排查半天就是画点函数没做边界检查，把显存写穿了。
3.5 把 shadow buffer 刷上屏：页寻址模式与刷屏命令
刷屏是把 oled_ram 全部写入 SSD1306 的内部显存。这里的关键是理解页寻址模式下，写完一页数据后列地址会自动加 1，但页地址不会自动跳转，必须手动写 0xB0~0xB4 切页。
void OLED_Flush(void) { uint8_t page, col; for (page = 0; page < 5; page++) { OLED_WriteCmd(0xB0 + page); /* 设置页地址 0~4 */ OLED_WriteCmd(0x00); /* 列地址低 4 位：0 */ OLED_WriteCmd(0x10); /* 列地址高 4 位：0 */ for (col = 0; col < 9; col++) { OLED_WriteData(oled_ram[page][col]); } } }这段代码有两个值得说的点。第一个是列地址每次都从 0 开始，因为上一次刷屏结束后列地址停在 8，不重置就写到下一行去了。第二个是 OLED_WriteData 逐个字节传输效率低，但胜在实现简单，如果刷屏频率要求不高（比如 10Hz 以下），这个方案完全够用。追求效率的改进方案见第六章。
4. 从点线到字符：0.42 寸屏上的字库与坐标换算
4.1 取模方式：纵向取模和横向取模不能混用
OLED 显示字符，本质是把字模数组按顺序贴到显存里。字模取模工具有两种主流模式：纵向取模（列行式，字节内从上到下）和横向取模（行列式，字节内从左到右）。因为 SSD1306 显存本身就是纵向 8 位一字节，所以必须用纵向取模，也就是俗称的“列行式”或“逐列式”。
一个常见的翻车现场是：拿到一个 8x16 的字模数组，用横向取模的数据直接刷屏，结果显示出来的字符上下颠倒或左右镜像。这不是驱动代码的问题，是取模设置不对。我在工程里一般直接约定：PCtoLCD2002 选“阴码、列行式、逆向”，这样导出的数组和 SSD1306 的显存布局天然对齐。
void OLED_ShowChar(uint8_t x, uint8_t y, char c, const uint8_t *font8x16) { uint8_t page = y / 8; uint8_t bit_offset = y % 8; const uint8_t *p = &font8x16[(c - ' ') * 16]; /* 每个字符 16 字节 */ uint8_t i; for (i = 0; i < 16; i++) { uint8_t data = p[i]; if (bit_offset == 0) { /* 正好页对齐，直接写入 */ oled_ram[page][x / 8] = data; } else { /* 跨页显示：拆分到上下两页 */ oled_ram[page][x / 8] |= data << bit_offset; oled_ram[page + 1][x / 8] |= data >> (8 - bit_offset); } x++; if (x >= 72) break; /* 防止写穿显存 */ } }这里的跨页处理是 I2C OLED 驱动里最容易出 bug 的地方。y 不是 8 的倍数时，字符上半部分落在 page，下半部分落在 page+1，必须把一字节拆成两次移位写入。很多初学者直接在 y 是 8 的倍数时才显示字符，非对齐位置就乱码，就是这个移位逻辑没写对。另外注意这里用|=而不是直接赋值，是因为同一位置可能已经有其他内容，直接覆盖会把背景清掉。
4.2 坐标体系：72x40 屏的字符摆布策略
72x40 的屏比 0.96 寸的 128x64 小了将近一半，能放的字符数量有限。用 8x16 字体，一行最多 9 个字符（72/8=9），一共 2.5 行（40/16=2.5，第三行只能显示上半部分）。用 6x8 字体，一行 12 个字符，5 行刚好铺满。
我做小屏交互界面的习惯是：标题用 8x16 字体，正文用 6x8 字体，混合排版。例如状态栏显示电压值用 8x16 加粗数字，下面的参数说明用 6x8 普通字体。这样既保证关键信息醒目，又不至于让整个界面显得拥堵。坐标换算时记一个经验值：8x16 字符占宽 8、高 16，6x8 字符占宽 6、高 8，画布规划按这两个基本单位对齐，视觉上就不会歪。
4.3 显示数字和变量的通用套路：格式化到缓冲区
显示传感器读数或系统状态时，标准做法是把数值 format 到字符串再逐个显示。这里有一个芯片资源相关的坑：STM32 的 HAL 库如果开了微库（MicroLib），sprintf 可以正常用；如果没开，printf 系列函数会占用大量 Flash，可能链接失败。
void OLED_ShowValue(uint8_t x, uint8_t y, float val) { char buf[12]; char *fmt = (val < 0) ? "-%d.%02d" : "%d.%02d"; int ip = (int)val; int fp = (int)((val - ip) * 100); if (fp < 0) fp = -fp; sprintf(buf, fmt, ip, fp); OLED_ShowString(x, y, buf, FONT_8X16); }注意这个函数对负数的处理：先把整数部分取出来，再单独算小数部分，避免浮点转字符串时 -0.5 这种值出现负数符号串位的怪问题。我实际项目中用的方案更简单粗暴，直接把sprintf(buf, "%d.%02d", ip, fp)换成整数运算后手动填字符，能省掉整个 printf 依赖，缺点是代码稍长。新手阶段建议先开 MicroLib 用 sprintf，等工程尺寸紧张了再手写。
5. 避坑指南：I2C OLED 黑屏与乱码的六个典型故障
5.1 初始化发完了，屏幕还是黑的
现象：I2C 波形正常，每个字节都能收到 ACK，0xAE~0xAF 全序列执行完，但屏幕无任何显示。
原因一：0xAF 命令没执行或者执行后被后续代码改回了 0xAE。有些例程把开显示放在最后，但你在后面又调用了其他初始化函数重置了配置。原因二：复位引脚悬空，SSD1306 从未退出复位状态。原因三：对比度寄存器设置过低，0x81 后面跟了 0x00，面板亮度极低但并非全黑。
解决：先单独发 0xAF，确认屏亮（亮的是雪花的点亮状态而不是画面内容），再发 0xA5 看是否整屏点亮。0xA5 是忽略显存内容强制全部点亮，这个命令是最好用的硬件自检手段，能快速区分是驱动问题还是显存写入问题。
5.2 画面整体偏移，右侧出现残缺列
现象：显示内容整体右移了 8 个像素以上，右侧一部分内容跑到屏幕外面去了。
原因：初始化序列里少了 0xA1 或 0xA0 的段重映射设置，SSD1306 默认段方向是 SEG0 从右边开始。0.42 寸屏因为只引出了 72 列，段方向的缺省状态正好和面板引线相反，需要 0xA1 反向。
解决：在初始化序列里固定保留 0xA1 和 0xC8 这一对反向设置。注意如果用的是 SPI 版本、且模块带 DC 线，这个问题的表现是不一样的，SPI 下反段表现为镜像而不是偏移，I2C 下因为逐字节写入、列地址自增方向不同，表现出来更像错位。
5.3 I2C 总线死锁，程序卡在 HAL_I2C_Master_Transmit 不返回
现象：程序运行到 OLED 初始化时卡死，硬件调试发现卡在等待 I2C 总线空闲的事件，SCL 或 SDA 被拉低不释放。
原因：I2C 通信中途被打断，比如初始化 OLED 时恰好有高优先级中断插进来，中断里又操作了同一个 I2C 外设，导致时序错乱，总线状态机进入异常，总线被从设备拖住。
解决：I2C 通信期间不要嵌套同总线的操作，OLED 显示函数不要放在中断回调里直接调用。如果必须中断刷新，设置一个标志位，主循环检测到再调用刷新函数。真出现死锁可以用 GPIO 模拟的复位序列强制释放总线：SCL 先拉高，SDA 拉低再拉高，连续 9 个时钟脉冲把卡住的状态机复位掉。
5.4 屏幕显示有噪点或残影，刷新过后旧内容清不掉
现象：刷新新画面后，部分区域还残留上一次显示的内容，或者屏幕出现随机亮点。
原因：shadow buffer 和应用层使用的显存角色不一致。比如你有一个画点函数写的是 oled_ram_1，但刷屏函数刷的是 oled_ram_2，两个 buffer 是同一结构体的不同实例，内容不同步。另一个常见原因是画点函数的清屏操作只清了 shadow buffer 没刷到屏上。
解决：把清屏函数和刷屏函数配对调用，保证buffer 写入 -> 主动刷屏这个顺序在任何更新路径上都一致。我在这里还吃过一个亏：局部刷新时把一整页 9 字节发出去，但同一页的另外 8 字节在 shadow buffer 里是旧值，导致覆盖掉其他函数刚写入的新值。解决是局部刷新前先从 shadow buffer 读出整页再改再写。
5.5 SCL 频率太高导致花屏或丢数据
现象：OLED 初始化正常、显示正常，但刷新稍快就出现花屏，有时候整屏内容错乱。
原因：I2C 时钟配置成 1MHz。SSD1306 的 I2C 接口最高支持 400kHz（标准模式是 100kHz，快速模式 400kHz），往上超频不受保证。某些 STM32 主频高，I2C 外设时钟分频配置不当，实际 SCL 可能跑到 800kHz 以上。
解决：CubeMX 里把 I2C 时钟速度设为 400000，同时开启 I2C 的模拟噪声滤波器。如果 400kHz 仍然偶尔花屏，降到 300kHz 或 200kHz，代价是刷新率相应下降，但对于 0.42 寸这种小屏，肉眼看不出来。
5.6 屏幕亮度不均匀，部分区域偏暗
现象：整屏内容正常显示，但屏幕左边或右边局部区域明显比中间暗，尤其在亮度调高时更明显。
原因：0.42 寸屏幕体是上下两块面板拼起来的，SSD1306 驱动 72 列时，部分 COM 线的引出长度不一致，导致不同区域压降不同。对比度寄存器全局设置后，远端区域亮度更低。
解决：这是硬件特性，软件上能做的是 0x81 设全局对比度适中（0x80~0xBF），不要拉到 0xFF；显示设计上避免大面积纯色高亮区域，用反色突出关键信息而不是靠提高全屏亮度。如果项目对亮度一致性要求极高，建议换用其他尺寸屏或加分立的 OLED 驱动方案。
6. 进阶：用 DMA 把刷屏时间从 15ms 压到 5ms
前面章节的 OLED_Flush 函数逐字节调用 HAL_I2C_Master_Transmit，刷 5 页共 45 字节需要发起 45 次 I2C 传输，每次都有地址阶段和停止条件。实际测量 400kHz 下一次完整刷屏大约需要 15ms，对于显示静态数据够用，但做菜单滑动或数值动态刷新时能感觉到轻微闪烁。
优化思路是拼包：把控制字节和整页数据拼到一个连续缓冲区，一次 DMA 传输发一整页，5 页发 5 次，或者更进一步把 5 页全部拼成一个大数组外加每页的页地址命令，分两次传输（第一次发命令序列，第二次发全部显存数据）。
void OLED_Flush_DMA(void) { uint8_t cmds[15]; /* 5 页，每页 3 个命令 */ uint8_t data_buf[45]; /* 5 页 x 9 字节，前面拼 0x40 控制字节 */ for (uint8_t page = 0; page < 5; page++) { cmds[page * 3 + 0] = 0x00; cmds[page * 3 + 1] = 0xB0 + page; cmds[page * 3 + 2] = 0x00; cmds[page * 3 + 3] = 0x10; /* 这里其实是 3 个一组，注意数组长度 */ } /* 实际实现应分页发送，此处示意拼包思路 */ for (uint8_t page = 0; page < 5; page++) { uint8_t buf[12]; buf[0] = 0x00; buf[1] = 0xB0 + page; buf[2] = 0x00; buf[3] = 0x10; buf[4] = 0x40; /* 数据控制字节 */ memcpy(&buf[5], &oled_ram[page][0], 9); HAL_I2C_Master_Transmit_DMA(&hi2c1, 0x78, buf, 14, 100); } }我这里故意保留了一个注释要提醒的事：cmds 数组长度和索引计算容易出错，每页命令其实是 4 个字节（控制字节、页地址、列低、列高），不是 3 个。上面示例代码里 cmds 数组的写法有 bug，实际工程里更稳妥的方案是直接分页发送，每页发一个 14 字节的包，这样数据结构清晰，也不容易算错偏移。
另一个值得说的地方是 DMA 发送中途不能修改 buffer。如果你在 DMA 传输完成中断里直接改 oled_ram，下一帧刷新时可能发到一半数据变了，画面出现撕裂。常见做法是双缓冲：oled_ram 和 oled_ram_back 交替使用，DMA 发其中一个时应用层画另一个，发送完成中断里交换指针。0.42 寸屏的显存只有 45 字节，双缓冲只多花 90 字节 RAM，代价几乎可以忽略。
刷屏频率受限于 I2C 带宽，400kHz 下 45 字节数据加命令开销约 2ms 内能完成，实际测得 5 页分五次传输的耗时约 6ms，比逐字节调用的 15ms 快了一倍多。如果你想再快，可以把页地址命令和数据全部拼成一个大数组，只发起一次传输，这样能压到 3ms 以内。但代价是每次刷屏要准备 45+20=65 字节的缓冲区，而且要保证页地址正确切换，拼包的索引计算要仔细验证。
这个 DMA 方案我用在一个小型可调电源的项目里，OLED 每秒刷新 10 次电压电流值，CPU 占用从逐字节方案的 15% 降到了 3% 不到。当时遇到最莫名其妙的问题是在 DMA 完成中断里调用了 OLED_WriteCmd 切换页地址，导致下一次 DMA 传输的起始列地址乱掉。教训是 DMA 刷屏期间，所有 I2C 操作都要等传输完成事件之后再发起，中断里只置标志位、不碰 I2C 外设。如果你也在这个方案上折腾，记住一条：把 DMA 传输完成中断的优先级设为低于应用层刷新任务，用标志位同步，能避免百分之九十的诡异花屏。希望帮到你。
本文还有配套的精品资源，点击获取
