合规检查核心在于卷命名规范、使用可追溯、权限匹配及生命周期可控：必须显式声明命名卷（如prod-db-data），禁用匿名卷和不安全绑定挂载；验证UID/GID权限一致性；定期清理悬挂卷并验证备份可恢复性。
合规检查不是走流程，而是防止数据错挂、误删、权限越界这些真实风险。重点不在“有没有卷”，而在“卷怎么命名、谁在用、权限对不对、生命周期是否可控”。
命名是否规范且可追溯
命名混乱是生产事故常见诱因。匿名卷（Docker 自动生成的随机名）无法识别用途，极易在重建服务时挂载错卷，覆盖数据。
- 所有 docker-compose.yml 中的 volumes 字段必须显式声明卷名，禁止仅写
- /path或- ./data:/path这类绑定挂载写法（除非明确用于开发） - 卷名应体现服务+用途+环境，例如：
prod-db-data、staging-redis-cache、app-logs；避免泛化名如data、vol1 - 检查是否存在重复卷名：运行
docker volume ls --format '{{.Name}}'，确认无重名；多项目共用同一卷名时，务必通过docker volume inspect核实挂载路径和实际用途
挂载关系与权限是否安全
卷挂载后，容器内进程以什么 UID/GID 写文件，直接决定主机侧数据能否被其他服务或用户意外读写。
- 检查容器内应用用户是否与卷目录权限匹配：进入容器执行
ls -ld /mounted/path，确认属主 UID/GID 与应用进程一致；若不一致，可在docker run或 compose 中用user: "1001:1001"显式指定 - NFS 或自定义驱动卷需额外验证：检查
docker volume inspect volume-name中的Options字段，确认uid、gid、no_root_squash等关键参数符合最小权限原则 - 禁止将卷挂载到容器内敏感路径（如
/etc、/root），尤其不能用:ro挂载系统配置目录——只读也不安全，可能被容器内漏洞利用绕过
生命周期是否受控
卷不会随容器自动删除，长期积累的未使用卷既占磁盘空间，又增加误操作风险。
- 运行
docker volume ls -f dangling=true查看所有“悬挂卷”（未被任何容器引用），确认它们确实已废弃；非必要不保留 - 对每个命名卷执行
docker volume inspect volume-name，查看Mountpoint路径，并人工核对该路径下是否有活跃业务数据（如 PostgreSQL 的base/目录、Redis 的dump.rdb） - 定期执行
docker volume prune -f清理悬挂卷，建议纳入 CI/CD 部署后脚本或运维巡检清单；但生产环境执行前必须先确认docker ps中无依赖该卷的运行中容器
备份与恢复路径是否验证过
有卷不等于有备份。合规要求的是“可验证恢复”，而非“存在卷”。
- 确认卷所在宿主机路径（
Mountpoint）已纳入备份策略（如 rsync 定时同步、BorgBackup 归档），且备份任务实际成功运行（查日志，非只看 cron 是否触发） - 抽样验证：选取一个非核心卷，手动执行备份 → 删除原卷 → 从备份还原 → 启动容器验证服务可用性
- 对使用
local驱动以外的卷（如 NFS、S3 插件），检查驱动插件是否启用健康检查，以及网络连通性是否持续监控
