composer install 在共享主机报 permission denied 的根本原因是其默认依赖可写全局缓存和项目路径，而共享主机仅开放用户主目录下子目录（如 ~/myapp/）为可写，web 目录（如 ~/public_html/）通常禁止写入 vendor/。
为什么 composer install 在共享主机上直接报错 Permission denied？
因为默认情况下，Composer 会尝试往系统级目录（比如 /usr/local/bin 或 ~/.composer/vendor/bin）写入可执行文件，而共享主机禁止写入这些路径。更常见的是，vendor/ 目录创建失败，错误信息通常是：file_put_contents(./vendor/autoload.php): Failed to open stream: Permission denied —— 实际是当前用户对项目根目录没有写权限，或磁盘配额已满。
根本原因不是 Composer 本身需要 root，而是它默认行为依赖「可写入的全局缓存 + 可写入的项目本地路径」，而共享主机通常只开放用户主目录（如 /home/username/）下的子目录为可写。
- 确认你的项目是否放在
~/public_html/或~/www/这类 Web 可访问目录下 —— 这些位置往往被主机限制写入，尤其是vendor/自动生成时 - 优先把项目代码放在
~/myapp/这类纯用户目录中，再通过 Web 服务器 alias 或符号链接暴露出去 - 运行前先执行
umask 002，避免后续生成的文件因权限太严导致 PHP 运行时报failed to open stream
如何在无 root 权限下安装并使用 Composer 二进制？
别碰系统级安装。直接下载 PHAR 文件到你有写权限的任意目录（比如 ~/bin/），然后加执行权限即可用。
- 创建目录：
mkdir -p ~/bin - 下载最新稳定版：
curl -sS https://getcomposer.org/installer | php -- --filename=composer --install-dir=~/bin - 确保
~/bin在$PATH中：在~/.bashrc或~/.profile末尾加一行export PATH="$HOME/bin:$PATH"，然后运行source ~/.bashrc - 验证：
composer --version应该能正常输出 —— 如果报command not found，说明PATH没生效或 shell 配置未重载
composer install 卡在 Cloning into '...' 或提示 git clone failed 怎么办？
共享主机通常禁用 git 命令，但 Composer 默认优先走 Git 克隆（尤其对 dev- 分支或 vcs 类型仓库）。它不会自动 fallback 到 zip 包下载，除非你明确关掉。
- 强制使用 dist 包而非源码克隆：
composer install --prefer-dist - 永久生效：在项目根目录运行
composer config prefer-dist true，这会在composer.json同级生成composer.lock并写入配置 - 如果仍失败，检查
composer.json中是否有自定义仓库（repositories）指向私有 Git 地址 —— 这种情况必须换为 HTTPS zip 链接，或联系仓库提供方启用 zip 下载支持 - 注意：某些包（如 laravel 的部分扩展）在
--prefer-dist下可能缺失开发用脚本，生产环境一般没问题，但本地调试时需留意
vendor/autoload.php 找不到或不生效？检查这三处
不是 Composer 没装好，而是 PHP 加载路径或 Web 服务器配置没对上。共享主机常把 Web 根目录和项目实际路径分开，容易漏掉这一层。
- 确认
vendor/autoload.php确实存在且可读：ls -l vendor/autoload.php；如果不存在，说明composer install没成功跑完（看上一步） - PHP 脚本里引入路径写绝对路径更稳：
require __DIR__ . '/../myapp/vendor/autoload.php';，而不是相对路径../vendor/autoload.php（容易因include_path或当前工作目录变化失效） - 检查 Web 服务器是否禁用了
allow_url_include或设置了过严的open_basedir—— 错误日志里会出现is_dir(): open_basedir restriction in effect，这时要把vendor/所在的完整路径加进open_basedir（通常在.htaccess或php.ini用户配置里）
最麻烦的点其实是：共享主机的 PHP 进程用户（如 apache 或 nginx）和你 ssh 登录的用户不同，导致文件所有者不一致。哪怕你 chown 过，下次 Composer 更新又会以你用户身份生成新文件 —— 解决办法只有全程用同一用户操作，或让主机支持 suexec。这点容易被忽略，但真出问题时排查成本最高。