如何解决Composer安装后脚本导致项目目录读写权限异常问题？

本文共计923个文字，预计阅读时间需要4分钟。

直接结论：

为什么 post-install-cmd 不该承担权限修复主责

Composer 的 post-install-cmd 是在安装完成后由当前用户身份执行的钩子，它无法越过系统级权限限制——如果 vendor/ 已被 sudo composer install 创建为 root 所有，普通用户运行脚本时连 file_put_contents("vendor/autoload.php") 都会失败，更别说递归改权。
常见错误现象包括：
• 脚本中途报 Permission denied 且无后续输出
• chmod -R 看似成功，但 vendor/bin/phpunit 仍提示 Operation not permitted（尤其 macOS / WSL）
• CI 日志显示 “cache file write failed”，实际是脚本试图往只读缓存目录写日志

哪些目录真需要 install 后自动设权？

真正该由 post-install-cmd 管理的，是项目运行时需动态写入的**应用级目录**，而非 Composer 自身产物。典型场景包括：
• Laravel 的 storage/ 和 bootstrap/cache/
• Symfony 的 var/cache/ 和 var/log/
• 自定义上传目录（如 public/uploads/）
这些目录通常不在 Git 中，且权限策略与 vendor/ 完全无关。正确做法是：
• 用 PHP 原生函数判断并创建，避免依赖 shell 命令的跨平台风险
• 目录权限设为 0755（所有者可读写执行，组和其他人仅读执行）
• 文件权限设为 0644（如 .env），不开放全局写入
• 避免对整个 storage/ 递归 chmod -R 775，日志文件应为 0644，而 storage/logs/ 子目录才需 0755

Linux/macOS 下安全可用的 post-install-cmd 示例

以下配置放在 composer.json 的 "scripts" 段内，经实测兼容 PHP 7.4+ 及现代 Composer 版本：

"post-install-cmd": [<br> "@php -r \"if (!is_dir('storage')) { mkdir('storage', 0755, true); }\"",<br> "@php -r \"if (!is_writable('storage')) { chmod('storage', 0755); }\"",<br> "@php -r \"if (!is_dir('storage/logs')) { mkdir('storage/logs', 0755, true); }\"",<br> "@php -r \"if (!is_writable('storage/logs')) { chmod('storage/logs', 0755); }\"",<br> "@php -r \"if (file_exists('.env') && !is_writable('.env')) { chmod('.env', 0644); }\""<br>]注意：
• 不调用外部 chmod 命令，规避 shell 权限继承问题
• 每次操作前检查目录存在性与可写性，防止重复失败
• 不对 vendor/、composer.lock 或缓存路径做任何操作——它们的权限必须在运行 composer install 前就由用户属主和 umask 决定

Windows 和 WSL 用户的特殊处理点

Windows 原生环境无需 chmod，但 WSL 用户若项目放在 /mnt/c/ 下，上述 PHP 脚本中的 chmod() 调用会静默失败（NTFS 不支持 POSIX 权限）。此时应：
• 将项目移至 WSL 原生路径（如 ~/project），再执行 composer install
• 若必须保留在 /mnt/c/，禁用所有 chmod() 行，改用 Windows ACL 工具（如 icacls）在 PowerShell 中预设目录权限
• 在 composer.json 中用 platform-check 区分环境：

"post-install-cmd": [<br> "[ $(uname) = 'Linux' ] && php -r \"mkdir('storage', 0755, true) || true;\" || exit 0"<br>]这个细节常被忽略：脚本本身无法修复 WSL + Windows 路径的底层权限模型冲突，只能绕过。