Composer require path仓库报Permission denied本质是vendor/或composer.lock属主为root，普通用户无权操作；应先用ls -ld确认归属，再执行sudo chown -R $USER:$USER vendor/ composer.lock修复，或删后重装。
composer require path 仓库报 Permission denied
本质不是本地包路径本身没权限，而是 Composer 在创建软链接或写入 vendor/ 时被操作系统拒绝——95% 情况下是因为 vendor/ 或 composer.lock 属主是 root，而你正以普通用户执行 composer require。
先快速定位：
- 看终端错误里是否含 file_put_contents(.../vendor/autoload.php) 或 symlink(): Permission denied
- 运行 ls -ld vendor/ composer.lock，如果输出第一列含 root，就确认是所有权问题
修复方式（复制即用）：
- sudo chown -R $USER:$USER vendor/ composer.lock
- 如果刚执行过 sudo composer install，建议直接删掉：rm -rf vendor/ composer.lock，再用普通用户跑 composer install
path 类型仓库指向的本地目录被拒绝访问
Composer 对 repositories.type: "path" 的目录不做所有权校验，但会在 require 阶段尝试读取其 composer.json、创建符号链接、甚至执行 post-autoload-dump 脚本。若该目录本身权限太严（比如 chmod 700 且非属主），就会失败。
检查与修复：
- 运行 ls -ld ./packages/my-utils（替换成你的实际路径），确认属主是你自己，且至少有 r-x 权限
- 若属主是 root，运行 sudo chown -R $USER:$USER ./packages/my-utils
- 若权限是 drwx------，只需加执行位：chmod u+x ./packages/my-utils（不必 755，700 + u+x 已足够）
- Windows 用户注意：WSL 下若该目录挂载自 Windows NTFS 分区，可能默认无执行位，需在 WSL 中显式 chmod +x
装完本地包后 Class not found，其实是 autoload 写入失败
这常被误判为“权限不足”，实则是 vendor/composer/autoload_static.php 或 autoload_files.php 无法写入——根本原因仍是 vendor/ 目录归属不对，或父目录不可写。
验证与处理：
- 运行 composer dump-autoload，看是否报 file_put_contents(.../vendor/composer/autoload_static.php): failed to open stream
- 若报错路径落在 vendor/ 内，说明 vendor/ 权限未归还，重跑 sudo chown -R $USER:$USER vendor/
- 不要手动改 vendor/ 权限位（如 chmod -R 777），它只会让后续 CI 构建因安全策略失败
- 确保本地包的 composer.json 中 autoload.psr-4 键值末尾有反斜杠，例如："MyCompany\Utils\": "src/"，少一个 就会导致映射失效
CI 或 Docker 中 path 本地包反复权限失败
本地能跑，CI 报 Permission denied，大概率是 UID 不一致：宿主机用户 UID 是 1001，CI 容器默认以 UID 0（root）或另一个 UID 启动，挂载进来的 ./packages/ 目录对容器内用户不可读。
务实解法：
- 在 CI 脚本开头加一步修复：sudo chown -R $(id -u):$(id -g) ./packages/
- 或更彻底：构建阶段就统一 UID，例如 GitHub Actions 中用 run: docker run --user $(id -u):$(id -g) ...
- 避免在容器里用 sudo composer require——它会让 vendor/ 归 root，后续 PHP-FPM 或 artisan 命令全卡住
- 最小改动方案：把本地包路径从 ./packages/my-utils 改成绝对路径 /tmp/my-utils，并在 CI 中每次 cp -r 复制过去，绕过挂载权限问题
最容易被忽略的一点：所有修复都必须在 vendor/ 目录重建前完成。一旦 vendor/ 里混入 root 所有子目录（比如某个 symlink 指向的 target 是 root-owned），chown -R 可能无法穿透，只能删掉重来。
