宿主机识别 USB 串口而应用看不到，需要分层核对设备访问。
枚举与驱动先产生节点，容器映射和用户权限再决定访问。重插可能改变节点，业务协议还需另查。
一、问题的范围与前提
镜像、容器、网络和数据卷是不同对象。镜像定义运行产物，容器执行进程，网络决定可达关系，卷管理跨容器生命周期的数据。把它们分别列出来，有助于判断重建究竟改变了什么；单个容器显示 Up，只能说明相关入口进程仍然存在。
二、技术分析与方案取舍
从 lsusb 到设备节点，再到容器内打开串口，是三道不同的检查。USB 枚举成功但没有 tty 节点，先查看内核驱动绑定；节点存在但 Permission denied，检查运行用户与设备组；能打开却无回包，再检查协议参数。
映射 /dev/ttyUSB0 只是把某个节点交给容器，重新插拔后编号变化可能使它指向另一设备。稳定链接有助于表达身份，但具体运行时对符号链接和热插拔的行为仍需验证。仅执行 restart 不会重读新的 devices 创建参数。
调整映射后核对容器实际配置，并确保没有另一个进程同时占用总线。调试日志保留错误类型和帧结构，不发布设备序列号或现场原始报文。
先固定基础镜像、应用版本和必要配置，再检查最终容器的实际参数。Compose 文件只是期望描述，已经创建的容器可能仍带旧环境。涉及端口、设备和挂载等创建参数时，需要按差异重建；普通 restart 不会重新读入全部创建配置。重建前确认数据所在位置和现有卷身份。
三、实现与排查的顺序
- 确认宿主机节点。
- 核对 devices。
- 检查运行权限。
- 重建并连续读测试。
按这个顺序保留中间结果，可以区分输入条件、处理过程和最终输出。前一阶段的条件不成立时，先解释对应错误，再继续后面的试验；单次返回成功不足以覆盖整条链路。
最小示例
1
2
3
lsusb
ls -l /dev/ttyUSB* /dev/ttyACM* 2>/dev/null
journalctl -k --since "10 minutes ago"
先确认 USB 枚举和设备节点，再检查权限与协议回包。设备名称以主机实际识别为准，公开日志去除设备序列号、MAC 和个人路径。这里不发送设备控制指令。
四、验证和结果解释
可以将配置解析结果、容器实际状态和一次业务请求放在一起观察。配置有效说明语法和部分引用成立，镜像构建有效说明产物生成，真实请求才进一步说明依赖链可用。将这些结果分开记录，能避免一个阶段的成功遮住另一个阶段的失败。
| 需要验证的结果 | 保留的对照 | 不能由此推出的结论 |
|---|---|---|
| 无需全局特权掩盖 | 固定输入与配置、对应输出 | 一次成功代表所有条件成功 |
| 重插身份正确 | 中断前后状态与错误阶段 | 没有报错代表结果正确 |
| 回包可解释 | 恢复后的同条件复测 | 临时恢复代表根因已经消失 |
容器异常不一定需要重建整套服务。先定位受影响对象，再确认是否有状态需要保留。数据卷独立于容器并不等于有独立备份，健康检查也不等于自动重启。恢复策略需要与退出、网络失联、数据损坏等具体条件对应。
五、适用边界与结论
界面刷新不会更改容器创建参数，节点可见不代表协议已通过。
这条路径把“确认宿主机节点”与“重建并连续读测试”连在一起，中间保留可复查的条件。实施时优先确认“无需全局特权掩盖”，再检查“回包可解释”；两者都满足，才能在当前样本与配置范围内评价方案。设备、数据或软件版本改变以后，相关假设需要重新验证。
