其实Git LFS官方并没有给出一个严格的字节数阈值来定义“大文件”——这更多是一个基于Git原生工作机制的相对概念，得结合Git的特性来理解：

• Git原生是为文本文件（比如代码）设计的，它通过存储文件的差异（delta）来节省空间。但对于二进制大文件（比如音频、视频、高清图片、安装包），每次修改几乎都会产生全新的文件内容，Git存储这些差异的效率极低，会让仓库体积飞速膨胀，拖慢克隆、提交、拉取等操作。
• 所以在实际使用中，只要某个文件会导致Git仓库体积异常增大、或者拖慢Git操作效率，就可以被视为Git LFS适用的「大文件」。常见的例子就是你提到的音频样本、视频、几GB的数据集、大型设计文件等。

另外，虽然没有官方阈值，但很多团队会自己制定规则，比如：

• 单个文件大小超过100MB就用LFS管理
• 或者只要是二进制文件（不管大小）都统一用LFS

简单说，Git LFS的核心是解决Git处理高体积、高修改成本的文件的痛点，“大”是相对于Git的高效处理能力而言的，而非绝对的字节数。

内容的提问来源于stack exchange，提问作者Thunderforge