composer clear-cache 不修复权限问题，仅清除缓存文件；若 ~/.composer/cache 归属为 root，则命令因 permission denied 失败，须先用 chown 修复属主再执行。
composer clear-cache 本身不修复权限问题
composer clear-cache 只删缓存文件，不改目录属主。它清的是 ~/.composer/cache/files/、repo/、vcs/ 这些子目录里的内容，但若整个 ~/.composer/cache 目录归属是 root，那命令执行时就会卡在 Writing cache file 或直接报 Permission denied——根本进不去清理环节。
多用户环境下，常见污染路径是有人用 sudo composer global require，导致 ~/.composer 下所有子目录（包括 cache、vendor、config.json）被设为 root:root。此时普通用户运行任何 composer 命令都会失败，clear-cache 也不例外。
先查归属，再 chown，最后 clear-cache
必须按顺序操作，跳过检查直接清缓存大概率失败：
- 确认当前用户：
whoami - 查缓存路径：
composer config --global cache-dir（新版通常是~/.config/composer/cache，旧版是~/.composer/cache） - 看归属：
ls -ld $(composer config --global cache-dir)—— 如果输出里第一列不是你的用户名，就说明权限污染了 - 修复归属：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 再试：
composer clear-cache，此时应有类似Clearing cache (12.4 MiB)的输出
为什么不能只清缓存就完事
多用户系统里，权限污染常不止于 cache/ 目录：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
~/.composer/vendor/bin下的全局命令软链接可能属root，导致laravel、phpunit等命令执行时报Permission denied - 项目内
vendor/目录若曾被sudo composer install生成，也属root，后续composer update会写不进去 -
~/.composer/config.json若属root，修改镜像源（composer config -g repo.packagist）会失败
所以完整修复得覆盖三处：~/.composer（或 ~/.config/composer）、项目 vendor/、以及 composer.json 所在目录本身。
避免下次再污染的硬约束
Linux 多用户环境里，sudo composer 是唯一明确要禁用的操作：
- 永远不要用
sudo composer install或sudo composer global require - 如果必须装全局工具，先确保
~/.composer/vendor/bin属于当前用户，再配PATH；或者改用用户级 bin 目录：composer config -g bin-dir ~/bin，然后mkdir -p ~/bin && export PATH="$HOME/bin:$PATH" - CI/CD 或部署脚本里，明确指定运行用户（如
su -c "composer install" -s /bin/sh www-data），别依赖 root 切换
缓存目录权限错位是静默故障，不会立刻报错，但会在某次 clear-cache 或 global require 时突然爆发。修复后记得验证：用普通用户跑一次 composer global require laravel/installer，再检查 ~/.composer/vendor/bin/laravel 是否可执行——这才是真正闭环。
