答案是先定位报错路径归属，再用sudo chown -R $USER:$USER修复本地源目录所有权，并检查~/.composer及缓存目录归属是否正确。报错含file_get_contents(/path/to/my-repo/packages.json)说明本地源路径属主非当前用户，需递归修正所有权，禁用chmod -R 777，确保路径为绝对路径且支持Unix权限。
报错含 file_get_contents(/path/to/my-repo/packages.json) 怎么办
这说明 Composer 正在读取你配置的本地自定义源（比如 repositories 里写了 "type": "path" 或 "type": "package"），但系统拒绝访问该路径——不是权限位不够（如 755），而是文件/目录属主不对。Linux/macOS 下，即使有读权限，若属主是 root 或 www-data，当前用户仍会被拒。
立刻执行两行命令定位：
ls -ld /path/to/my-repo<br>ls -ld /path/to/my-repo/packages.json
看输出第三列（属主）是不是你的用户名。如果不是，问题就确认了。
- 用
sudo chown -R $USER:$USER /path/to/my-repo递归修复所有权，这是唯一安全做法 - 绝对不要
chmod -R 777：CI 工具会拒绝加载，Git 会警告 ownership changed - 如果路径在 Web 根下（如
/var/www/my-repo），只要$USER能读就行，Web 服务用户无需写权限
composer.json 里 "url": "../my-local-package" 导致安装失败
相对路径在不同项目根目录下解析结果不一致，composer install 可能找错位置，甚至跨项目污染缓存。
- 改用绝对路径：
"url": "/home/alex/my-local-package" - 路径含空格或中文？加
file://前缀并 URL 编码："url": "file:///home/alex/my%20local%20package" - 挂载自 Windows 共享盘或 Docker volume？先
touch /path/to/my-repo/test && rm /path/to/my-repo/test验证底层是否支持 Unix 权限；不支持就挪到~/repos/再试
换镜像后 composer install 仍卡在 packagist.org
不是镜像没生效，而是项目级 composer.json 中的 repositories 数组覆盖了全局配置，且顺序不对——Composer 会按数组顺序尝试，兜底才走 repo.packagist。
- 检查项目
composer.json是否存在repositories字段；如有，确保它把国内镜像放在最前面 - 或者干脆删掉整个
repositories数组，只依赖全局镜像配置（推荐） - 运行
composer config -g repo.packagist确认输出是类似{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 换源后必须
composer clear-cache，否则旧失败记录还在，重试照样走原地址
Permission denied 报错出现在 vendor/ 或 composer.lock
这不是缺权限，是“主人认错了”——这些目录曾被 sudo composer install 污染过，现在你以普通用户运行，系统直接拒绝写入。
- 执行
ls -ld vendor/ composer.lock $(composer config --global home)查归属 - 只要任一输出属主不是
$USER，就统一修复：sudo chown -R $USER:$USER vendor/ composer.lock ~/.composer - 别只修
vendor/：如果~/.composer/cache/是root所有，Composer 在读packages.json前就会卡在写缓存阶段，报错看起来像读取失败 - 修复后务必
rm -rf vendor && composer install重来，别信dump-autoload
实际排查时最容易忽略的是：本地自定义源和全局缓存归属混在一起，一个 chown -R 没打全，问题就藏在缓存目录里，表面看一切正常，但下次 install 就突然失败。
