go list -f "{{.dir}}" 返回的是go认定的有效源码根路径，仅包含含.go文件的目录，忽略.git等隐藏目录；模块缓存中唯二被主动读取的隐藏文件是.mod和.sum，其余隐藏文件不影响构建。
go list -f "{{.Dir}}" 能看到包目录，但隐藏文件不在其中
Go 工具链默认不把 .git、.github、.vscode 这类隐藏目录当作“包内容”处理，go list -f "{{.Dir}}" 返回的是 Go 认为有效的源码根路径（比如 /home/user/go/pkg/mod/github.com/sirupsen/logrus@v1.9.3），但它只保证该路径下有 *.go 文件，不保证列出所有子目录——尤其是以 . 开头的。你用 ls -a 手动进去看，大概率会发现这些隐藏文件确实存在，只是 Go 不索引、不编译、也不在依赖图里体现。
真正影响构建的隐藏文件只有 .mod 和 .sum
模块缓存中唯一被 Go 主动读取并校验的隐藏文件是：.mod 和 .sum（位于 $GOMODCACHE/xxx@v1.2.3/ 下）。它们分别对应 go.mod 的副本和 go.sum 校验行。其他隐藏文件（如 .git/config）仅在 go mod download 阶段由 Git 命令临时使用，构建完成后即无作用。
-
go mod download -json会输出每个模块的Dir字段，你可以拿它去ls -a <dir></dir>查看真实文件树 -
go list -m -json不含隐藏文件信息，它只返回模块元数据（Path、Version、Replace等） - 如果你怀疑某隐藏文件被意外打包进二进制（比如
.env被 embed 进去了），那问题不在模块依赖层，而在你自己的//go:embed声明或构建脚本里
想确认某个隐藏文件是否被 embed 或 runtime 读取
Go 没有“模块级隐藏文件扫描”机制，但你可以分场景验证：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 如果是
//go:embed .github/workflows/*这种写法：会报错pattern matches no files，因为 embed 明确跳过以.开头的路径 - 如果用
os.ReadDir或filepath.WalkDir遍历embed.FS：它**不会返回**以.开头的条目，这是 fs 包的硬性过滤行为 - 若想强制包含，必须在构建前用脚本把
.xxx重命名为dot-xxx，再 embed —— 但这属于 hack，且违背 Go 对隐藏文件的约定
最省事的核对方式：直接查 $GOMODCACHE
运行 go env GOMODCACHE 得到路径，然后挑一个你关心的模块（比如 github.com/gorilla/mux），执行：
cd $(go env GOMODCACHE)/github.com/gorilla/mux@v1.8.6 ls -a | grep '^\.'
你会发现：.git 通常存在（go mod download 用 git clone 拉下来的完整仓库），但 .github、.editorconfig 等只在原始仓库根目录才有，而 Go 缓存里只保留了 go list 能识别的包路径下的内容（即至少含一个 *.go 的子目录）。换句话说：Go 不会为了一个隐藏文件，把整个仓库根目录都拖进 $GOMODCACHE。
真正容易被忽略的是：有些私有仓库的 CI 脚本会在 go build 前自动注入 .env 或 .secrets 到构建环境变量，这跟模块依赖完全无关，但看起来像“隐藏文件生效了”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
