共享文件夹不能用作 gopath 或项目根目录，因其底层文件系统不支持 inotify、mtime 更新等机制，导致 go build 卡住、go mod tidy 失败、权限异常及缓存失效；gopath 和 gocache 必须设在虚拟机本地磁盘，代码同步推荐 rsync 或 vs code remote-ssh。
虚拟机里跑 Go 项目，用共享文件夹直接编译基本就是自找麻烦——go build 会卡住、go mod tidy 反复失败、fsnotify 触发异常重启，根本不是配置问题，是底层文件系统不支持。
为什么共享文件夹不能当 GOPATH 或项目根目录
VirtualBox Guest Additions 和 VMware Tools 对 inotify 事件监听有严重缺陷：符号链接解析错乱、文件修改时间（mtime）不更新、目录遍历返回空或重复条目。Go 工具链依赖这些机制做增量构建和模块缓存校验。
-
go mod download在共享路径下常卡在 “verifying” 阶段，实际是fsnotify等待一个永远不会到来的事件 -
go build -o ./bin/app生成的二进制可能权限为 000 或缺失执行位，因为 guest tools 无法正确透传 chmod -
go run .第二次执行大概率报cannot find module providing package，因为go.mod时间戳被 host 同步覆盖，触发内部缓存失效
GOPATH 和 GOCACHE 必须落在虚拟机本地磁盘
所有 Go 运行时写入路径都得避开 /mnt/hgfs、/vagrant、/media/sf_* 这类挂载点。哪怕只是临时设为 GOPATH，也会让 go install 编译出的工具无法执行。
-
GOPATH设为$HOME/go（默认值），确保$GOPATH/bin在本地 ext4 分区上 -
GOCACHE显式设为$HOME/.cache/go-build，避免 NFS 或 SMB 挂载导致的锁竞争 - 若必须同步代码，用
rsync -av --delete ~/project/ /mnt/hgfs/project/单向推，而非双向挂载
编译性能差？先关掉 go.work 和 replace 本地路径
虚拟机 CPU 资源有限，go.work 文件会强制启用多模块工作区模式，每次 go build 都要遍历所有 use 目录；而 replace 指向共享路径会让 Go 工具链反复 stat 宿主机文件系统。
- 删掉项目根目录下的
go.work文件，除非真需要同时开发 3 个以上模块 - 检查
go.mod是否含replace example.com/foo => ../foo，替换成真实 commit hash 或 tag - 编译时加
-gcflags="-l"关闭内联，减少单次编译 CPU 占用，对 2 核虚拟机更友好
VS Code Remote-SSH 比共享文件夹靠谱得多
与其折腾 vboxsf 权限和 inotify，不如用 SSH 直连虚拟机——代码存在本地，编辑器走 TCP 转发，go run 和 dlv 全部在虚拟机内执行，完全规避文件系统层问题。
- 在虚拟机开
sudo systemctl enable ssh，确保 SSH 服务开机启动 - VS Code 安装
Remote-SSH插件，用ssh username@vm-ip连接 - 编辑器里打开的路径是
/home/username/project，不是/mnt/hgfs/project
真正卡住的从来不是 Go 版本或代理配置，而是你把宿主机文件系统当成了 Linux 本地磁盘来用。共享文件夹只适合传安装包、拉日志、备份二进制，别让它参与构建流程。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
