Windows 的 bun patch 报 Could not access 长路径

Windows 已开启长路径，终端 Git 的 core.longpaths 也为 true，bun install 能完成，但 bun patch --commit 仍在生成差异时出现 Could not access，没有留下预期补丁。此时要检查 Bun 启动 Git 的环境，而不是继续反复修改同一个全局设置。

Bun 1.4.4 有这条具体表现：依赖中的深层文件完整路径超过常见的 Windows 路径边界，安装阶段正常，补丁阶段失败。Windows 的长路径策略、Git 配置，以及实际调用它们的子进程是不同层次。

终端读到的配置不等于补丁子进程读到的配置

Bun 的补丁实现会隔离 Git 的配置来源。1.4.4 的相关环境设置包括 GIT_CONFIG_NOSYSTEM=1，并将 HOME、XDG_CONFIG_HOME 和 USERPROFILE 设为空；因此终端里查到的用户级或系统级 core.longpaths，不保证会进入这个差异生成子进程。

先保留完整错误路径，计算工作区根目录、依赖相对路径拼接后的实际长度。不要只看文件名，也不要把“超过 260 个字符”写成所有工具一律失败的绝对边界；前缀形式、程序实现和 Windows 配置都会影响结果。

终端单独执行 Git 差异成功，只能证明那次 Git 调用的环境可用，不能证明 Bun 的隔离调用读取了相同配置。安装成功也没有覆盖后面的补丁差异阶段。

迁移前先保存已经改过的依赖

如果修改只存在于 node_modules，先另存修改内容和对应包版本，核对备份能找到原来的文件。补丁尚未生成时，直接删依赖、重新安装或清理失败工作区，都可能把唯一修改一并丢掉。

针对路径过深的项目，可在新的短路径工作区按原锁文件安装同一依赖，再按 Bun 原有补丁流程应用那份精确修改并提交补丁。应先检查现有补丁状态，避免把已经存在的补丁再应用一次。不要仅复制一份不清楚来源的依赖目录后就认定版本相同。

缩短工作区根路径可以降低这条调用遇到长路径的机会，且不依赖隔离子进程去读取用户配置。它不需要关闭安全软件或扩大目录权限，也不应演变成随意重命名依赖内部文件；后者会改变导入与包内容。

验收补丁能在干净安装中重建

确认补丁文件实际生成，包清单中的补丁登记与文件相符，并检查差异只含预期修改。随后在独立、可恢复的工作区按同一锁文件完成安装，确认补丁被应用，原来要修的功能也经过验证。

仅有命令退出码零，或者手工编辑后的依赖当前能运行，不足以证明下次安装可复现。原失败目录和修改备份在验证完成前应保留；后续清理只针对本次明确创建且没有其他工作在使用的内容。

这里的处理限定补丁差异生成遇到长路径的场景；若路径很短、错误实际是访问拒绝或文件已不存在，应继续按对应的文件状态排查。