Git LFS跟踪规则必须显式声明才能生效，未在.gitattributes中配置filter=lfs的文件即使超大也不会被拦截，仍会完整存入Git对象库导致仓库膨胀。
Git LFS 跟踪规则必须显式声明才能生效
Git LFS 不会自动拦截大文件，它只对 .gitattributes 中明确用 filter=lfs 标记的路径起作用。没配置就提交 500MB 的视频文件，git push 依然会把整个文件塞进 Git 对象库——LFS 完全不干预。
常见错误是以为“装了 LFS 就万事大吉”，结果仓库照常膨胀。正确做法是：在项目根目录创建或编辑 .gitattributes，按需添加模式匹配行：
*.{psd,ai,sketch} filter=lfs diff=lfs merge=lfs -text
data/*.zip filter=lfs diff=lfs merge=lfs -text
model.bin filter=lfs diff=lfs merge=lfs -text
注意点：
-
filter=lfs是必需项，缺了就只是普通文本规则 - 通配符优先级高，
*.bin会覆盖更具体的model.bin，建议先写细粒度再写宽泛规则 - 已提交过的文件（哪怕只是暂存过）不会被新规则自动重写，需手动执行
git lfs migrate import --include="*.psd"
服务器端 LFS 权限由远程托管平台控制，非 Git 本身
Git 本身不校验 LFS 文件上传权限；实际限制发生在 LFS 服务器（如 GitHub、GitLab 或自建 git-lfs-server）接收 git lfs push 请求时。这意味着：
- 本地
git add和git commit永远成功，哪怕文件超 2GB - 真正报错出现在
git push阶段，典型错误是：batch request: Unauthorized或LFS: 403 Forbidden - 权限问题往往和 OAuth Token 权限不足、组织成员角色变更、私有 LFS 服务器未启用对应仓库的 LFS 支持有关
验证方式：运行 git lfs env，检查输出中 Endpoint 是否可访问、Git LFS user agent 是否正常，以及 SSH 或 HTTPS 认证是否命中预期账户。
pre-commit 钩子无法替代 LFS 跟踪，但能补漏
即使配置了 LFS，仍可能因疏忽导致大文件误入 Git 原生对象库：比如忘记 git add 前确认后缀、临时绕过 .gitattributes、或使用 --force 提交被忽略的文件。此时客户端钩子仍是最后一道防线。
覆盖A股热点发现、可比公司分析、基金诊断筛选、资金流向分析、多维选股、行情技术分析、股东股本分析及深度技术分析全流程，为投资顾问提供全方位市场分析参考。
关键区别在于目标不同：
- LFS 钩子目标：把大文件转为指针，保留版本历史
- pre-commit 钩子目标：直接拒绝提交，强制人工介入
推荐组合策略：
- 用
.gitattributes主动跟踪已知大文件类型 - 用 husky +
pre-commit脚本拦截未被 LFS 覆盖但超过 10MB 的文件（如漏配的.raw或.mov） - 脚本里别只查
git diff --cached，要加上--diff-filter=ACM排除删除操作，避免误判
LFS 指针文件本身没有额外权限模型
Git LFS 存储的是纯文本指针（含 oid、size、version），它们和普通文本文件一样受 Git 分支/标签权限控制。也就是说：
- 如果某人没有
main分支写权限，他就不能推送包含新 LFS 指针的 commit 到main - 但只要他能 push 到某个分支，对应的 LFS 文件（二进制内容）就会被上传到 LFS 服务器——除非服务器端单独配置了存储配额或白名单
- Git 服务提供商（如 GitHub Enterprise）允许为组织级 LFS 设置用量上限和下载权限（例如禁止 fork 仓库下载 LFS 内容），但这不属于 Git 协议范畴
真正容易被忽略的是：LFS 文件一旦上传，其 oid 在所有引用中复用。如果某次 commit 引用了旧 oid，而该文件已在 LFS 服务器被管理员删除，后续 git lfs pull 就会失败——这不是权限问题，而是数据一致性断裂。运维侧必须定期审计 LFS 存储健康状态，不能只盯 Git 仓库权限。
