Composer path仓库提示Directory does not exist，根本原因是url必须为相对于主项目composer.json的合法相对路径，不支持~、$HOME或绝对路径，且目标目录须含有效composer.json并具备读取权限。
Composer path 仓库提示 Directory does not exist 怎么办？
路径不存在错误通常不是路径写错了，而是 Composer 在解析 path 类型仓库时，**只认相对于 composer.json 所在目录的相对路径**，且不支持波浪号（~）、环境变量或绝对路径别名。
常见现象：composer update 报错 Directory /xxx/yyy does not exist，但用 ls -d /xxx/yyy 确实存在。
- 检查
repositories中的url字段是否用了~/my-package或$HOME/my-package—— 这些一律不展开，必须写成../my-package或../../vendor-packages/my-package - 路径必须指向一个含有效
composer.json的目录，不能是空目录、软链接（除非系统级启用 symlink 支持且 Composer 版本 ≥2.2）、或 Git 工作区未初始化的目录 - Windows 用户注意反斜杠：
"url": "..\my-package"可能被解析失败，统一用正斜杠"../my-package"
本地包 composer.json 缺少 autoload 导致自动加载失败
即使 path 路径正确、composer update 成功，运行时仍可能报 Class not found —— 这是因为 Composer 不会自动为 path 包注册自动加载规则，它完全依赖该包自身的 autoload 配置。
- 确保本地包根目录下的
composer.json包含合法autoload段，例如："autoload": { "psr-4": { "MyVendor\MyPackage\": "src/" } } - 修改本地包的
autoload后，需在主项目中运行composer dump-autoload，否则新映射不会生效 - 如果本地包没有
autoload，又不想加（比如纯配置包），可在主项目的autoload中手动追加映射，但这样会失去包自治性
为什么 path 依赖更新后代码没变？
Composer 对 path 类型仓库默认启用“硬链接”（hard link）或符号链接（symlink），行为取决于操作系统和 composer.json 配置。这导致：改了本地包代码，PHP 却还在用旧字节码（OPcache）或旧 require 结果。
- 确认是否启用了 symlink：
"options": {"symlink": true}在repositories.path下；若没配，Composer 默认用 copy 模式，此时改本地源码根本不会影响 vendor 目录 - 使用 symlink 模式时，务必清 OPcache：
opcache_reset()或重启 PHP-FPM / Apache - 开发中建议显式开启 symlink 并配合
composer update --no-cache，避免因缓存误判文件状态
多层嵌套 path 引入时的路径解析陷阱
当 A 项目通过 path 引入 B 包，而 B 包自身又通过 path 引入 C 包时，C 的路径是相对于 B 的 composer.json，不是 A 的。这点极易被忽略，导致 B 安装失败。
- 每个
path仓库的路径都只在自己所在composer.json的上下文中解析，Composer 不做递归重写 - 若想共享同一套本地依赖树，所有
path应基于同一个根目录约定（例如全部以../packages/xxx形式书写），并确保各项目都在该根目录的子目录下 - 跨团队协作时，这种嵌套 path 很难维护，建议改用私有 Packagist 或
git@+dev-main分支方式替代
最常被忽略的是：路径本身没问题，但当前用户对目标目录没有读取权限（尤其是 Docker 容器内执行时 uid 不匹配），或者 SELinux/AppArmor 限制了访问 —— 此时错误信息仍是模糊的 Directory does not exist，实际得查系统日志。
