Git LFS 拉取 unexpected EOF 与临时文件写入失败排查修复-平芜编程栈

1. 三行报错拆开看，其实是三个故障面叠在一起

git lfs pull失败，屏幕上只剩下一行红字：cannot write data to tempfile "/root/8dc6d01e84acccd8a5769d5": LFS: unexpected EOF。很多人第一反应是去修网络，也有人直接怀疑仓库里的 LFS 对象坏了，然后重新 clone 一遍，结果在同一行报错上再次卡住。这个报错最容易误导人的地方在于：它把“写不进本地”和“读不回远端”两件事压缩成了一句话，而这两件事的排查路径几乎相反。

先说清楚这段内容是什么。这是一次 Git LFS 大文件拉取的现场事故复盘，核心围绕git lfs pull过程中出现cannot write data to tempfile与LFS: unexpected EOF的组合报错展开，覆盖成因定位、现场取证、参数调整、配置固化四个环节。它解决的问题是：当仓库里挂着几十兆到几百兆的二进制资产（模型权重、设计稿、音视频素材、数据集切片）时，默认配置下的 LFS 拉取会以各种姿势中断，而报错信息又不足以直接指向根因。

适合谁看：日常要处理带 LFS 仓库的后端、算法、客户端同学；负责 CI 流水线、构建机、容器镜像维护的运维同学；以及被这条报错卡了半天、不想再靠“删了重拉”碰运气的任何人。不需要你对 Git 内部对象模型有多深的理解，只要你会敲df、会看环境变量、能改 git config，这篇里的流程就能直接照着走一遍。

1.1 报错发生在下载链路的哪一环

把 LFS 拉取拆成四步，报错的位置就很好定位了：

客户端读取工作区里的指针文件（几十字节的文本，形如version https://git-lfs...加一段 oid 和 size）；
把这批 oid 打包，向服务端发一个 batch 请求，拿到每个对象对应的下载地址和大小；
按lfs.concurrenttransfers指定的并发数，逐个下载对象，边下边写进一个临时文件；
校验字节数无误后，把临时文件重命名到最终路径.git/lfs/objects/xx/yy/<oid>，再由 smudge 过滤器把内容检出到工作区。

报错文本里的cannot write data to tempfile明确落在第 3 步，而/root/8dc6d01e84acccd8a5769d5这个没有扩展名、没有层级、直接挂在/root下面的随机文件名，是典型的临时文件命名风格——前缀随机、无后缀、由程序在运行时生成。也就是说，客户端已经拿到了下载地址，已经开始收数据，但在“把收到的字节落到磁盘”这个动作上失败了。

这里有个细节值得停下来想一秒：正常的 git-lfs 临时文件通常落在.git/lfs/tmp或者你配置的lfs.storage目录下，路径里会带.git。而现在它出现在了/root根下，说明这个环境的临时目录被重定向过——可能是TMPDIR被设成了/root，可能是lfs.storage被配到了家目录，也可能是HOME=/root且某个环节直接用了os.TempDir()的返回值。这一条线索，后面排查时会成为分水岭。

1.2 为什么“写失败”和“EOF”总是成对出现

unexpected EOF字面意思是“提前到达流末尾”。在 HTTP 下载场景下，服务端在响应头里声明了Content-Length，客户端按这个长度收字节，收到一半连接断了，实收字节数小于声明值，就会抛 EOF。这也是为什么很多人一看 EOF 就认定是网络问题。

但在这个组合报错里，EOF 很可能是“写失败”的次生结果，而不是原因。设想一下底层流程：客户端从连接里读一块缓冲，往临时文件写一块；当write()因为磁盘满、inode 耗尽、配额超限、权限不足而返回错误时，写入循环被打断，读取循环也随之终止，尚未消费完的响应体被直接丢弃。在客户端的视角里，它看到的现象就是“数据流没有走完”，于是报出了 EOF。

反过来也成立：如果真的是链路中途断开，写入侧会拿到一个不完整的文件，此时磁盘写入本身没报错，但最终字节数校验不通过，同样会以 EOF 的形式抛出。所以这两条信息谁先谁后，光看报错文本是分不出来的，必须靠现场取证来判定——这就是下一节要干的事。

提示：不要在这个阶段就急着重装 git-lfs 或删仓库。LFS 对象在服务端是内容寻址的，本地删掉只会让你重新下载一遍，根因没动，报错必然复现。

我遇到过最典型的误判，是某开发者看到 EOF 就以为是公司内网出口设备把大文件传输掐断了，于是把并发调到 1、把超时拉到 600 秒，来回折腾两小时，最后df -h一看，构建机根分区只剩 300MB。报错文本从来不会主动告诉你“磁盘满了”，它只会告诉你“我写不进去”。

2. 五分钟现场取证：先分清是“写不进去”还是“读不回来”

排查这类问题的效率，取决于你多快能把故障面收敛到一侧。我的习惯是不做任何修改，先花五分钟把现场信息全部抓下来，再决定动手方向。因为一旦你先改了配置、清了缓存，现场的很多证据就没了，后面只能靠猜。

取证的目标只有三个：临时目录到底在哪、那块盘还剩多少、传输过程有没有留下痕迹。下面三步按顺序做，做完基本就能定性。

2.1 空间与 inode 的双重检查

先看容量，这是最容易被忽略又最常见的一条：

df -h df -i

两条命令都要跑，别只跑第一条。df -h看的是块空间，df -i看的是 inode 数量。很多人只知道磁盘满会写失败，不知道 inode 耗尽同样写不进去，而且报错信息几乎一模一样。LFS 仓库的特点是对象多、单文件大，但如果你的仓库里混着大量小文件（比如逐帧导出的图片序列、上千个几 KB 的配置快照），inode 消耗会非常快。inode 用满时，df -h可能还显示有几十 G 空闲，但任何新建文件的操作都会失败。

重点看两个挂载点：临时文件所在的分区（本例是/root所在的根分区），以及最终存储目录所在的分区（默认.git/lfs/objects，跟仓库同盘）。这两个如果在不同分区，还有个坑：临时文件写完后需要重命名到最终位置，跨分区重命名会失败。虽然这次报的是 EOF 不是跨设备错误，但如果你后面为了省空间把临时目录指到另一块盘，就得提前想到这一层。

顺手再确认一下配额。如果机器上开了用户级磁盘配额，df是看不出来的：

quota -s 2>/dev/null || echo "quota 命令不可用或未启用"

容器环境里更要注意，容器看到的磁盘容量往往和宿主机不是一回事，这个放到第 3 节细说。

2.2 用 git lfs env 确认临时目录的真实位置

这一步是整个排查里最有价值的一步。git-lfs 自带一个环境自检命令，会把它认为的各个关键路径全部打印出来：

git lfs env

输出里重点关注四行：LocalWorkingDir（工作区根）、LocalGitDir（.git 位置）、LocalMediaDir（LFS 对象最终存储目录）、TempDir（临时文件目录）。TempDir那一行如果指到了/root或者别的奇怪位置，报错里的路径就解释得通了。

同时把几个可能影响临时目录的环境变量一起打出来：

env | grep -iE 'tmp|temp|home|git_lfs'

TMPDIR是第一嫌疑人。有些构建镜像为了让容器内的临时文件不落到 overlay 层，会把TMPDIR统一指到挂载卷上；也有反过来的，把TMPDIR指到家目录图省事。一旦TMPDIR=/root，而/root又恰好在空间紧张的系统盘上，报错就顺理成章了。

确认目录可写性也别省：

ls -ld /root id touch /root/.write_test && echo "可写" && rm -f /root/.write_test

注意id的输出。如果你是在容器里以非 root 用户运行，而TMPDIR指向/root，那就是纯粹没权限——/root默认权限是700，非属主连列目录都做不到，更别说建文件。这种场景下的报错文本和磁盘满几乎一样，但修法完全不同。

2.3 打开传输日志，看重试与断流记录

定性到这一步，如果空间和权限都没问题，就该看传输过程了。git-lfs 支持用标准的环境变量把 HTTP 层日志打出来：

GIT_TRACE=1 GIT_CURL_VERBOSE=1 git lfs pull 2>&1 | tee /tmp/lfs-trace.log

日志会很长，别从头读，用关键字过滤：

grep -nE 'HTTP/|Content-Length|error|retry|timeout|EOF' /tmp/lfs-trace.log | head -80

看几个点：响应状态码是不是 200；Content-Length声明的字节数和你期望的对象大小是否吻合；有没有出现多次重试（retry关键字）；断开发生在传输开始后多久。如果每次都是在差不多的时间点断（比如稳定在 30 秒左右），那更像是超时配置问题；如果是随机时长断，且断的时候机器负载很高，那更可能是写入被阻塞后连接被拖死。

还有一条容易被忽略的线索：单对象大小。用git lfs ls-files -s可以列出所有 LFS 对象的 oid 和体积：

git lfs ls-files -s | sort -k3 -n -r | head -20

如果报错总是出现在体积最大的那几个对象上，方向就很清楚了——不是网络不行，是单个对象太大，超过了某个环节能承受的窗口。这个信息在后面的参数估算里会直接用到。

3. 六类高频成因与对应处置方案

现场取证拿到线索之后，成因基本能归到下面几类里。我按出现频率从高到低排，每一类都给出判断依据和对应动作，你可以直接对号入座。

3.1 容量类：磁盘满、inode 耗尽与临时空间翻倍

判断依据：df -h某分区使用率 95% 以上，或df -i的 IUse% 接近 100%。

这一类最反直觉的地方在于“临时空间翻倍”。很多人算空间只算 LFS 对象总体积，忽略了下载过程中临时文件的存在。峰值占用大概是：

峰值临时空间 ≈ 并发数 × 最大单对象体积 × 1.5（安全系数） 总需求 ≈ LFS 对象总体积 + 峰值临时空间 + 工作区检出体积

举个具体的：仓库 LFS 对象共 12GB，最大单文件是 400MB 的模型权重，默认并发 8。峰值临时空间 ≈ 8 × 400MB × 1.5 ≈ 4.8GB。再加上工作区最终要把这些文件全部检出（又是一份 12GB），实际需要的空闲空间接近 29GB。如果构建机根分区总共 40GB、系统已占 20GB，那必然会炸。

处置动作分两手。第一手是立刻释放空间：git lfs prune能清掉本地不再被引用的 LFS 对象，git gc --prune=now清理松散对象，docker system prune处理容器镜像残留（如果是容器环境）。第二手是把临时目录挪到空间充足的分区，同时保证它和lfs.storage在同一分区：

git config --global lfs.storage /data/lfs-store export TMPDIR=/data/lfs-store/tmp mkdir -p "$TMPDIR"

注意：lfs.storage和TMPDIR一定要在同一块盘上。跨分区时临时文件写完后无法用 rename 落位，会退化成“复制 + 删除”，对大文件来说既慢又容易在中途出现新的中断。

inode 耗尽的处置更简单粗暴：找出是哪个目录在疯狂产生小文件。find /path -xdev -type f | wc -l按目录统计一下，通常是构建产物、日志轮转、缓存目录。清掉之后df -i立刻能看出来。

3.2 权限类：/root 下那个写不动的临时文件

判断依据：id显示当前用户非 root，但TempDir指向/root；或者ls -ld看到目标目录属主是 root、权限 700。

这类问题的荒诞之处在于，报错路径看起来完全合法——文件确实该建在那儿，只是你没资格建。容器里换用户运行是最常见的触发场景：镜像默认USER root，CI 里为了安全改成非 root 用户，但HOME环境变量没跟着改，仍然是/root，于是 git-lfs 按HOME推导临时目录，直接撞墙。

修复方式有三种，按侵入性从小到大排：

# 方式一：临时指定，只影响当前会话 export TMPDIR=/home/ci/tmp && mkdir -p "$TMPDIR" # 方式二：写进 git 配置，长期生效且不污染环境变量 git config --global lfs.storage /home/ci/lfs # 方式三：容器镜像层面修根因，把 HOME 和 TMPDIR 一起改掉 # Dockerfile 里加： # ENV HOME=/home/ci TMPDIR=/home/ci/tmp

我更倾向方式二加方式三的组合：配置层面用lfs.storage把存储位置钉死，镜像层面把HOME纠正过来。只改TMPDIR的问题是它太容易被后续的 shell 脚本覆盖，今天修好了，明天某个source又把环境变量冲掉了。

还有一个隐蔽的权限问题是父目录的执行位。临时文件要建在/root下，你不光需要对/root有写权限，还需要对它以及各级父目录有x权限。用namei -l /root一路看下去，任何一级缺x都会失败。

3.3 传输类：并发太高、超时太短与断流重试

判断依据：磁盘空间充足、权限正常，但日志里能看到多次 retry，或者断开时间点比较集中。

默认lfs.concurrenttransfers是 8，这个值在本地开发机上很合适，放到共享出口的构建机上就偏激进。八条连接同时拉几百兆的二进制，出口带宽被瞬间打满，任何一条连接稍微慢一点就会触发lfs.activitytimeout（默认 30 秒无数据活动即判定超时）。超时之后客户端会重试，重试又从零开始拉，于是你看到的现象是“进度条反复回退，最后 EOF”。

调整方向是“降并发、拉超时”：

git config --global lfs.concurrenttransfers 3 git config --global lfs.activitytimeout 120 git config --global lfs.dialtimeout 60 git config --global lfs.tlstimeout 60 git config --global lfs.transfer.maxretries 5

参数怎么定，别拍脑袋。并发数的上限受两个约束：出口带宽和磁盘写入能力。粗略估算，如果单对象平均 200MB、目标总耗时希望控制在 10 分钟内，那么需要的有效吞吐约 200MB × 对象数 / 600 秒。假设 60 个对象，就是 20MB/s，按单连接 5MB/s 估算，并发 4 就够，没必要开 8。另一个约束是磁盘：机械盘随机写并发 8 会让 IO 等待飙高，反而更慢；SSD 上开 4 到 6 比较合适。

还有一种情况是对象本身在服务端就不完整。这种概率不高，但一旦碰上，无论你怎么调参数都会在同一个 oid 上失败。验证方法是看报错里的 oid 是否每次都一样：

git lfs ls-files -l | grep <oid前几位> git lfs fsck

git lfs fsck会校验本地对象完整性。如果确认是服务端对象缺失，那就只能联系仓库维护方重新推送，客户端侧再怎么调都是徒劳。

3.4 环境类：容器配额、overlay 与只读挂载

判断依据：容器内df -h显示空间充足，但写入依然失败；或者mount输出里能看到 overlay、tmpfs。

容器环境的坑在于“看得见的空间”和“能用的空间”不是一回事。overlay 文件系统的上层可写层往往有单独的大小限制（比如 10GB），df -h /显示的可能是宿主机的大盘，而实际写入落到可写层，一超限就失败。判断方法是看挂载类型：

mount | grep -E ' / |overlay' findmnt -T /root

如果/root落在 overlay 上，最稳妥的做法是把 LFS 存储和临时目录都指到显式挂载的卷上，别让它落在可写层里。这既解决空间问题，也避免了大文件把镜像层撑爆。

另一个常见情况是tmpfs。有些镜像把/tmp挂成 tmpfs，容量是内存的一半。LFS 拉几个大文件就能把它填满，而且 tmpfs 占的是内存，填满之后整机都开始 swap，表现是“机器卡死然后报 EOF”。这种场景下df -h /tmp会显示一个很小的容量，一看便知。

只读挂载也会引发类似报错。CI 里经常把仓库目录以只读方式挂进容器，.git/lfs/objects自然写不进去。touch一下目标目录就能验证，报Read-only file system就别再纠结网络了。

3.5 存储类：文件系统特性与长路径

判断依据：换到某台特定机器才复现，其他机器正常。

不同文件系统对大文件、稀疏文件、并发写的处理差异很大。网络文件系统（NFS、SMB 挂载）在写大文件时对锁和缓存的处理和本地盘完全不同，并发写多个大文件容易出现超时后连接被服务端单方面关闭，客户端看到的就是 EOF。如果仓库放在网络盘上，建议把lfs.storage指到本地盘，拉完再同步过去。

还有一种是小众但真实的情况：某些文件系统对单文件大小或目录内文件数有限制。LFS 的对象目录是按 oid 前两位、次两位分层的（.git/lfs/objects/ab/cd/...），单个目录下的文件数不会太多，一般不会撞上限。但如果有人手工改过存储结构，就不好说了。git lfs env看一眼LocalMediaDir的实际结构，比猜快得多。

3.6 配置类：被 .lfsconfig 悄悄改掉的路径

判断依据：git lfs env显示的路径和你预期完全不符，且本机 git config 里找不到对应项。

仓库根目录可以放一个.lfsconfig文件，里面的配置会在 clone 和 pull 时被读取。如果这个文件里写了lfs.storage指向某个绝对路径，那所有克隆这个仓库的人都会受影响。这种情况在多环境协作里特别容易出问题——写配置的人在本地路径是/data/lfs，到了你的机器上这个路径根本不存在或者不可写。

cat .lfsconfig 2>/dev/null git config --list --show-origin | grep lfs

第二条命令会带上配置来源文件，一眼就能看出某个值是从仓库配置、全局配置还是系统配置来的。排查配置类问题时，--show-origin比--list有用得多。

提示：.lfsconfig里适合放和仓库相关的相对路径类配置，不适合放绝对路径和机器相关的路径。团队协作时建议在规范里明确这一条，能省掉大量“为什么只有你那儿报错”的沟通成本。

4. 一套可以直接抄的修复流程

前面讲的是分类判断，这一节给一条完整的、可以照着执行的路径。我按“先止血、再定位、后固化”的顺序组织，每一步都有明确的验证动作，做完一步确认一步，不要跳步。

4.1 分步执行清单

第一步，把现场信息存下来，避免后面反复试错丢证据：

mkdir -p /tmp/lfs-diag && cd /tmp/lfs-diag df -h > df-h.txt 2>&1 df -i > df-i.txt 2>&1 git lfs env > lfs-env.txt 2>&1 env | grep -iE 'tmp|temp|home|git_lfs' > env.txt 2>&1 mount > mount.txt 2>&1

第二步，判断是空间问题还是传输问题。看df-h.txt和df-i.txt，任一使用率超过 90%，先按 3.1 处理；都正常则进入第三步。

第三步，确认临时目录可写。从lfs-env.txt里找到TempDir，然后：

TMPDIR_PATH=$(git lfs env | grep '^TempDir=' | cut -d= -f2-) echo "临时目录: $TMPDIR_PATH" mkdir -p "$TMPDIR_PATH" dd if=/dev/zero of="$TMPDIR_PATH/.probe" bs=1M count=512 oflag=direct 2>&1 | tail -2 rm -f "$TMPDIR_PATH/.probe"

这一步写 512MB 测试文件，既验证权限又验证真实可用空间。oflag=direct绕过页缓存，得到的是真实落盘速度。如果这一步就失败了，问题定性完成，直接修目录。

第四步，收敛并发并重试：

git config lfs.concurrenttransfers 2 GIT_TRACE=1 GIT_CURL_VERBOSE=1 git lfs pull 2>&1 | tee /tmp/lfs-retry.log

并发降到 2 是刻意的保守值，目的是把“是不是并发导致的”这个变量排除掉。如果 2 能过、8 不能过，那就是并发问题，再往上慢慢试探找到这台机器的甜点值。如果 2 也过不去，说明和并发无关，回去看日志。

第五步，分段拉取。如果仓库 LFS 对象特别多，一次性pull太重，可以按目录分批：

git lfs pull --include="assets/models/**" git lfs pull --include="assets/datasets/**"

--include支持通配符，配合.gitattributes里的路径规则使用。分批拉的好处是单次事务小，失败后重来的代价低，而且容易定位到具体是哪批对象有问题。

第六步，落盘校验：

git lfs fsck git status

fsck会检查本地对象是否完整，git status确认工作区没有残留的未检出文件。两步都干净，才算真正修完。

4.2 参数怎么估：三个算得出来的数

调参最怕拍脑袋，这里给三个能算的数。

并发数。按目标吞吐反推：

所需并发 ≈ 期望总吞吐 ÷ 单连接实测吞吐 期望总吞吐 ≈ LFS 对象总体积 ÷ 期望完成时间

实测单连接吞吐的方法很简单，拉一个中等大小的对象，看日志里的耗时。假设单连接 6MB/s，你希望 12GB 在 15 分钟内拉完，需要 13.6MB/s，那并发 3 就够。开到 8 只是让带宽更快见底，并不会更快完成。

超时时间。默认 30 秒的activitytimeout指的是“连续 30 秒没有收到任何数据”。对于几百兆的对象，只要链路不是完全卡死，一般不会触发。真正容易触发的是dialtimeout和tlstimeout，这两个卡的是建立连接阶段。跨地域访问时把这两个提到 60 秒比较稳妥，activitytimeout提到 120 秒足够，再高意义不大。

临时空间。用 3.1 里的公式，但要注意一个细节：lfs.concurrenttransfers只限制同时在传的对象数，每个对象在传输期间都会独占一个临时文件。所以峰值临时空间是并发数乘以最大单对象体积，而不是平均体积。仓库里如果有个 2GB 的巨型文件，并发开到 4，光临时文件就要 8GB，这个数必须先算出来再决定开多大。

4.3 一份配置模板

把上面这些收敛成一份可以直接用的配置。全局配置放机器相关的路径和并发，仓库配置放和项目相关的东西：

# 全局：路径与并发，跟机器绑定 git config --global lfs.storage /data/lfs-store git config --global lfs.concurrenttransfers 3 git config --global lfs.activitytimeout 120 git config --global lfs.dialtimeout 60 git config --global lfs.tlstimeout 60 git config --global lfs.transfer.maxretries 5 # 仓库级：和项目相关，可以随仓库走 git config lfs.fetchinclude "assets/**" git config lfs.fetchexclude "assets/archive/**"

fetchinclude和fetchexclude这两个在 CI 里特别有用。历史归档目录里的 LFS 对象可能从来没人看，但每次 clone 都要拉一遍。用fetchexclude排掉，clone 时间能砍掉一大截，也顺带降低了触发这个报错的面。

如果团队里多台构建机共享一套配置，可以把全局部分写进一个脚本，机器初始化时执行一次。别写进.lfsconfig——那个文件会跟着仓库走，把某台机器的绝对路径带进仓库，下次换人换机器又是一轮新的报错。

配置文件层面还有一个选择：~/.gitconfig和~/.config/git/config都生效，但后者更符合现在的习惯。用git config --global --list --show-origin可以确认到底改的是哪个文件，避免出现“我明明改了但不生效”的情况——十有八九是改了一个不生效的文件。

5. 常见问题速查与避坑清单

这一节把前面散落的判断点收敛成表，再补几条只有踩过才知道的经验。

5.1 常见问题速查表

报错表现	最可能的原因	快速验证	处置动作
每次都在同一个 oid 上失败	服务端对象缺失或损坏	`git lfs fsck`；对比 oid	联系仓库维护方重推，客户端无解
失败时间点集中在 30 秒左右	`activitytimeout`过短	查看`lfs.activitytimeout`	提到 120 秒，并发降到 2 到 3
进度条反复回退后 EOF	并发过高导致连接被挤断	日志里搜`retry`	`lfs.concurrenttransfers`降到 2
`df`有空间但写不进去	inode 耗尽	`df -i`	清理小文件目录
路径指向`/root`且当前非 root	`TMPDIR`或`HOME`指错	`env \| grep -i tmp`	改`TMPDIR`或`lfs.storage`
容器内`df`正常但失败	overlay 可写层配额	`findmnt -T /root`	临时目录挪到挂载卷
`/tmp`容量特别小	tmpfs 挂载，占内存	`df -h /tmp`	换`TMPDIR`到磁盘目录
只有某台机器复现	`.lfsconfig`写了绝对路径	`git config --list --show-origin`	删掉或改为相对路径
大文件必挂、小文件正常	单对象超出某环节窗口	`git lfs ls-files -s`	分批拉取，`--include`缩小范围

5.2 几条只有踩过才知道的经验

别在第一轮就git lfs prune。prune 清的是本地已经不存在的 LFS 对象，它确实能腾空间，但如果你正在拉的这批对象还没下完，prune 之后重拉等于从头再来。正确顺序是先确认容量缺口有多大，用du -sh .git/lfs看本地已经占了多少，再决定是清本地还是扩空间。

GIT_LFS_SKIP_SMUDGE=1是个很好的止血工具。当仓库大到你只想先拿到代码、LFS 回头再说时：

GIT_LFS_SKIP_SMUDGE=1 git clone <仓库地址> cd <仓库> git lfs pull --include="你需要的那部分/**"

这样 clone 阶段完全不碰 LFS，指针文件原样落盘，工作区里是几十字节的文本而不是几百兆的二进制。它不解决根因，但能让你在排查期间不被卡住。

日志里的时间戳比报错文本有用得多。GIT_TRACE=1输出的每一行都带耗时。我习惯算一下“从开始下载到断开”的间隔：如果这个间隔在不同对象上高度一致，几乎可以断定是超时阈值；如果间隔杂乱无章，那才是真正的随机断流或写入阻塞。这个判断用肉眼扫一眼日志就能做，比反复改配置试错快得多。

并发调小之后记得调回来。排查时把lfs.concurrenttransfers降到 2 是常见操作，但很多人修完之后忘了改回去，结果后续所有仓库的拉取都慢得让人抓狂，还以为是自己网络变差了。建议排查时用仓库级配置（git config lfs.concurrenttransfers 2，不带--global），修完直接git config --unset，不影响全局。

临时目录和存储目录放同一块盘，这条要写进团队规范。跨分区的代价不只是性能：临时文件写完之后需要一个原子重命名，跨分区时这一步会失败，git-lfs 会退化成读一遍再写一遍，中间任何中断都会让前面下载的字节白费。我在三个不同环境里见过同一个坑，两次是有人为了省空间手动改的，一次是构建镜像里预设的。

最后，给这条报错一个正确的心理预期。unexpected EOF这个措辞很有迷惑性，它读起来像“网络断了”，但实际情况里，磁盘相关原因占的比例远高于网络。我自己的统计里，前三位分别是容量不足、临时目录权限、并发过高，网络本身的锅不到两成。所以下次再看到这行红字，第一件事是df -h和git lfs env，而不是去 ping 服务器。

至于仓库侧能做的优化，如果你们团队正在维护一个 LFS 对象动辄上 G 的仓库，值得考虑的是把历史归档目录用fetchexclude排掉，把超大文件拆成带索引的分片，以及在 CI 里缓存.git/lfs/objects而不是每次全量拉。这几点做下来，这条报错出现的频率会低很多，即使出现，影响面也小得多。