windows上git clone报“filename too long”错误，是因系统max_path默认限制260字符（含盘符、分隔符及文件名），git检出时调用windows api创建深层路径失败；常见于node_modules嵌套、ios pods或java生成路径等场景。
为什么 Windows 上 git clone 会卡在 “Filename too long”
这不是 Git 本身的问题，而是 Windows 系统级限制在作祟：MAX_PATH 默认为 260 字符（含 C:\、所有 \ 分隔符和文件名）。Git 下载对象没问题，但检出（checkout）时调用 Windows API 创建深层路径文件失败，就会报 fatal: cannot create directory at 'xxx': Filename too long 或 error: unable to create file xxx: Filename too long。
常见高危场景包括：
- 项目放在
C:\Users\YourName\Documents\GitHub\...这类长路径下 - 前端项目带
node_modules，尤其含嵌套 scope 包（如@types/react-router-dom） - iOS 项目含
Pods/或 Swift Package 依赖，路径动辄十几层 - Java/Maven 项目中生成的 shaded jar 路径含长 classifier 和 timestamp
检查当前 core.longpaths 是否已启用
先确认问题是否只是配置缺失——很多用户装完 Git for Windows 后没手动开长路径支持。
在 Git Bash 或命令行中运行：
git config --get core.longpaths
如果返回 false 或空，说明未启用；返回 true 则需排查其他原因（比如系统级限制未解、或路径真超了 32767 字符极限）。
注意作用域优先级：--local > --global > --system。若某仓库目录下 .git/config 里显式写了 longpaths = false，它会覆盖全局设置。
快速启用长路径支持（推荐首选）
对绝大多数情况，只需一条命令即可生效，无需重启系统：
- 全局启用（影响所有仓库）：
git config --global core.longpaths true
- 仅对当前仓库启用（适合无管理员权限环境）：
git config core.longpaths true
- 克隆时临时启用（适合单次操作）：
git clone -c core.longpaths=true <url><path></path></url>
执行后再次 git config --get core.longpaths 验证应返回 true。若仍报错，说明 Git 进程未读到新配置——关闭并重开终端，或重启 IDE（如 VS Code、IntelliJ）。
Windows 系统级长路径支持必须打开
即使 core.longpaths = true，若 Windows 系统本身没放开限制，Git 仍会在底层 API 调用时失败。这是最容易被忽略的一环。
分情况处理：
-
Windows 10/11 专业版/企业版：运行
gpedit.msc→ 计算机配置 → 管理模板 → 系统 → 文件系统 → 启用“启用 Win32 长路径” → 设为“已启用” → 重启电脑 -
Windows 家庭版：运行
regedit→ 定位到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem→ 修改LongPathsEnabledDWORD 值为1→ 重启电脑
注册表项不存在时可手动新建；修改前建议导出备份。该设置是系统级开关，Git 的 core.longpaths 只有在此基础上才真正起效。
复杂点在于：某些企业环境禁用组策略或注册表编辑，此时只能换路径——把仓库克隆到根目录下，例如 D:\p\，硬压低初始路径长度。这招虽土，但实测有效。
