CH340在macOS上的串口通信：从“设备未识别”到稳定烧录的完整实践路径
你刚把Arduino Uno（用的是CH340芯片）插进Mac，打开Arduino IDE，端口列表里却空空如也；或者ls /dev/cu.*什么都没输出；又或者avrdude报错stk500_recv(): programmer is not responding——别急着换线、换板、重装系统。这几乎不是硬件问题，而是macOS和CH340之间一次没谈拢的“握手”。
这不是玄学，是可诊断、可复现、可闭环解决的工程问题。
为什么CH340在Mac上总“失联”？一句话说清本质
CH340本身是一颗符合CDC ACM类规范的USB设备——它不宣称自己是“某个厂家的私有芯片”，而是老老实实告诉Mac：“我是一个标准的USB串口设备”。理论上，macOS只要加载了通用CDC驱动（比如Apple自带的AppleUSBSerial.kext），就该自动识别它。
但现实是：Apple从未将CH340的VID/PID（0x1a86/0x7523）加入其内建串口驱动白名单。
所以当Mac看到这个设备时，反应是：“哦，是个CDC设备……但我没被授权管你。”
结果就是：USB设备出现在系统报告里（system_profiler SPUSBDataType能看到），但没有/dev/cu.usbserial-*节点，也没有串口抽象层——上层工具（screen,minicom,esptool,avrdude）自然全部失效。
换句话说：CH340不是不工作，是Mac根本没给它分配“说话的资格证”。
驱动不是“装上就行”，而是要“对得上号”
macOS对驱动的接纳，像一场层层设防的签证审核：
| macOS版本 | 驱动形态 | 审核方式 | 典型障碍 |
|---|---|---|---|
| ≤ 10.14 Mojave | KEXT（内核扩展） | SIP保护下默认拒收 | 安装后黑屏/设备不出现，需手动点「允许」+重启 |
| 10.15–12 Monterey | 签名KEXT | 强制代码签名 + 用户明确授权 | “已阻止已加载的系统软件”提示，必须去「安全性与隐私」里点“允许” |
