Git报内存不足错误主因是其自身内存阈值限制，而非系统真缺内存：64位Git仍受单次malloc上限约束，需调http.postBuffer、pack.windowMemory等参数，并检查ulimit、overcommit策略及Swap/分页文件配置。
git pull/push 报 Out of memory 或 not enough memory
这类错误不是系统真没内存，而是 Git 自身在打包、解包、HTTP 传输阶段触发了硬性内存阈值。64 位 Git 默认仍受限于单次 malloc 的分配上限（比如 http.postBuffer 默认仅 1 MB），遇到大文件或深度历史仓库时极易踩中。
-
http.postBuffer控制 HTTP POST 请求缓冲区大小，git push失败常因它太小：运行git config --global http.postBuffer 2147483648（2 GB）可覆盖默认值 -
pack.windowMemory影响 delta 压缩解压时的内存分配，对git pull更关键：设为512m或1g（如git config --global pack.windowMemory 1g） - 禁用压缩能显著降低峰值内存：执行
git config --global core.compression -1，代价是网络传输体积略增，但换来了稳定性 - 如果只拉最新代码，别硬扛全量历史——改用
git clone --depth=1或git fetch --depth=1
Git 报 “次优的 pack – 内存不足”
这个警告本质是 Git 检测到当前 pack 文件太大，而它预估自己拿不到足够连续内存来高效解包，于是退回到低效但省内存的 unpack 方式。它不中断操作，但后续 git status、git log 会明显变慢，且容易演变成 fatal 错误。
- 优先调
pack.threads：设为1（git config --global pack.threads 1），避免多线程争抢内存导致碎片化 -
pack.deltaCacheSize控制 delta 缓存上限，设为2g可缓解重复解包开销：git config --global pack.deltaCacheSize 2g - 确认不是旧 Git 版本 bug：Git 2.30+ 对大 pack 的内存预估更准，低于 2.25 的版本建议升级
- 该警告高发于含 LFS 大文件或二进制资产的仓库，此时应配合
git lfs install和服务端 LFS 支持，而非靠调参数硬顶
Linux 下 ulimit 或 overcommit 导致 malloc 失败
即使 free -h 显示还有 2 GB 空闲，git 进程仍可能因用户级限制或内核内存策略被拒。这不是 Git 配置能绕过的层级问题。
- 检查当前限制：
ulimit -v（虚拟内存）、ulimit -m（物理内存），若输出是数字（如 2097152 表示 2 GB），说明被显式限制了 - 临时解除：
ulimit -v unlimited；永久生效需编辑/etc/security/limits.conf，加一行* soft memlock unlimited - 查看 overcommit 策略：
cat /proc/sys/vm/overcommit_memory。值为0时，内核会保守拒绝大块分配——临时切到1（sudo sysctl vm.overcommit_memory=1）往往立竿见影 - Swap 不是“备胎”，是刚需：512 MB～2 GB 物理内存的机器，必须配至少 2 GB Swap（
sudo fallocate -l 2G /swapfile），否则 OOM Killer 会在 Git malloc 前直接 kill 进程
Windows 下 git.exe 报 “not enough memory for initialization”
这是 Windows 特有的虚拟内存（分页文件）耗尽信号。Git for Windows 是 32 位进程（即使系统是 64 位），地址空间上限约 2–3 GB，一旦分页文件不足，连初始化都失败。
- 不要只看“可用物理内存”，打开「系统属性 → 高级 → 性能设置 → 高级 → 虚拟内存」，确认分页文件已启用且大小足够（建议“系统管理的大小”或手动设为物理内存 1.5 倍）
- TortoiseGit 用户注意：它底层调用的是同个
git.exe，所以配置和错误表现完全一致，优化方式也相同 - 若用 WSL2，问题逻辑接近 Linux，但需额外检查
wsl.conf中是否限制了内存：[wsl2]段下加memory=2GB可防容器内资源不足 - Git for Windows 更新到 2.40+ 后，部分 malloc 调用已迁移到 64 位兼容路径，但初始化阶段仍卡在 32 位限制，不能指望单靠升级彻底解决
实际调试时最容易忽略的点：Git 的内存配置项之间存在隐式依赖。比如设了 pack.windowMemory 1g 却没调 pack.threads 1，多线程反而会让总内存消耗翻倍；又比如开了 core.compression -1 却没调 http.postBuffer，push 仍会在 HTTP 层崩。得按场景组合调整，而不是堆参数。
