windows下git报invalid path错误本质是ntfs文件系统拦截，主因是路径含保留名（如con、aux）或非法字符，需先禁用core.protectntfs验证，但保留名文件仍需重命名才能真正写入。
Windows 上遇到 error: invalid path，基本就是 Git 拒绝检出某些文件路径——不是网络或权限问题，而是 NTFS 文件系统层面的硬性拦截。核心原因就一个：你正在 checkout 的路径，在 Windows 下根本不能合法存在。
为什么 git clone 后只有 .git 文件夹
这是最典型的表征。Git 已完成对象下载（Clone succeeded），但 checkout 阶段失败，所以工作区空空如也。背后机制是：core.protectNTFS 默认为 true，Git 会主动跳过所有违反 NTFS 规则的路径（比如含保留名、双斜杠、非法字符等），且不报具体错误类型，只笼统提示 invalid path。
- 常见触发路径：
con.java、aux.c、prn.txt、folder//file、file:、file? - 注意：Windows 不区分大小写，
CON.java和con.java效果一样 -
git status -s会显示所有文件为D（deleted），其实是“从未被创建”，不是真删了
关闭 core.protectNTFS 是最快验证方式
临时禁用保护机制，能立刻判断是否为 NTFS 兼容性问题。但要注意作用域和副作用：
- 仅对当前项目生效：
git config core.protectNTFS false（需在已初始化的 Git 目录内执行） - 对当前用户全局生效：
git config --global core.protectNTFS false（影响所有后续 clone） - 修改用户级配置文件
C:\Users\{user}\.gitconfig，手动添加[core] protectNTFS = false - ⚠️ 关闭后，Git 仍无法真正创建
con这类保留名文件——它只是不再阻断 checkout 流程，但实际写入时仍会失败，并抛出unable to create file
长路径和保留名要分开处理
core.protectNTFS 解决的是 NTFS 命名限制（如保留字、8.3 短名冲突），不是路径长度问题。后者需额外配置：
- 启用系统级长路径支持：注册表中设置
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled = 1，或组策略启用「启用 Win32 长路径」 - 同时开启 Git 长路径支持：
git config --system core.longpaths true或git config --global core.longpaths true - 两者缺一不可：系统没开，Git 开了也没用；Git 没开，系统开了也白搭
真正无法绕过的文件名必须改名
如果 git checkout 后仍有 unable to create file xxx 报错，说明路径含 Windows 保留名（con、prn、aux、nul、com1～com9、lpt1～lpt9 等），这类名字在 NTFS 下完全禁止创建，Git 再怎么关保护也无济于事。
- 唯一解法：让仓库维护者在 Linux/macOS 端把
con.java改成config.java或类似合法名，再提交推送 - 若你无权改源码，只能本地 fork 后手动 rename 并提交，或使用
git restore --source=HEAD --no-overlay --staged --worktree -- :/清理状态后手工补文件（不推荐） - 别指望
core.protectNTFS false能解决这个——它只放宽“检查”，不突破系统内核限制
真正卡住人的往往不是配置开关，而是误以为关了 protectNTFS 就万事大吉；结果发现 con.java 还是死活写不进磁盘。这时候得回头确认：报错里那个“invalid path”，到底是 Git 拦的，还是 Windows 内核拦的。
