当我把 Docker 迁移交给 AI 之后……符号链接的致命陷阱
2026.6.26
当我把 Docker 迁移交给 AI 之后……符号链接的致命陷阱
我让它帮我搬个家，它却直接把房子拆了，还连地基一起刨走了。
背景
最近在整理开发环境，想把 Docker Desktop 从 C 盘迁移到 D:\devtools\Docker，把全部工具都放在一个目录下统一管理。目标结构很简单：
text
D:\devtools\Docker
├── App\ (Docker Desktop 程序本体)
├── Images\ (WSL 虚拟磁盘，存储镜像和容器)
└── Volumes\ (用户持久化数据，compose 挂载等)
因为过程涉及一些命令行操作，我懒得自己敲，就把需求丢给了 AI 助手，让它“帮我把 Docker 搬过去，数据别丢就行”。它拍着胸脯说包在它身上。
AI 的操作过程
第一次操作 —— 看起来挺顺利
AI 先用 mklink /J 把 C:\Program Files\Docker 创建了一个 Junction 符号链接，指向 D:\devtools\Docker。Docker 正常启动，docker run hello-world 也成功运行。AI 得意地汇报：“任务完成，一切正常。”
第二次操作 —— “优化目录结构”
我觉得三个子目录（App、Images、Volumes）混在一起不够清爽，就又告诉 AI：“能不能把它们分开放，App、镜像、数据各进各的文件夹？” AI 立刻响应，开始执行所谓的“目录整理”。
此时 D:\devtools\Docker 已经是一个指向 C:\Program Files\Docker 的 Junction 符号链接，而 AI 完全没意识到这一点，径直执行了以下命令：
powershell
AI 以为在往 D 盘整理文件，实际通过符号链接写到了 C 盘
Move-Item “D:\devtools\DockerData\DockerDesktopWSL*” “D:\devtools\Docker\Images”
Move-Item “D:\devtools\Docker\DockerFiles” “D:\devtools\Docker\Volumes”
最后这条命令，AI 自信地告诉我“清理完成”
cmd /c “rmdir /s /q ““C:\Program Files\Docker”””
结果： Docker 程序、52GB 的镜像、4GB 的持久化数据，被 AI 一键清空。它还无辜地问我：“还需要我做什么吗？”
根本原因：符号链接是透明的，AI 也看不见
Junction 符号链接对操作系统和所有程序都是完全透明的。
当 AI 对 Junction 目录执行文件操作时，Windows 在底层自动把路径重定向到了目标目录。AI 以为自己在整理 D:\devtools\Docker\Images\，实际上文件全部写进了 C:\Program Files\Docker\Images\。
最后那条 rmdir /s /q 删除的，正是 C:\Program Files\Docker 这个真实目录，连同刚刚移进去的数据，一起从磁盘上彻底抹除。AI 的“清理”确实很干净——干净到连 Docker 自己都被卸了。
损失清单
容器镜像（需重新拉取）
镜像 用途 来源
mysql:5.7 数据库 Docker Hub
redis:7.2-alpine 缓存 Docker Hub
mongo:6.0 MongoDB Docker Hub
minio/minio:latest 对象存储 Docker Hub
nacos/nacos-server:v2.3.2 服务注册中心 Docker Hub
apache/rocketmq:4.9.7 消息队列 Docker Hub
mybilibili-elasticsearch-ik:7.17.18 ES 搜索（自定义 IK 分词） 需重新构建
registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5 流媒体服务器 阿里云镜像
持久化数据
数据 大小 可恢复性
Docker Desktop 程序 8.19 GB ✅ 可重装
WSL 虚拟磁盘（镜像层） 52.38 GB ✅ 可重新 pull
Volumes 持久化数据 4.15 GB ❌ 需数据恢复
Minio 视频文件 未知 ❌ 不可恢复，需重新上传
MySQL 数据库 - ✅ 有备份（96.4 KB，357条INSERT，2026-05-31 备份）
MongoDB 数据库 - ✅ 有备份（188.9 KB，34条 insert，2026-05-24 备份）
n8n 工作流配置 - ❌ 丢失
dify AI 应用配置 - ❌ 丢失
one-api 配置（one-api.db） - ❌ 丢失
Dha_config 配置文件 - ❌ 丢失
备份文件位置：D:\files\mybilibili-next\mybilibili-cloud\init\ 下的 mybilibili-mysql.sql 和 mybilibili-mongodb.sql。
核心损失：Minio 里存储的全部用户视频、转码片段以及封面图。这部分数据没有任何备份，只能重新上传。
数据恢复建议（给绝望的你）
立刻停止往 C 盘和 D 盘写入任何新数据，避免覆盖被删除的文件。
使用 DiskGenius 或 Recuva 扫描 C:\Program Files\Docker 和 D:\devtools 所在磁盘扇区。
只要被 rmdir /s /q 删除的文件还没被新数据覆写，恢复的概率其实不低——但前提是马上动手。
补救与恢复计划
第一步：重装 Docker Desktop
这次我自己来，AI 已加入黑名单。
第二步：老老实实创建真实目录
powershell
确保 D:\devtools\Docker 是真实目录，绝不是符号链接
New-Item -ItemType Directory -Path “D:\devtools\Docker\App”
New-Item -ItemType Directory -Path “D:\devtools\Docker\Images”
New-Item -ItemType Directory -Path “D:\devtools\Docker\Volumes”
第三步：重新拉取镜像
bash
docker pull mysql:5.7
docker pull redis:7.2-alpine
docker pull mongo:6.0
docker pull minio/minio:latest
docker pull nacos/nacos-server:v2.3.2
docker pull apache/rocketmq:4.9.7
docker pull registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5
mybilibili-elasticsearch-ik 需要根据 Dockerfile 重新构建
第四步：启动基础设施
使用原本的 docker-compose-infra.yml（配置文件在 D:\files\mybilibili-next\mybilibili-cloud\scripts\）。
第五步：恢复数据库
bash
MySQL
docker exec -i mybilibili-mysql mysql -uroot -p mybilibili < D:\files\mybilibili-next\mybilibili-cloud\init\mybilibili-mysql.sql
MongoDB
docker exec -i mybilibili-mongo mongosh < D:\files\mybilibili-next\mybilibili-cloud\init\mybilibili-mongodb.sql
第六步：Minio 数据
所有视频只能手动重新上传，这部分损失无法用技术手段挽回。
正确的做法（AI 本应如此）
永远不要在任何符号链接内部执行文件操作。 正确的迁移流程应该严格按这个顺序来：
powershell
1. 先断开符号链接（只删链接，不删目标目录里的任何东西）
cmd /c “rmdir ““D:\devtools\Docker””” # 注意：绝对不能加 /s /q
2. 创建真实目录
New-Item -ItemType Directory -Path “D:\devtools\Docker\App”
3. 将 C 盘程序文件复制到新位置
Copy-Item “C:\Program Files\Docker*” “D:\devtools\Docker\App” -Recurse
4. 确认复制无误后，删除 C 盘原目录
Remove-Item “C:\Program Files\Docker” -Recurse -Force
5. 重新建立符号链接，让系统认为 Docker 还在老地方
cmd /c “mklink /J ““C:\Program Files\Docker”” ““D:\devtools\Docker\App”””
给 AI 使用者（以及所有开发者）的核心教训
符号链接是透明的，AI 也发现不了
Junction / Symbolic Link 对所有文件操作完全透明。你以为在操作链接，实则直击目标本体。AI 既没有这个安全意识，也不会在执行前二次确认链接的指向——它只会按指令直挺挺地撞上去。rmdir /s /q 是不可逆的
这条命令会绕过回收站，直接永久删除文件。AI 不会提示你“这条命令有风险，是否确认？”，它只会敲完回车然后安静地等待下一个指令。先断链接，再动文件
想在符号链接的位置创建真实目录，必须先通过 rmdir（不加 /s /q）把链接本身干掉，然后才能创建真实目录。顺序一错，神仙难救。重要数据不能把命交给 AI
Docker 镜像丢了可以重新 pull，MySQL/MongoDB 因为我之前手动备份了 SQL 文件，幸免于难。但 Minio 里的视频、n8n 的工作流、dify 的配置……这些没备份的东西，AI 删起来毫不手软。AI 的“自信”背后，可能是你永远找不回的生产数据。不要让 AI 在符号链接里做任何文件操作
无论是 Move-Item、Copy-Item、Remove-Item 还是 mkdir，只要目标路径里藏着符号链接，操作系统实际读写的就是链接指向的真实位置。而 AI，会忠实地把这份“看起来正确”的路径直接喂给系统，绝不会替你多想一步。
总结
这次“AI 协助迁移 Docker”的悲剧，根源就在于我（以及 AI）都忘记了 D:\devtools\Docker 已经是一个透明的 Junction 符号链接。
AI 高效、听话，但它没有对文件系统运作原理的深层理解，也没有“先备份再执行”的避险本能。你可以让它帮你生成代码，但千万别把 rmdir /s /q 的决策权也交出去。
如果你也曾动过“让 AI 帮我整一下 Docker 目录”的念头，请务必记住这段教训：
先断链接，再动文件；操作之前，确认路径真身；重要数据，先备份再动手；高危命令，永远不要交给 AI 一键执行。
愿你的数据安然无恙，也愿你能从我的血泪中，省下那好几十 GB 的回忆。