是否应使用git-lfs追踪项目依赖包信息元数据文件？

不推荐使用Git LFS追踪package-lock.json、yarn.lock、go.sum这类依赖锁文件，这种做法既不会提升存储/传输效率，还会直接破坏依赖管理的核心逻辑，实际生产环境踩坑概率极高。

为什么LFS追踪锁文件拿不到正向收益 #

• Git对文本文件的存储效率远高于直观认知：Git底层存储的是文件快照的增量压缩包，不会每次变更都存储全量文件。哪怕单次锁文件改动显示数万行，实际存储的压缩增量体积往往只有几KB到几十KB，远没有diff页面展示的行数看起来夸张。而LFS的机制是每次文件变更就存储一份独立的全量对象，长期迭代下来，LFS占用的存储空间、拉取时的流量消耗反而比原生Git存储文本大得多。举个实际场景的例子：中型Node项目的package-lock.json全量约1.5MB、5万行左右，迭代2年累计100次锁文件提交，原生Git仓库中所有锁文件版本的压缩总大小通常不到10MB；如果用LFS存储，100次变更就对应100份独立的1.5MB对象，总占用达150MB，拉取时还要额外走LFS服务接口，速度反而更慢。
• 锁文件是构建流程的强依赖，不属于可丢弃的生成产物：本地新环境初始化、CI/CD流程执行时，必须第一时间读取锁文件的完整内容，才能安装到版本完全一致的依赖，保证构建可复现。如果用LFS追踪锁文件，一旦出现LFS服务故障、本地未安装LFS钩子、LFS权限配置错误等情况，拉取到本地的锁文件只是几十字节的LFS指针文件，内容只有LFS版本标记、文件哈希、文件大小几行元数据，会直接导致依赖安装时JSON解析失败，整个构建流程崩溃。
• LFS不支持原生文本diff能力：锁文件提交到Git的核心价值之一就是可以在代码评审、问题排查时直接查看依赖版本的变更记录。如果交给LFS存储，在PR页面、本地git log中都无法直接查看锁文件的内容差异，必须手动拉取对应版本的LFS对象才能对比，审计、排查成本会陡增。

关于SVG使用LFS的适用边界 #

你提到的SVG建议用LFS存储的说法存在明确的适用前提：只有单个体积较大（通常10MB以上）、由工具自动导出、完全不需要人工编辑的SVG生成产物（比如复杂数据可视化导出的矢量图、工业设计软件导出的矢量图纸）才适合用LFS存储。日常项目中使用的SVG图标、人工维护的矢量素材，单文件通常只有几KB到几十KB，用原生Git存储的效率远高于LFS，强行用LFS只会增加不必要的流程复杂度。

LFS存储依赖类文件的适用场景 #

目前行业内没有通用的量化研究结论，能明确对应到特定编程语言、项目规模、迭代周期的LFS收益阈值——本质原因是依赖锁文件从设计上就不属于LFS的适用范畴。LFS的设计目标是存储大体积二进制资产，适合用LFS追踪的依赖相关文件只有三类：

• 单文件体积10MB以上的预编译二进制依赖，比如C/C++项目中的.so、.dll、.a预编译库
• 项目内置的大体积媒体资源，比如客户端、游戏项目依赖的高清贴图、音视频素材
• 体积超过100MB、不需要做文本diff、丢失后可以通过构建流程完整重新生成的产物

一个简单的判断标准可以覆盖90%以上的场景：只要是需要读取文本内容做diff、属于构建流程前置依赖的文本文件，不管单次改动行数多少，都不要用LFS存储；只有单文件体积超过10MB、不需要做文本对比、就算临时获取失败也不会阻塞核心流程的文件，才考虑纳入LFS追踪。

如果觉得Node生态锁文件diff行数太多影响评审效率，正确的优化方式不是使用LFS，而是升级到npm 7+、yarn 3+以上的新版本，新版包管理器的锁文件格式已经做了结构化优化，无意义的diff行数比老版本减少80%以上；也可以在.gitattributes中为锁文件配置自定义diff驱动，忽略哈希字段的无意义对比，实际体验提升远高于强行接入LFS。

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