git lfs规则需精准匹配，避免误跟踪小文件；每条规则须加-text参数防止文本diff；并发数可调至4–12提升上传效率；历史大文件需用git lfs migrate重写；.gitattributes必须提交生效。
git lfs track 规则写得太宽泛，会导致小文件也被误追踪
常见错误是直接 git lfs track "*" 或 git lfs track "**/*"，结果所有文件（包括几KB的配置、日志、脚本）都变成LFS指针。Git LFS不是“越大越好”，而是“该管才管”——小文件走原生Git反而更快更可靠。
实操建议：
- 按扩展名精准匹配，例如只跟踪
*.bin、*.h5、*.pth这类真正体积大且不可 diff 的二进制资源 - 对目录批量管理时加扩展名限制，比如
models/**/*.{bin,pt,ckpt}，避免models/**/*把models/README.md也拖进去 - 用
git check-attr -a <file></file>验证某文件是否真被 LFS 规则命中，防止规则失效或覆盖冲突
.gitattributes 中漏写 -text 参数，导致 Git 对二进制文件做文本 diff
默认情况下，Git 会尝试把所有文件当文本处理：计算行数、找换行符、做差异高亮。对 .zip 或 .psd 这类二进制文件，这不仅毫无意义，还会显著拖慢 git status、git diff 甚至 git add。
实操建议：
- 每条
git lfs track规则后必须显式加上-text，例如：*.zip filter=lfs diff=lfs merge=lfs -text - 不要依赖全局设置——
-text是 per-pattern 属性，只作用于当前匹配项 - 已有误配的仓库，可手动编辑
.gitattributes补上-text，再运行git add --renormalize .刷新工作区
并发上传卡在 1–2 个连接，实际带宽没跑满
Git LFS 默认只开 3 个并发连接（lfs.concurrenttransfers=3），在千兆局域网或高速云服务器上，这相当于只用了不到 10% 的带宽，上传 2GB 模型可能要等十几分钟。
实操建议：
- 根据网络环境调高并发数：
git config lfs.concurrenttransfers 8（4–12 之间较稳妥） - 如果远程 LFS 服务有速率限制（如 GitHub Enterprise 或私有 GitBucket），需同步确认服务端最大连接数，避免客户端设太高反被拒绝
- 配合
git config lfs.http.timeout 300和git config lfs.http.retries 5，防止因瞬时抖动中断重传
已有大文件的历史提交没清理，克隆仍很慢
执行 git lfs track 只影响后续提交。如果项目已存在几十次含 500MB .fbx 文件的 commit，新用户 git clone 时依然得下载全部历史版本的指针+内容（除非你提前做了迁移）。
实操建议：
- 用
git lfs migrate import --include="*.fbx,*.psd" --everything重写历史，把已有大文件转为 LFS 管理（注意：这是破坏性操作，需团队同步停 push） - 迁移前先
git lfs migrate info --everything预览哪些文件会被处理，避免误伤 - 迁移后必须
git push --force --all和git push --force --tags，旧克隆仓库需重新git clone才能受益
最易被忽略的一点：LFS 规则生效依赖于 .gitattributes 被提交并推送到远端。很多人改完规则忘了 git add .gitattributes，或者提交了但没 push，结果同事拉下来还是原样——指针没生成，大文件照常塞进 Git 对象库。
