bind mount 仅做路径映射，不处理设备 uuid；需先在宿主机用 uuid 稳定挂载磁盘至固定路径（如 /mnt/data-disk），再通过 -v /mnt/data-disk:/data 将其绑定进容器，确保容器内可安全访问且不受设备名漂移影响。
bind mount 本身不处理设备 uuid，它只做路径级映射——挂载的是宿主机上已挂载好的文件系统路径，而非原始块设备。因此，“在 bind mount 中透传设备 uuid”这个说法存在概念混淆。真正需要的是：让容器内能**感知或访问到某块磁盘的 uuid**，同时保持对该磁盘数据的精准控制（如只读、绑定特定分区、避免设备名漂移）。这需分两步实现：宿主机侧用 uuid 可靠挂载磁盘，容器侧通过 bind mount 暴露该挂载点。
先在宿主机用 UUID 稳定挂载磁盘
设备名（如 /dev/sdb1）在重启或热插拔后可能变化，但每个文件系统的 UUID 是唯一的、不变的。必须先用 UUID 把磁盘挂载到一个固定路径，Bind Mount 才有稳定目标。
- 查 UUID：
sudo blkid或ls -l /dev/disk/by-uuid/，找到目标分区对应 UUID，例如12345678-1234-5678-1234-567812345678 - 创建挂载点：
sudo mkdir -p /mnt/data-disk - 临时挂载验证：
sudo mount UUID=12345678-1234-5678-1234-567812345678 /mnt/data-disk - 写入
/etc/fstab实现开机自动挂载：UUID=12345678-1234-5678-1234-567812345678 /mnt/data-disk ext4 defaults,noatime 0 2
再用 Bind Mount 将 UUID 挂载点暴露给容器
此时 /mnt/data-disk 是一个由 UUID 确保稳定的目录。你可以安全地把它 Bind Mount 进容器，容器内看到的就是该磁盘上的真实文件系统，且不受设备名变动影响。
- 基础挂载（读写）：
docker run -v /mnt/data-disk:/data alpine ls /data - 显式只读（推荐用于配置或只读数据）：
docker run -v /mnt/data-disk:/data:ro alpine cat /data/config.json - 在 docker-compose.yml 中声明：
volumes:<br> - /mnt/data-disk:/data:ro
容器内如何获取并校验 UUID
容器启动后，若需程序主动识别底层磁盘身份（比如做健康检查或日志标记），可从挂载点反查 UUID：
- 确保容器镜像包含
util-linux（含findmnt）或blkid工具 - 执行：
findmnt -n -o SOURCE /data | xargs blkid -s UUID -o value
或更直接：findmnt -n -o UUID /data - 结果即为宿主机上该文件系统的原始 UUID，与
/etc/fstab中一致
为什么不直接挂载 /dev/disk/by-uuid/...？
有人尝试 -v /dev/disk/by-uuid/123...:/mnt/disk，这是错误的。该路径是符号链接，指向 /dev/sdb1 这类块设备节点；而 Bind Mount 不支持将块设备节点“当作文件系统”挂进容器——容器内无法直接 mount 它（缺少权限和内核模块），也无法绕过宿主机的挂载层直接读写裸设备（除非用特权模式+自定义逻辑，极不推荐）。唯一安全、标准的做法，是让宿主机先完成文件系统挂载，再把挂载点路径交给容器。
