必须启用Windows系统级长路径支持（注册表LongPathsEnabled=1并重启），再配置Git core.longpaths=true，同时优化项目路径（如克隆到根目录、调整缓存路径或使用稀疏检出），三者缺一不可。
Windows系统级长路径开关必须先开
只配Git不改系统，90%的情况仍然报错。因为ERROR_FILENAME_EXCED_RANGE (206)是Windows内核API在CreateFileW等函数入口就拦截的，Git连文件系统都没摸到。必须先启用系统层支持：
- 按
Win + R，输入regedit打开注册表编辑器 - 定位到
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystem - 新建或修改 DWORD (32 位) 值：
LongPathsEnabled，设为1 - 重启电脑 —— 不重启无效，这是硬性要求
这一步打开后，Windows才允许应用使用扩展路径前缀 \?，否则Git即使开了core.longpaths也无权调用底层接口。
Git配置core.longpaths要分作用域设
git config --global core.longpaths true看似一劳永逸，但实际有坑：
- 全局配置对已存在的仓库不自动生效，需进每个仓库再运行一次
git config core.longpaths true - 某些CI环境（如GitLab Runner）以服务账户运行，可能读不到用户级
--global配置，得用--system（需管理员权限） - 企业Git服务器若启用了strict path validation策略，仅客户端开长路径仍会拒绝推送，需同步检查服务端配置
验证是否生效：在任意仓库执行 git config --get core.longpaths，输出 true 才算到位。
路径过长常和模板生成、依赖缓存耦合爆发
单纯克隆老项目很少出问题，真正高频场景是构建工具自动生成深度嵌套路径：
- Flutter/HarmonyOS项目中，
PUB_CACHE默认落在C:Users{用户名}AppDataRoamingPubCache，加上包名和版本号轻松破300字符 —— 应手动设环境变量PUB_CACHE=D:PUB - Java项目里，Maven本地仓库
~/.m2/repository+ 多级groupId + artifactId + version + classifier，配合Git submodule嵌套，极易触发 - 像
jeecg-boot这类代码生成器，模板中含大量占位符拼接（如V{currentDate}_1__menu_insert_{entityName}.sql），原始路径本身合法，但渲染后爆炸式增长
这类问题单靠core.longpaths压不住，必须从源头缩短缓存/输出目录，或改用符号链接（mklink /D）做路径映射。
别信“浅克隆能解决路径过长”这种误导
git clone --depth=1只是跳过历史提交，所有文件仍会完整检出，路径长度一点没少。实测某Vue组件库用该参数克隆后，依然在node_modules/@vue/composition-api/dist/vue-composition-api.esm-bundler.js处报Filename too long。
真正有用的辅助手段只有两个：
- 把仓库克隆到根目录下，比如直接
cd D: && git clone https://xxx.git，砍掉用户路径那几十个字符 - 用
git sparse-checkout只检出必要子目录，避免拉取整个docs/examples/nested/deeply/structured/树
系统注册表+Git配置+项目路径三者缺一不可，漏掉任何一层，都可能在某个深夜构建时突然失效 —— 尤其是升级Windows或重装Git后，LongPathsEnabled容易被重置，得重新检查。
