写在前面
同事把 Docker 的 volume 指向了挂在盘符上的 NAS 目录，第一次构建镜像就卡了十几分钟；后来把镜像层挪回本地盘，构建时间回到了 1 分多钟。
这类问题不是"网络盘慢"这么一句话能解释的。挂载盘上跑开发负载，本质上是在拿一个"带延迟、带锁语义差异、可能断连"的存储，去干一件默认它是一块本地 SSD 的事。
一、镜像层为什么特别怕挂载盘
Docker 写镜像层的时候，习惯是"大量小文件 + 顺序追加"。这两种访问模式恰好是网络盘最不擅长的：
结果是构建过程不是"慢一点"，而是"某个步骤无响应"，因为它在等一个永远不会立刻完成的 fsync。
二、把"读多写少"和"写多读少"分开对待
实践里有效的做法不是全盘搬到本地，而是按访问特征分层：
判断标准很简单：这个目录在一次典型操作里，是被大量顺序读，还是被大量小文件写。前者放挂载盘没负担，后者放挂载盘必翻车。
三、给 Docker 显式关掉那些依赖"真盘"的特性
如果确实需要容器直接读写挂载盘上的目录，有几个开关值得单独确认：
四、怎么判断"这个盘到底靠不靠谱"
不用猜，看三个地方就够：
我们自己做的 ScsDrive（https://drive.scsoi.com）把 NAS / WebDAV 挂成 Windows 盘符时，也是按"带网络延迟的本地盘"这条前提来设计的：批量写入先排队，数据库类应用默认排除，锁冲突先查凭据再查磁盘。它免费、无广告，不像 RaiDrive 那样要付费订阅。
五、给团队的最小约定
如果团队里有人把开发负载放在挂载盘上，建议直接把三条写进规范：
先自查这三件事，通常能省掉一整天的排查。
你们在挂载盘上跑过构建或者数据库吗？踩过哪些坑，欢迎在评论区聊聊
