根本原因是path仓库目录属主为root而非当前用户，需用sudo chown -r $user:$user修复该路径归属；报错中带完整路径的一行即问题所在，ls -ld确认属主后精准修复，禁用chmod -r 777。
根本不是权限位不够，而是 Composer 尝试写入的目录（比如 vendor/、composer.lock 或自定义 path 仓库对应的本地路径）属主被锁死为 root，当前用户无权接管。
报错里出现 path 仓库路径时，先确认它是否真实可写
Composer 的 path 仓库类型（如 "type": "path"）会把本地目录当作包源，安装时需将该目录内容软链接或复制进 vendor/。但若该本地路径本身不可写，或其父目录属主是 root，就会直接失败。
- 查清报错中具体路径：终端输出里带完整路径的那一行，例如
Could not symlink /home/user/mylib to vendor/mylib: Permission denied→ 问题在/home/user/mylib目录本身 - 运行
ls -ld /home/user/mylib，看第一列是否含root root；如果是，说明这个“本地包”目录也被sudo污染过 - 注意：即使
mylib是你自己建的，只要曾用sudo git clone或sudo cp过，就可能已变root所有 - 别在
path仓库路径里放符号链接指向系统级目录（如/usr/local/lib），那里的权限策略更严格，且 Composer 不会帮你绕过
path 仓库指向的目录属主是 root 怎么办
不能只修 vendor/，必须同步修复 path 源目录的归属——否则下次 composer update 仍会卡在 symlink 阶段。
- 执行
sudo chown -R $USER:$USER /home/user/mylib（替换成你实际的path路径） - 如果该目录是 Git 仓库，顺手检查
git status是否提示 ownership changed；若有，说明内部文件也混了root权限，需一并修正 - 若
mylib是子模块或挂载点（比如 WSL2 下挂载 Windows 分区的/mnt/c/dev/mylib），chown无效，得改挂载参数或换到 Linux 原生路径（如~/dev/mylib） - 临时验证：用当前用户手动执行
ln -s /home/user/mylib test-link，失败则证明问题确实在源路径
为什么 chmod -R 777 对 path 仓库无效
因为 path 类型依赖的是操作系统级的文件所有权控制，而非权限位。尤其在 symlink 模式下，Composer 调用的是 symlink() 系统调用，内核只认 owner，不看 777。
-
chmod -R 777 /home/user/mylib后仍报 Permission denied？大概率是mylib所在文件系统不支持 chmod（如 vboxsf、WSL2 的/mnt/c、某些 NFS 挂载） - 强行设
777还会让 Git 提交时记录错误的 mode 变更（100777），后续协作时引发冲突 - 安全扫描工具（如 Semgrep、CI 的 Trivy）会直接拒绝构建含
777的vendor/或path包目录 - 真正要动的是 owner：
sudo chown -R $USER:$USER是唯一可靠解法，chmod只用于补救 umask 导致的默认无写权限（如mkdir -m 755后需加u+w）
最易被忽略的一点：path 仓库的路径若含空格或中文，某些旧版 Composer 会静默截断或解析失败，报错却显示成权限问题——先用纯英文路径验证，再排查归属。
