CH340插上没反应？别急着换线，先看看Windows是不是在“拒载”你的驱动
你有没有遇到过这种情况：手头一块CH340转串模块，明明以前用得好好的，今天一插电脑——设备管理器里蹦出个“其他设备 → USB-SERIAL CH340”，右下角还挂着黄感叹号。点进去一看，错误代码28：“该设备未成功安装驱动程序，找不到驱动程序”。
更离谱的是，你明明已经从官网下了最新版驱动、一路“下一步”装完，结果系统还是不认账。
不是驱动没装，而是Windows压根不让你装。
为什么“装了”也等于“白装”？
问题不在硬件，也不在驱动本身，而在于现代Windows系统的“安保机制”太严格了。
从Windows 10 64位系统开始，微软强制启用了驱动签名验证（Driver Signature Enforcement, DSE）——简单说就是：所有要进入系统内核的驱动，必须持有由微软信任的CA机构签发的数字证书，否则一律“拒之门外”。
听起来很安全对吧？但现实是：
- 很多国产芯片厂商（比如南京沁恒WCH）出于成本考虑，并未为每一版驱动申请昂贵的EV代码签名；
- 一些老版本CH340驱动使用的签名证书已被微软逐步淘汰（尤其是2020年后不再接受传统SHA-1签名）；
- 即使你手动指定INF文件安装，系统仍会弹窗警告：“此驱动程序未通过Windows徽标测试”，然后默默拒绝加载
.sys文件。
于是你就卡在这一步：驱动就在眼前，可就是“差那么一口气”。
🔧 典型症状：
- 插入设备后无法分配COM口
- 手动更新驱动时提示“发布者不可信”
- 安装日志显示“驱动被阻止加载（Code 52）”
这不是你的操作问题，而是系统策略和低成本外设生态之间的典型冲突。
想让CH340正常工作？得先让Windows“睁一只眼闭一只眼”
解决思路很明确：临时或永久绕过驱动签名检查，让未签名或自签名的驱动也能顺利加载。
下面这三种方法，按风险递增排序，你可以根据使用场景灵活选择。
方法一：重启进“无签名模式”｜适合临时调试，零修改
如果你只是想快速验证板子能不能通信，完全不需要改任何设置。Windows本身就留了个“后门”：禁用驱动签名强制检查的一次性启动选项。
✅ 操作步骤（Win10/Win11通用）
- 打开【设置】→【更新与安全】→【恢复】
- 在右侧找到“高级启动”，点击【立即重新启动】
- 进入蓝屏菜单后依次选择：
- 疑难解答 → 高级选项 → 启动设置 → 重启 重启后按
F7或直接按7键，选择：Disable driver signature enforcement系统正常启动后，立刻插入CH340设备
- 此时再去设备管理器中手动更新驱动，指向你下载好的CH340驱动目录
✅ 成功标志：驱动安装完成，设备状态变为“这个设备运转正常”，并分配了COM端口号（如COM4）。
💡 小贴士：这个模式只生效一次，下次重启自动恢复保护状态，安全性高，非常适合实验室调试。
方法二：开启测试签名模式｜开发者的日常工具箱
如果你经常需要测试各种自制驱动、开源固件或者非标硬件，可以长期启用“测试签名模式”。虽然桌面上会有水印，但它能极大提升开发效率。
🛠️ 开启方式（管理员权限运行CMD或PowerShell）
bcdedit /set testsigning on执行后重启电脑，你会看到桌面右下角多了个“测试模式”的水印。
此时再尝试安装CH340驱动，即使没有微软认证，也能顺利通过。
⚙️ 补充技巧：如何正确打包一个“可测试签名”的驱动？
光开testsigning还不够，你还得确保驱动包里的.inf和.cat文件匹配。否则系统仍然报错。
推荐做法：
- 使用微软官方工具链生成签名目录：
bash Inf2Cat /driver:"C:\path\to\ch340_driver" /os:10_X64 - 用
SignTool对.cat文件进行测试签名：bash SignTool sign /v /s TESTSIGNING /n "Test Cert" /t http://timestamp.digicert.com xxx.cat
这样生成的驱动包，在testsigning开启状态下就能稳定加载。
⚠️ 注意事项：
- 此模式下所有未签名驱动都可能被加载，存在安全隐患；
- 不建议用于生产环境或对外交付设备；
- 如需关闭，运行：
bcdedit /set testsigning off
方法三：BIOS关掉Secure Boot｜终极解决方案
如果前两种方法都不行，那大概率是因为你机器开启了Secure Boot。
Secure Boot 是UEFI层面的安全机制，它的作用是防止未经授权的操作系统或驱动加载。哪怕你在系统层打开了testsigning，只要 Secure Boot 还开着，测试签名依然无效。
这时候就得深入BIOS动手了。
🔧 BIOS设置流程
- 重启电脑，狂按
Del/F2/F10（不同品牌按键不同），进入UEFI界面 - 找到Boot → Secure Boot选项
- 改为
Disabled - （可选）将启动模式改为 Legacy + UEFI 混合模式（兼容性更好）
- 保存退出，重启
然后再配合前面任一方法（推荐同时执行bcdedit /set testsigning on），基本可以100%解决问题。
✅ 实战案例：
某客户采购了一批工业平板用于现场数据采集，全部预装Win10专业版。部署时发现CH340模块集体失灵。排查后确认是出厂默认开启Secure Boot所致。最终统一刷机流程中加入BIOS配置环节，问题彻底解决。
别忘了清理“历史包袱”：设备管理器缓存也很关键
有时候你会发现，明明换了新驱动，系统还是沿用旧的错误记录。这是因为Windows的即插即用数据库（PnP Database）缓存了之前的失败安装信息。
清理建议：
- 删除设备时勾选“删除此设备的驱动程序软件”
- 使用命令行工具
devcon强制移除残留节点：
devcon remove "*CH340*"清空以下路径中的临时驱动缓存：
C:\Windows\System32\DriverStore\FileRepository
查找包含ch34x、ch341ser的文件夹，备份后删除重启后再重新插拔设备
给工程师的实战建议：别总想着“绕过去”，更要学会“防得住”
虽然上述方法都能解决问题，但从工程化角度出发，我们更应该思考如何避免这类问题反复出现。
| 场景 | 推荐方案 |
|---|---|
| 个人学习 / 调试 | 方法一（临时禁用）足矣 |
| 团队开发 / 多人协作 | 统一开启testsigning，制作标准化镜像 |
| 批量部署 / 客户交付 | 替换为CP2102、FT232RL等WHQL认证芯片 |
| 自主产品设计 | 申请EV代码签名证书，自行签署驱动 |
特别是对于即将量产的产品，强烈建议：
- 优先选用已通过WHQL认证的USB转串方案（如Silicon Labs CP2102N、FTDI FT232R）
- 或者投入资源完成自有驱动的数字签名，提升产品专业度和兼容性
毕竟，“每次都要教客户进BIOS关Secure Boot”，听起来就不像是正规军干的事。
附：一份干净可用的CH340驱动结构模板
为了方便快速部署，建议准备一个标准化驱动包，结构如下：
CH340_Driver_Pack/ ├── CH341SER.INF ← 安装描述文件（支持x64/x86） ├── CH341SER.SYS ← 核心驱动（注意版本匹配） ├── CH34X.cat ← 数字签名目录（必须与INF哈希一致） ├── DPInst.exe ← 微软官方静默安装工具（支持自动识别架构） ├── readme.txt ← 包含安装说明和常见问题 └── install.bat ← 可选的一键安装脚本其中DPInst.exe来自微软WDK，支持无人值守安装，非常适合集成到产线烧录流程中。
写在最后：技术的本质是平衡
CH340之所以流行，靠的是极致的成本控制；而Windows的驱动签名机制，则是为了守护系统的底线安全。两者本无对错，只是站在了不同的立场。
作为开发者，我们要做的不是抱怨“为什么不能即插即用”，而是理解背后的机制，在安全性、稳定性、便捷性之间找到最佳平衡点。
掌握驱动签名绕过技能，不只是为了修好一个串口线，更是为了建立起一套应对复杂软硬件协同问题的思维方式。
下次当你再看到“usb-serial controller找不到驱动程序”时，希望你能微微一笑：
“哦，它不是找不到，是不愿意收。”
“现在，我知道怎么说服它了。”
