Go中无法直接调用overlay驱动，需通过exec.Command调用mount命令或使用containerd/continuity/fs实现用户态合并，且必须配合mount namespace隔离。
overlay驱动在Go中无法直接调用，得靠exec.Command启动mount
Go标准库不提供对Linux overlay文件系统的原生封装，syscall.Mount 虽能触发挂载，但必须手动拼接所有参数且极易出错。实际项目里，几乎没人手写syscall调用——参数顺序、flag组合（如MS_MGC_VAL）、data字符串格式（"lowerdir=...,upperdir=...,workdir=..."）稍有偏差就会返回invalid argument或operation not permitted。
更稳妥的做法是复用系统mount命令：
- 确保运行时进程具有
CAP_SYS_ADMIN能力（容器内需加--cap-add=SYS_ADMIN） -
upperdir和workdir必须位于同一文件系统（否则报Invalid argument） - 路径必须已存在且权限正确（
upperdir需可写，workdir下必须有work子目录）
cmd := exec.Command("mount", "-t", "overlay", "overlay",
"-o", "lowerdir=/lower,upperdir=/upper,workdir=/work", "/merged")
err := cmd.Run()
用github.com/containerd/continuity/fs实现安全的overlay层合并
如果目标不是挂载而是模拟overlay语义（比如构建镜像、打包只读层+可写层），github.com/containerd/continuity/fs 提供了Merge函数，它按overlay规则递归合并lower（只读）和upper（可写）目录到目标路径，自动处理whiteout、opaque目录等细节。
注意它不依赖内核overlay驱动，纯用户态实现，适合非特权环境：
立即学习“go语言免费学习笔记（深入）”；
- 不支持硬链接跨层传播（
hardlink行为与内核overlay略有差异） - 不会自动创建
work目录结构，upper需预先准备好work/work子目录 - 合并过程无原子性保证，失败时可能留下中间状态
import "github.com/containerd/continuity/fs"
err := fs.Merge("/merged", []string{"/lower"}, "/upper")
dockerd和runc底层怎么用overlay？关键在storage driver配置
Go生态中真正稳定使用overlay的组件，是containerd和runc——它们通过graphdriver插件机制调用overlay或overlay2。你不需要自己实现，但得理解配置项如何影响行为：
-
/var/lib/docker/overlay2是默认root路径，overlay2比overlay多一层diff目录，兼容性更好 - 启用
overlay2需内核≥4.0，且/proc/sys/fs/xfs/speculative_prealloc不能为1（某些XFS系统会挂载失败） - Go程序若嵌入
containerd，可通过containerd/client.WithDefaultNamespace+client.NewImage间接利用其overlay存储
别忽略unshare(CLONE_NEWNS)和mount namespace隔离
即使mount成功，若没切换到独立的mount namespace，挂载点会泄漏到宿主机——这是调试时最常被忽略的一环。在Go中需先调用unix.Unshare(unix.CLONE_NEWNS)，再执行mount，否则普通用户权限下也会失败（提示operation not permitted）。
此外：unix.Mount("", "/", "", unix.MS_PRIVATE|unix.MS_REC, "")建议紧随其后，防止挂载传播影响其他进程。
没做namespace隔离的overlay，基本等于没做。
