如果没执行 git lfs install 就直接 git clone 包含 Git LFS 追踪文件 的仓库，会出现 “大文件下载不完整” 的问题，具体表现和原因如下：

一、核心现象：下载的是“占位符”，而非真实大文件

Git LFS 的核心原理是：仓库中存储的不是大文件本身，而是一个“文本占位符”（指针文件，通常以 .gitattributes 配置追踪），真实大文件存储在 Git LFS 服务器上。

如果没初始化 Git LFS（git lfs install 的作用），git clone 只会：

1. 下载仓库的普通文件（代码、配置等）；
2. 下载大文件对应的 占位符（而非真实大文件），占位符内容类似：

   version https://git-lfs.com/spec/v1
   oid sha256:abc1234567890...（大文件的哈希值）
   size 10485760（大文件大小，如10MB）
   

3. 打开这些“大文件”时会发现是文本内容（占位符），而非原本的音频、视频、压缩包等真实文件。

二、不同场景的差异

1. 仓库本身不包含 Git LFS 追踪文件

如果克隆的仓库没有用 Git LFS 管理任何大文件（即没有 .gitattributes 配置 LFS 追踪规则），那么 git clone 完全正常，和是否执行 git lfs install 无关，能完整下载所有文件。

2. 仓库包含 Git LFS 追踪文件

此时 git clone 会“看似成功”，但真实大文件未下载，后续操作可能出现：

• 打开大文件失败（占位符无法解析）；
• 编译/运行项目时缺少依赖文件（如大模型权重、测试数据集）；
• 执行 git pull/git checkout 切换分支时，大文件依然是占位符，不会自动下载。

三、补救措施：克隆后补全大文件

如果已经克隆完成，无需重新克隆，执行以下步骤即可下载真实大文件：

1. 先安装并初始化 Git LFS（参考之前的 Ubuntu 安装步骤）；
2. 进入克隆后的仓库目录，执行：

   git lfs pull
   

   该命令会识别占位符中的哈希值，从 Git LFS 服务器下载对应的真实大文件，替换掉占位符。

四、总结

关键提醒

git lfs install 的作用是 在本地配置 Git LFS 钩子（hook），让 Git 命令（clone/pull/checkout）自动识别 LFS 占位符并下载真实文件。如果没执行，Git 就不知道如何处理占位符，只会当作普通文本文件下载。