ESP32-P4 USB读卡器实战：从MSC到FatFs，把开发板变成U盘-平芜编程栈

作为一个经常在ESP32系芯片上折腾USB应用的工程师，看到这个实验标题我其实挺有感触的。“USB读卡器（Slave）”这几个字看起来简单，就是把开发板接上电脑，让PC把板子当成一个大号U盘来识别。但真正动手做的时候，里面牵扯到的协议栈、存储介质、文件系统、枚举时的时序配合，随便哪一个环节出问题，都能让人折腾一个下午。

所以我决定把这个实验从原理到实操完整拆一遍，把我自己踩过的坑、调过的参数、查过的寄存器都写出来。这篇内容主要面向正在看《DNESP32P4开发指南_V1.0》第四十九章的读者，也适合任何想在ESP32-P4上快速实现USB MSC设备（U盘）功能的嵌入式开发者。

1. 实验总体认识：一块开发板如何“伪装”成U盘

1.1 这个实验解决什么问题

USB读卡器（Slave）实验的核心目标，是把DNESP32P4开发板上的USB端口配置成设备模式，让PC主机将其识别为一个Mass Storage Class（大容量存储类）设备，表现出来的效果就是电脑里多了一个盘符，你可以像操作普通U盘一样去读写文件。

对于嵌入式开发者来说，这个功能真正解决的是“文件交互”这个老大难问题。平时我们调试设备，要把里面的日志、配置、固件备份拿出来，要么用串口慢慢导，要么用网络传输，都不太方便。如果把板子变成一个U盘，插入电脑就能直接拖拽文件，对产品量产、数据采集、固件升级这些场景都有直接价值。

从技术角度来说，这个实验也是理解USB协议栈的绝佳入口。USB协议非常庞大，MSC类是其中比较“纯粹”的一类——它没有HID那样复杂的报表描述符，也没有CDC那样需要管理虚拟串口和中断端点，MSC只需要处理批量传输（Bulk Only Transfer，BOT）和SCSI命令，逻辑链路比较清晰，特别适合作为学习USB从设备的第一个完整实验。

1.2 USB Slave模式与读卡器的核心链路

在开始看代码之前，我建议先在脑子里建立这条完整的数据链路：

PC主机（USB Host） ↓ USB总线（D+/D-差分信号） DNESP32P4 USB OTG控制器（Device模式） ↓ SCSI命令解析（MSC类协议） FAT文件系统层（FatFs） ↓ 底层块设备读写 存储介质（SD/TF卡或板载Flash）

这条链路非常关键。很多新手只盯着“USB枚举”部分，以为设备能被识别就完事了。但读卡器实验的难点恰恰在下半段：当PC发来一个SCSI READ命令，请求读取某个逻辑块地址（LBA）的数据时，你的板子必须去存储介质的对应位置，把256字节或者512字节的数据翻出来，原路返回给主机。这个过程中任何一层的接口不匹配、时序超时，都会表现为PC端“写入失败”或者“设备无响应”。

在这个实验里，DNESP32P4的USB外设工作在Slave侧，用的是芯片自带的USB 2.0 HS OTG控制器，最高理论速率480Mbps。但实际我们能体验到的读写速度远远达不到这个值，因为瓶颈在存储介质的读写速度和FatFs文件系统的处理效率上，这一点后面实测部分我会给出数据。

1.3 开发板与外设选型

DNESP32P4开发板是正点原子基于乐鑫ESP32-P4芯片做的高性能开发板，集成了双核RISC-V处理器，主频可以到400MHz，配上USB 2.0 HS OTG接口，做这个实验非常合适。

存储介质方面，我强烈建议首选SD/TF卡，而不是芯片内置的Flash。原因很简单：

SD卡本身就是按块设备设计的，和MSC类天然匹配
你可以随时把卡拔出来插到电脑上，直接验证数据有没有写对
读卡器读卡器，用卡才符合直觉

如果开发板上有TF卡槽，那直接插卡用；如果没有，可以用SPI方式外接一个TF卡模块。DNESP32P4开发板我记得板载了TF卡槽，而且引出的引脚比较友好，省去了很多飞线的麻烦。

2. 原理深挖：USB枚举、MSC类与文件系统三者如何协作

2.1 USB设备枚举流程

要理解USB读卡器，绕不开枚举（Enumeration）这个过程。所谓枚举，就是USB主机和USB设备建立通信的第一步，有点像两个人见面先互报家门。

当DNESP32P4通过USB线插入PC时，PC会检测到D+线上的上拉电阻信号（全速设备是1.5kΩ上拉到3.3V），然后开始复位总线、发送一系列标准请求。设备收到这些请求后，需要按顺序返回设备描述符（Device Descriptor）、配置描述符（Configuration Descriptor）、接口描述符（Interface Descriptor）、端点描述符（Endpoint Descriptor）等。

对于MSC设备来说，标准请求里面最有意思的是SET_CONFIGURATION，一旦执行到这个请求，主机就认定了设备的工作模式。随后主机会发送GET_MAX_LUN类专用请求，询问设备支持多少个逻辑单元（LUN）。读卡器通常返回1，代表一个盘符。

枚举过程全部走端点0（控制端点），速度相对较慢，但是MSC真正数据传输走的是批量端点（Bulk Endpoint）。TinyUSB协议栈在后台自动完成了枚举阶段的工作，我们在应用层只需要注册好描述符，剩下的交给协议栈处理。这也是为什么现代嵌入式开发不用像十年前那样手写USB状态机了。

2.2 MSC类协议与SCSI命令

枚举完成后，MSC设备就进入了BOT（Bulk-Only Transport）传输模式。这个模式说起来其实很规整，每笔事务都由三个部分组成：

主机先发送一个CBW（Command Block Wrapper），里面带有命令块
然后主机和设备之间传输数据（方向由CBW中的标志位决定）
最后设备返回一个CSW（Command Status Wrapper），报告命令执行状态

CBW里包着的命令就是SCSI命令。MSC设备经常要处理的SCSI命令包括：

INQUIRY：主机询问设备的基本信息（厂商、产品名、版本）
READ CAPACITY：主机询问设备总共有多少扇区，扇区多大
TEST UNIT READY：主机询问设备是否就绪
READ(10)、WRITE(10)：实际的数据读写命令
REQUEST SENSE：设备返回错误信息时使用

我刚开始做这个实验时，总觉得SCSI命令很神秘。后来打印一下调试日志才发现，Windows在枚举U盘时发的命令就那么几条，而且是固定顺序。你可以把它理解成一个“握手”过程：电脑先问“你是谁”，再问“你有多大”，然后就开始源源不断地发READ和WRITE命令。

这里有一个非常重要的细节：MSC设备的底层是按扇区（通常是512字节）寻址的，PC会把读卡器当成一块裸盘，而不是一个文件系统。你看到的盘符和文件，是PC上的操作系统基于FAT文件系统自己解析出来的。这也就意味着板子本身不一定非要跑文件系统——它只需要把扇区数据原样返回给PC即可。

2.3 FatFs为什么要参与

既然MSC只需要读写扇区，那为什么很多读卡器实验还非要挂一个FatFs？这也是我自己绕了一圈才想明白的问题。

答案是：为了底板和介质之间的“胶水”关系。

如果你的存储介质是SD卡，并且SD卡上已经格式化为FAT32，那么在MSC转发扇区时，理论上确实可以不跑FatFs。但问题是，SD卡在SPI模式下初始化时，需要发送ACMD命令来读取卡容量、确定块大小等参数，这些信息需要一套代码来管理。在ESP-IDF生态里，这一套代码就是FatFs底层的diskio接口——它得先通过底层驱动把SD卡“激活”，才能做扇区级读写。

更进一步说，在TinyUSB的MSC回调中，给上层提供的是“read block”和“write block”这样的接口。如果直接用SDMMC或SDSPI的驱动，还需要自己封装一层。而FatFs本身就定义好了disk_read、disk_write、disk_status这些接口，SD卡驱动只要把接口对应上，然后MSC回调再调用disk_read、disk_write，代码结构就非常清晰。

所以FatFs在这里的角色，更像是一个“统一抽象层”——它让上层MSC逻辑和底层SD卡驱动解耦。你把SD卡换成SPI Flash，也只要换掉diskio的实现，MSC的代码完全不用动。这个设计思想在嵌入式里非常实用。

3. 环境与硬件准备

3.1 硬件接线与引脚确认

做这个实验之前，先把硬件接线理清楚，避免后面排查时一头雾水。

DNESP32P4开发板的USB接口通常不止一个。一个用于调试/烧录，一个用于USB OTG功能。做Slave实验时，必须把USB线接到OTG那个接口上，插错的典型症状就是“电脑完全没反应”。这个我在第一次做的时候还真犯过，当时办公桌上USB线一大堆，随手抓起一根就插，结果折腾了十分钟才发现是接口错了。

如果使用TF卡模块，接线要特别注意。SD卡SPI模式的引脚定义一般包括：

CS（片选）
SCK（时钟）
MOSI（主出从入）
MISO（主入从出）

在DNESP32P4开发板上，如果是板载TF卡槽，通常已经接好了，只需要在代码里确认对应的GPIO编号。如果是自己飞线，尽量把引线剪短，SPI时钟频率可以先降到1MHz验证通信，再调高。

USB线方面，建议使用质量好的带屏蔽数据线。很多人忽略这一点，但USB高速信号对线材质量很敏感，劣质线材可能导致枚举失败或者数据传输CRC错误，这个坑我踩过，后面排查章节会详细说。

3.2 ESP-IDF与TinyUSB组件配置

软件环境方面，我使用的是ESP-IDF v5.2以上的版本，里面已经集成了TinyUSB组件的支持。ESP32-P4这个芯片较新，建议使用IDF v5.2.1或者更新版本搭配V1.0指南使用，避免遇到芯片支持不完整的问题。

TinyUSB是Adafruit发起的一个开源USB协议栈，专门为嵌入式设备设计，代码紧凑、支持类多、文档清晰。ESP-IDF官方将它作为组件引入，提供了一套esp_tinyusb封装API。我们不需要深入了解USB描述符内部的每一个字节，但需要会配置最关键的结构体。

一个重要概念：TinyUSB是跑在实时操作系统上的，它有自己的任务调度。如果你用的是FreeRTOS，TinyUSB组件会创建后台任务来处理USB中断和数据收发。应用层只需要通过回调函数来感知事件和处理数据。

在menuconfig里，我习惯开启以下配置项：

Component config → TinyUSB → Enable TinyUSB stack
USB Vendor/Device settings 里设置VID/PID，默认的可以先用
TinyUSB Class drivers 里勾选 Mass Storage Class driver

这里说一下VID/PID，Vendor ID是厂商ID，Product ID是产品ID。没有公司的开发者可以先用Espressif的测试VID，或者使用TinyUSB示例里的默认值。如果你以后要量产，必须向USB-IF申请自己的VID，或者购买第三方VID，不然设备在系统里会显示为未知厂商。

4. 核心代码实现：把SD卡暴露成U盘

4.1 存储介质初始化

存储介质初始化是整个实验的基础。这里我以SD卡（TF卡）为例，先把SD卡的驱动层搞定。

在ESP-IDF中，SD卡初始化有两种方式：SDMMC（4位模式）和SDSPI（SPI模式）。DNESP32P4开发板上如果TF卡槽接到了SDMMC控制器，用SDMMC模式速度更快；但如果是普通IO模拟的SPI，那就走SDSPI。

初始化代码可以简化为：

#include "esp_vfs_fat.h" #include "sdmmc_cmd.h" #include "driver/sdmmc_host.h" #include "driver/sdspi_host.h" sdmmc_host_t host = SDMMC_HOST_DEFAULT(); sdmmc_slot_config_t slot_config = SDMMC_SLOT_CONFIG_DEFAULT(); esp_vfs_fat_sdmmc_mount_config_t mount_config = { .format_if_mount_failed = false, .max_files = 5, .allocation_unit_size = 16 * 1024 }; sdmmc_card_t *card; esp_err_t ret = esp_vfs_fat_sdmmc_mount("/sdcard", &host, &slot_config, &mount_config, &card);

这里有一个值得玩味的参数：allocation_unit_size，也就是文件系统的分配单元大小。这个值越大，大文件读写的效率越高，但小文件会浪费更多空间。对于U盘应用，我建议设为16KB或者32KB，PC端格式化U盘时通常也默认这个级别。

如果挂载成功，你会在日志里看到SD卡的信息：制造商ID、卡容量、传输模式等。挂载失败时，要重点检查SPI接线、卡是否格式化、卡是否损坏这几个点。

我对一个有趣的细节印象很深：如果你在电脑上把TF卡格式化成exFAT，在传统FatFs版本的esp_vfs_fat_sdmmc挂载时可能会失败。因为老版本FatFs默认不带exFAT支持。解决方法是格式化成FAT32，或者在menuconfig里启用exFAT支持。做U盘实验，首选FAT32。

4.2 MSC回调函数实现

SD卡挂载好了之后，接下来就要把底层的块设备操作接口暴露给TinyUSB的MSC类。

在ESP-IDF的tinyusb组件里，MSC注册接口大致如下：

#include "tinyusb.h" #include "tusb_msc.h" static int32_t msc_read(uint32_t lba, uint32_t offset, void *buffer, uint32_t bufsize) { size_t sect_count = bufsize / SD_SECTOR_SIZE; // 调用FatFs底层disk_read接口 return disk_read(0, buffer, lba, sect_count); } static int32_t msc_write(uint32_t lba, uint32_t offset, const void *buffer, uint32_t bufsize) { size_t sect_count = bufsize / SD_SECTOR_SIZE; // 调用FatFs底层disk_write接口 return disk_write(0, buffer, lba, sect_count); } static int32_t msc_scsi_command(uint8_t lun, const uint8_t *scsi_cmd, uint8_t *buffer, uint32_t bufsize) { // 这里处理特殊SCSI命令，一般返回CBI_INVALID_CMD或者调用底层判断 return CBI_INVALID_CMD; } void msc_setup(void) { tinyusb_msc_config_t msc_cfg = { .vendor_id = "Espressif", .product_id = "MSC Demo", .callback = msc_event_cb, .read = msc_read, .write = msc_write, .scsi_command = msc_scsi_command, }; tinyusb_msc_register(&msc_cfg); }

这里最需要注意的，是lba（逻辑块地址）和offset这两个参数的区别。lba是PC请求的逻辑块号，比如PC想读取第1000个扇区，lba=1000。offset是缓冲区内的小偏移，通常用不到，但必须返回正确，否则PC端会读到错乱数据。

bufsize这个参数也值得一提。USB高速模式下，PC一次批量传输最多能带65536字节（64KB），但实际MSC通常按照SCSI READ(10)命令里指定的传输长度来。我们的底层磁盘读写接口必须能处理非512字节倍数的请求吗？事实上POSIX风格的磁盘接口都会按照扇区对齐，但MSC回调返回DMA时要注意性能，最好在读取时使用缓冲区对齐访问。

一个容易踩的坑是：TinyUSB的MSC回调中，read和write回调返回的是实际传输的字节数，如果失败要返回负数。很多示例代码里写的是返回字节数，这一点和普通disk_read函数的返回值含义不同。我在调这个的时候，日志上总是报“SCSI错误”，就是返回值搞错了。

我习惯在回调里加打印，但要注意，如果打印太频繁会拖慢USB传输。建议用一个带开关的调试宏，只在调试期打开。

4.3 USB设备栈启动与主循环

存储介质初始化好、MSC回调注册好之后，就剩下最后一步：启动TinyUSB设备栈。

在ESP-IDF里，启动代码非常简洁：

void app_main(void) { // 1. 初始化SD卡并挂载FAT sdcard_init(); // 2. 注册MSC回调 msc_setup(); // 3. 启动TinyUSB设备栈 tinyusb_device_config_t tusb_cfg = { .device_descriptor = NULL, // 使用默认描述符或者自定义 .string_descriptor = NULL, .external_phy = false, .configuration_descriptor = NULL, }; tinyusb_driver_install(&tusb_cfg); // 4. 主循环 while (1) { vTaskDelay(pdMS_TO_TICKS(10)); } }

启动时有一个非常关键的细节：configuration_descriptor是否需要自己定义。使用TinyUSB自带的MSC描述符时，协议栈会基于默认配置生成描述符，一般情况下够用。但如果你希望U盘显示一个自定义的厂商名、产品名或者序列号，就需要自己构造字符串描述符，并在上一步的string_descriptor里传入。

另外一个重要点：TinyUSB的设备栈需要响应USB中断，而ESP-IDF的移植已经封装好了。主循环里不需要调用任何TinyUSB的task函数，但如果你遇到“插入这个板子没有反应”的问题，可以检查自己的固件里是否意外地暂停了USB外设时钟，或者被某些低功耗模式干扰。

我记得在某个版本IDF上，如果不调用tinyusb_driver_install的tusb_cfg中配置external_phy，高速模式下的外部PHY会被错误启用，导致HS枚举不上。后来发现ESP32-P4内置了USB PHY，这个参数必须保持为false。这类问题在不同芯片、不同IDF版本上行为确实不一样，所以遇到枚举异常时，第一步就要去核对官方示例的配置。

5. 编译、烧录与实测

5.1 menuconfig关键配置项

在终端里运行idf.py menuconfig，需要重点确认以下配置：

配置项	推荐值	说明
TinyUSB stack	Enabled	打开TinyUSB协议栈
Mass Storage Class	Enabled	使能MSC类驱动
USB Vendor ID	0x303A（乐鑫测试VID）	可自定义
USB Product ID	0x4002	避免冲突
USB Device Speed	High Speed 或 Full Speed	根据芯片和线材
Compiler optimizations	Size 或 Debug	调试期用Debug，发布用Size

高速和全速的选择需要特别说明。ESP32-P4的USB控制器支持HS（480Mbps），但在很多情况下FS反而更稳定——即便枚举成FS，实际速度对U盘应用也完全够用。如果线材质量一般，强制HS可能导致链路协商失败，反而不如FS稳定。我先用HS试了一圈，实测在PC上写入速度只有FS的好一点点，那干脆就老老实实用FS了。

5.2 编译烧录步骤

确认配置之后，编译烧录步骤和普通ESP-IDF工程一样：

idf.py set-target esp32p4 idf.py build idf.py -p /dev/ttyUSB0 flash monitor

烧录时注意，如果调试串口和USB口是同一个口，那么烧录过程中不要插着设备模式的USB线，否则可能出现端口占用或供电冲突。

我实测时在板子上烧完固件，重新上电，然后插上USB线到电脑，Windows会提示“发现新硬件”。如果驱动正常，设备管理器里会出现“大容量存储设备”，同时“我的电脑”里多出一个盘符。整个枚举过程大概两三秒。

固态硬盘和U盘不同，U盘第一次插入时系统会读取分区表，如果SD卡上之前没有分区，Windows只会提示“需要格式化磁盘”。这时选择FAT32格式，格式化完成后就能正常拖文件了。

5.3 Windows/Linux实测表现

我分别做了写入和读取测试：

写入一个10MB的压缩包：开始速度能到5MB/s左右，后面会掉到3MB/s上下
从U盘回读这个文件到PC：读取速度比较稳定，在4-6MB/s之间
创建100个1KB的小文件：总耗时比较长，文件系统开销很明显

这个速度肯定是没法当高速U盘用的，但作为嵌入式设备导出日志、存配置文件的方案，已经完全够用了。核心需求是“不依赖串口/网络，插上就能拷数据”。

在Linux下直接lsblk能看到/dev/sd*设备，sudo mount /dev/sda1 /mnt/usb挂载后一样正常读写。但Linux下有个很小的细节：拔出U盘前要sync，否则缓存中的数据可能因为设备没响应而丢失。这个习惯在Windows下也适用，安全弹出还是很有必要的。

6. 常见问题与排查速查表

6.1 枚举失败/识别不到设备

现象：插入USB线后电脑完全没反应，设备管理器里没有任何变化。

排查步骤：

确认USB线插的是OTG接口，而不是调试串口接口
确认TinyUSB栈已经在main中被启动
查看串口日志，是否有TinyUSB初始化失败的错误
检查接线，D+和D-有没有接反，有没有虚焊
换一根线材试试，劣质线材最容易出这种问题

如果日志里出现TUSB ERROR: Device error，那多半是描述符配置有问题。此时建议先把自定义描述符全部注释掉，用默认配置跑通基础流程，再逐步加回自定义内容。

6.2 格式化失败或容量不对

现象：电脑识别到了设备，但提示“Windows无法完成格式化”。

这种情况十有八九是MSC回调中的底层读写函数返回错误。格式化过程会对每个扇区做读写校验，任何一次READ或WRITE失败，都会导致格式化中止。

排查时，先在代码里用串口打印出每次SCSI命令的LBA和长度值，看看有没有超出SD卡容量的请求。如果SD卡容量是32GB（约62500个扇区），而host请求读取LBA 80000000，那肯定是底层填写的容量信息不对。检查READ CAPACITY回调是否返回了正确的扇区数。

另外一个常见原因：disk_read和disk_write底层访问的磁盘卷编号不对。ESP-IDF的FatFs最多支持多个卷，如果MSC回调里写死了卷0，而SD卡实际挂载在卷0，那没问题；但如果中途改过挂载逻辑，可能导致卷号错位。

6.3 读写速度慢

现象：能正常读写文件，但速度只有几百KB/s。

优先排查是否跑在了Full Speed（12Mbps）模式下。Full Speed的理论速度也就1MB/s出头，如果线材有干扰，峰值速度上不去很正常。但如果是HS模式下的几MB/s降至几百KB/s，那问题往往出在底层README命令的块大小上传，可能没有充分利用多扇区传输。

SD卡驱动里建议使用多块读写命令（如CMD18/CMD25），而不是单块读写（CMD17/CMD24）。单块读写时每次都要发命令、等待响应，开销太大。

还有一点容易被忽视：TinyUSB的MSC数据缓冲区是否做了对齐处理。DMA外设通常要求4字节甚至16字节对齐，如果协议栈传入的缓冲区地址不对齐，底层SD驱动会走慢速的缓存路径。解决方法是在MSC配置结构体里指定对齐的缓冲区，或者用heap_caps_malloc分配内存。

6.4 拔插崩溃/复位

现象：正常使用时没问题，但直接拔USB线或者PC端安全弹出后，板子重启甚至panic。

这个问题本质上是热拔插处理没做周全。USB设备被拔掉后，总线上的中断和DMA访问可能会访问已经不存在的硬件状态，导致触发保护异常。

我的经验是两个方面：

在TinyUSB的事件回调里监听TUSB_EVENT_DEVICE_DISCONNECTED，在该事件中调用存储介质卸载，把打开的FatFs文件全部关闭
设立一个“设备在线”标志位，MSC的read/write回调先检查标志位，如果设备已经断开，立即返回错误，而不是继续访问SD卡

Panic时的日志可以定位到是访问哪个地址发生了问题，通常在sdmmc_read_sectors或者disk_read内部。这时把香炉先放下，不要急着去改底层，先看看是否已经正确优雅地处理了拔插事件。

7. 实验之外：这个能力的真实价值

做完整个实验，我最大的收获倒不是亲手做出了一个U盘，而是搞清楚了USB存储类设备从“枚举”到“扇区读写”的完整数据流。这个知识可以无缝扩展到很多真正的产品场景：

一是固件升级和配置备份。很多嵌入式设备要求“升级固件最可靠的方式”——不需要上位机软件，把设备插入电脑，把固件文件拖进盘符，拔出来，设备自己解析文件完成升级。这套方案在工业HMI、医疗仪器、数字示波器里非常常见。

二是数据导出。设备采集了大量传感器数据，平时存在SD卡或Flash中，需要定期回传给PC分析。有了USB MSC能力，现场人员不需要安装任何驱动和数据采集软件，插上电脑直接拷贝，对非技术人员非常友好。

三是桌面端交互。如果你做的是创客玩具、桌面键盘、智能硬件，USB读卡器可以是其中一个附加功能。比如一个带无线配置功能的Wi-Fi模组，插上电脑时显示为一个U盘，用户编辑里面的配置文件来设置Wi-Fi密码，配置完成后拔下，设备自动切换到正常模式。这个交互模式比做App或者网页配置要省事得多。

从学习层面讲，这个实验把USB协议、存储介质、文件系统这三个嵌入式领域的核心模块串成了一根线。你能画清楚这张数据流图，以后去做USB网卡（CDC ECM）、USB声卡（UAC）、USB HID设备，底层思路都是相通的——无非是换一套类驱动、换一批端点描述符、换一组回调函数。

我在实际做这个实验时还有一个体会，就是“先让数据通路跑起来，再去做优化”。不要一上来就想把速度做到满速、把代码结构设计得多么优雅。先拿原始SD卡、默认配置、CubeMX自动生成的代码跑通一个最小系统，在日志里看到SCSI命令正常执行、文件能拷进去，再一步步换高性能方案。嵌入式调试最忌讳的就是在黑盒子里瞎猜，把数据通路每一级都打印出来，故障点一定藏不住。