go.bug.st/serial.v1 是目前最省心的选择：纯 Go 实现、无 CGO 依赖、跨平台开箱即用；需注意系统权限与路径差异、显式设置读超时、正确处理帧边界与终止符、避免并发读写冲突，并严格遵循硬件通信契约。
go.bug.st/serial.v1 是目前最省心的选择：纯 Go 实现、无 CGO 依赖、跨平台开箱即用。你写一套代码，编译后在 Windows、Linux、macOS 上都能直接跑，不用改路径、不重写权限逻辑、也不用为不同系统套条件编译。
串口打不开：Permission denied 或 device not found 怎么查
这不是 Go 代码错了，是系统级路径或权限没对上。
- Linux：先运行
ls /dev/tty*确认真实设备名（比如/dev/ttyUSB0），再确认用户是否在dialout组：sudo usermod -a -G dialout $USER，改完必须重新登录终端 - macOS：只认
/dev/cu.*开头的设备（比如/dev/cu.usbserial-1420），/dev/tty.*很可能被系统后台占着 - Windows：端口名必须全大写且无前缀，
COM3可以，com3或\.COM3在部分库下会失败；go.bug.st/serial内部做了标准化，相对宽容 - 别硬编码端口。用
serial.GetPortsList()先探测可用端口，或让用户通过命令行参数传入
Read() 一直卡住或返回 0 字节
Read() 默认阻塞，不设超时就是等一辈子 —— 尤其在硬件发得慢、帧不完整或线空闲时。
- 必须显式设置读超时：
serial.WithReadTimeout(100 * time.Millisecond) - 每次调用后务必检查
n, err：n == 0 && err == nil是正常空读；err == io.EOF往往是 USB 转串口芯片断连后残留句柄 - 协议带帧头（如
0x7E）或换行符结尾？别用固定长度Read(buf)，改用bufio.NewReader(port).ReadBytes('\n')或自己拼包
Write() 返回成功但设备没响应
Go 层面 “写成功” 只代表数据进了内核缓冲区，不代表硬件真收到了。
立即学习“go语言免费学习笔记（深入）”；
- 确认终止符：很多设备要求命令结尾是
\r\n，你只写了[]byte("AT")，得改成[]byte("AT\r\n") - 查硬件手册：是否要 RTS/CTS 流控？
go.bug.st/serial中用RtsCts: true开启，CH340/CP2102 类芯片通常需关掉 - 连续写多条命令？加
time.Sleep(10 * time.Millisecond)—— 部分低端 USB 转串口芯片无法承受高频写入 - 用串口调试助手抓一包，对比 Go 发出的 hex 和手动发送是否完全一致：少一个
0x0D、多一个0x00都可能失败
goroutine 并发读写串口时 panic 或丢数据
*serial.Port 实例不是线程安全的，共用一个句柄并发读写必出问题。
- 绝对不要在多个 goroutine 里共享同一个
*serial.Port - 高频读写场景：用
sync.Mutex包一层，读写前mu.Lock()，完后mu.Unlock() - 低频场景更简单可靠：每个 goroutine 自己
Open()→ 操作 →Close()，只要注意别频繁开关
真正容易被忽略的是：串口通信不是“发完就完”，而是“发得准、收得全、断得清”。超时、帧边界、流控、终止符、权限、关闭时机——任何一个环节松动，都会让程序在某台机器、某个设备、某次重启后突然失联。写串口工具，本质是写与物理世界的契约，而不是写一段能编译的 Go 代码。
