根本原因是git lfs install仅配置本地钩子，未将已跟踪的大文件重写进LFS轨道，需先git lfs track指定文件类型，再git rm --cached后重新add以转换为LFS指针。
Git LFS初始化后push还是卡在大文件上
根本原因是 git lfs install 只配置本地钩子，但没把已存在的大文件“重写”进LFS轨道。Git仍按普通文件跟踪，push时自然走完整内容传输。
必须手动把目标文件纳入LFS规则并重新提交历史：
- 先运行
git lfs track "*.psd"（或具体路径如git lfs track "assets/large.zip"），这会更新.gitattributes - 执行
git add .gitattributes，否则规则不生效 - 关键一步：用
git rm --cached <file>把已跟踪的大文件从暂存区移出（不删工作区），再git add <file>—— 这次Git会按LFS规则把它转成指针 - 如果文件早已提交多轮，需用
git lfs migrate import --include="*.zip"重写历史（注意：协作仓库需全员强制同步）
pull下来的是文本指针而不是真实文件
这是LFS的正常行为，但说明客户端没装或没启用LFS过滤器。不是服务器问题，也不是文件损坏。
检查和修复步骤：
- 确认本机已安装LFS：
git lfs version，没输出就先装（macOS用brew install git-lfs，Windows下官网下载msi） - 运行
git lfs install（不是 init，也不是 clone 后自动触发）—— 它会在.git/hooks/放 pre-push/post-checkout 等钩子 - 如果之前 clone 没带 LFS 支持，直接
git lfs pull即可批量下载真实内容；也可单个文件用git lfs checkout <file> - 注意：某些CI环境或旧版Git（-c filter.lfs.smudge=true
Git LFS上传失败报错"batch request failed: 401 Unauthorized"
这不是权限配置错了，而是凭证过期或未传递给LFS服务端。Git本身能推，但LFS走独立HTTP接口，用的是另一套认证流。
常见原因和解法：
- GitHub/GitLab 的 personal access token 必须带
read:packages和write:packages权限（GitHub）或api（GitLab），密码或SSH密钥不管用 - 运行
git lfs install --force强制重置凭证存储，再用git credential reject清掉旧凭据（host=github.com, protocol=https） - 检查
git config --get-regexp 'lfs.*url'，确保LFS endpoint地址正确（例如GitHub是https://github.com/<user>/<repo>.git/info/lfs，不是原始git URL） - 企业自建Git服务器需确认
git-lfs-authenticate钩子是否部署并返回有效JWT
用 git clone 拉项目时跳过LFS文件下载
想快速检出代码结构、不等几百MB资源下载完？可以关smudge，但得清楚后果：所有LFS文件都会变成指针文本，无法直接用。
两种可控方式：
- 克隆时加参数：
git clone -c filter.lfs.smudge=false <url>，之后需要某文件再单独git lfs pull --include="path/to/file.bin" - 全局禁用（慎用）：
git config --global filter.lfs.smudge false，适合只读CI任务，但开发者机器上容易误以为文件缺失 - 注意：即使关了smudge，
git status仍显示clean，因为指针文件本身是Git管理的；真要验证是否下载了，看文件大小或file <file>输出
LFS最易被忽略的点是：它不改变Git对象模型，只是把blob替换成指针+服务端托管。所以所有操作都依赖钩子、凭证、网络三者同时在线——断一个，就卡在“看起来正常，实际不能用”的状态。
