用 ESP32 做 WebDAV NAS：从 USB Host 到 SD 卡的迂回

目标是让一块带屏的 ESP32 开发板变成局域网里的网络存储。最终落地是 SD 卡走 SPI + WebDAV 服务，但中间绕了一大圈——先尝试了 USB Host 挂移动硬盘，撞上了一堵硬件墙。

第一版设想：USB Host 挂移动硬盘

最初的想法是让 ESP32 当 USB Host，外接 U 盘或移动硬盘。固件里 USB 挂载逻辑用 MSC 大容量存储协议，代码本身是通的，但真机一测，设备死活不识别。

撞墙：T-QT Pro 的 Type-C 口是「纯设备口」

排查了好几轮，最后的根因在硬件层，而且无法用代码绕过。查官方原理图，有三个决定性证据：

flowchart LR
    VBUS[Type-C VBUS] -->|IN5819 二极管| P5[+5V 充电/供电]
    CC1[CC1] -->|5.1K 下拉| GND[GND]
    CC2[CC2] -->|5.1K 下拉| GND

1. VBUS 走二极管单向输入：IN5819 肖特基二极管单向导通，5V 只能"流进"板子，"流不出去"给下游设备供电
2. CC1/CC2 都接 5.1K 下拉：这是 USB-C 规范里 Device（UFP）角色的标准配置，硬件上写死了"我是设备"
3. 数据线 D+/D- 是对的：所以数据信号能切到 Host，但供电被堵死

结论：数据线通了，供电线被二极管堵死。下游 U 盘没电，自然不亮灯、不识别。这不是代码问题，是这块板子天生就不适合做 USB Host——它本来就是"显示 + 烧录口"的定位。

延伸问题：那 NTFS 硬盘能挂吗？

排查过程中还顺带理清了一个更根本的问题——NTFS 在 ESP32 上"永远不可能"，四重原因叠加：

原因	说明
规范闭源	NTFS 规范微软从未公开，现有驱动全是逆向产物
无嵌入式驱动	FatFs 作者明确声明永不支持 NTFS
硬件扛不住	MFT/日志/4KB 元数据需要的内存远超 ESP32 的 280KB RAM
有完美替代	exFAT 规范公开、FatFs 成熟支持，NAS 场景无区别

所以最后固件支持 FAT32 + exFAT（exFAT 原本被 ESP-IDF 默认关闭，需要手动启用）。

转向 SD 卡 SPI 方案

USB Host 走不通，存储换成 SD 卡走 SPI——正好用上芯片上另一路空闲的 FSPI 总线：

SD 卡引脚	接 T-QT Pro
CS	GPIO34
MOSI	GPIO35
SCK	GPIO36
MISO	GPIO37
VDD	3.3V（⚠️ 别接 5V）

这路 SPI 和屏幕的 SPI 完全隔离，SD 卡初始化走 SPI3_HOST，还顺手解决了 USB Host 会把串口切走、导致无法看日志的麻烦。

WebDAV 服务

基于 ESP-IDF 实现 WebDAV 协议，处理 PROPFIND / GET / PUT / DELETE 等基础方法，让桌面端、手机端都能把它当作网络磁盘挂载。

这里有个很典型的认知坑：WebDAV ≠ 网页服务器。浏览器直接访问 http://设备IP/ 会 404——因为浏览器发的是 GET / 要网页，而 WebDAV 根目录是个文件夹不是 index.html。正确用法是"挂载网络驱动器"，不是"浏览"。

过程中的硬件细节

• USB 2.0/3.0 都认，但都降速：ESP32-S3 USB Host 是 Full-Speed（12Mbps），实际吞吐约 1MB/s，插什么都跑不出这个天花板
• 多分区只认第一个：msc_host_vfs_register 默认只挂第一个分区
• VCC/VDD 供电判断：SD 卡模块板上有没有 AMS1117 稳压芯片，决定 VCC 该接 5V 还是 3.3V

体会

这个项目最大的收获是理解了嵌入式方案的边界由硬件决定——供电、引脚、总线、规范公开性，每一个都可能在某个环节把路堵死。与其硬磕，不如顺着硬件的真实能力重新设计，方案反而更快收敛。