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