根本原因是模块或其依赖将媒体文件直接提交到Git仓库并包含在模块路径内，Go工具链下载时会获取全部文件；有效方案包括发布者移出媒体文件、使用者replace fork、构建时清理缓存，但最务实的是避免媒体进入模块。
Go module 依赖中为什么会出现媒体文件？
根本原因不是 Go 模块本身拉取了媒体文件，而是你 go get 或 go mod tidy 的目标模块（或其间接依赖）把大体积的 .mp4、.zip、.pdf 等非代码资产直接提交到了 Git 仓库，并且这些文件被包含在 go.mod 所声明的模块路径范围内。Go 工具链下载 module 时默认 fetch 整个 tagged commit 或 branch 的全部文件（通过 proxy 或 direct git clone），不区分文件类型。
用 git sparse-checkout 配合 GO111MODULE=off 不可行
有人尝试禁用模块模式、改用 GOPATH + sparse-checkout 手动筛选，这条路走不通：
-
GO111MODULE=off在 Go 1.16+ 已基本废弃，且无法控制go mod download行为 -
git sparse-checkout是工作区优化，不影响go mod download底层调用的git archive或 proxy 的 tarball 构建逻辑 - Go proxy（如 proxy.golang.org）返回的是预打包的
@v/vX.Y.Z.zip，内容由模块作者的 Git 仓库快照决定，客户端无权过滤
真正有效的三个控制点
能起效的操作必须落在模块发布者或使用者的协作边界上，且需提前规划：
-
模块发布者侧：把媒体文件移出模块根目录，放到独立仓库（如
example.com/assets），并在README.md中说明；或使用.gitattributes+export-ignore（仅对通过git archive构建的 zip 有效，但多数 proxy 不依赖此机制） -
模块使用者侧：用
replace指向一个已清理的 fork 分支，例如：replace example.com/real/module => github.com/you/clean-module v1.2.0
，确保该 fork 已git filter-repo删除了大文件并重写历史 -
构建流程侧：在 CI 或本地构建前运行
go mod download，然后用脚本清理$GOPATH/pkg/mod/cache/download/下对应模块的.zip解压后的大文件（路径形如example.com/real/module/@v/v1.2.0.zip→ 解压到unpacked/目录），再tar -c重新打包。注意：这会破坏校验和（go.sum失效），必须配合GOINSECURE和本地 proxy 绕过验证
最务实的建议：别让媒体进模块，也别依赖带媒体的模块
Go 模块语义是「可复现的代码依赖」，不是资源分发通道。一旦发现某个开源模块把 samples/ 目录下的 200MB 视频塞进了 go.mod 路径，优先考虑：
立即学习“go语言免费学习笔记（深入）”；
- 提 Issue 请作者拆分资源仓库
- 用
go:embed+ 单独 HTTP 下载替代（运行时按需获取） - 若必须用，就 fork 后用
git filter-repo --path-glob "*.mp4" --invert-paths彻底删除，再打新 tag
所有“下载时过滤”的技巧都绕不开一个事实：Go 没有类似 npm 的 files 字段或 Maven 的 resources scope。想干净，只能从源头切掉那条路径。
