docker不会自动清理bind mount挂载目录，需人工介入实现优雅清理：启动时约定策略、进程退出前主动清理、宿主机侧定时触发清理，并优先使用named volume替代。
宿主机挂载（bind mount）本身不触发自动清理，docker 不会在容器停止或删除时自动处理挂载目录。所谓“优雅的自动清理”，关键在于**明确责任归属 + 主动控制时机 + 避免误删**，而不是依赖 docker 自动执行。
挂载资源不由 Docker 管理，必须人工介入
与 named volume 不同，bind mount 是将宿主机任意路径（如 /data/myapp）直接映射进容器。Docker 仅建立挂载关系，不跟踪该目录生命周期，也不感知其内容是否仍被需要。因此：
- 容器
stop或rm后，挂载目录原封不动，文件、权限、子目录全部保留 - 没有
--volumes这类开关能一并清理 bind mount - 误删宿主机目录可能导致其他服务中断，风险远高于 volume
实现“优雅清理”的三步落地法
不是等容器删完再扫目录，而是把清理逻辑嵌入到容器退出前或销毁后可预测的时间点：
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
-
启动时约定清理策略：在
docker run中用--tmpfs替代临时性 bind mount；对必须用 bind mount 的场景，在启动脚本中写明“该目录仅供本次运行，退出后可清空” -
容器内主进程退出前主动清理：在应用代码或 entrypoint 脚本中监听
SIGTERM，执行rm -rf /mounted/path/*（注意保留目录结构本身，避免影响宿主机权限） -
宿主机侧配合定时/触发式清理：用 systemd timer、cron 或 CI/CD 流水线脚本，在确认容器已
Exited后，按命名规则清理对应挂载路径，例如：find /host/mounts -maxdepth 1 -name "myapp-*" -mtime +1 -exec rm -rf {} \;
推荐替代方案：优先用 volume + 显式 prune
若挂载目的仅为数据持久化，强烈建议改用 named volume：
- 启动时：
docker run -v myapp-data:/app/data nginx - 清理时：
docker volume rm myapp-data或docker volume prune -f - volume 支持
docker volume inspect查看挂载点、驱动、使用状态，比手动管理路径更安全可控
特别注意清理边界和权限问题
无论用哪种方式，都需确认以下三点再执行删除：
- 该挂载路径是否被多个容器共用？—— 共享目录不能随单个容器销毁而清理
- 宿主机目录属主是否为 root？—— 容器内进程可能无权删除，需在宿主机用对应用户执行
- 目录下是否有正在被其他进程打开的文件？——
lsof +D /path可检测，避免“设备忙”错误
