Composer install本身不控制文件权限，实际由umask、运行用户属主及文件系统共同决定；95%权限问题源于属主错位而非权限数字过小，应优先用chown修复归属，禁用sudo和777。

Composer install 本身不控制解压后文件权限

Composer 没有 --chmod 或 --umask 这类参数，它不会主动设置下载包解压后的文件权限。实际权限由三者共同决定：运行用户的 umask、宿主文件系统是否支持权限位（如 NTFS、NFS、WSL /mnt/c）、以及解包工具（tar/unzip）的行为。比如 umask 0002 会让新目录默认为 775、文件为 664；而 umask 0022 则是 755 和 644。

真正起作用的是 umask 和运行用户归属

你在终端执行 composer install 时，当前 shell 的 umask 值决定了所有新建文件/目录的默认权限。如果看到 vendor/bin/phpunit 没有执行位，或 storage/logs 不可写，大概率是 umask 过松（如 0000），或你用了 sudo 导致属主变成 root。

• 查当前值：umask
• 临时收紧（推荐 CI/Docker 中使用）：umask 0022，再跑 composer install
• Dockerfile 示例：RUN umask 0022 && composer install --no-dev --optimize-autoloader
• 别依赖 chmod -R 补救——它不解决属主错位，还可能让 bin 脚本被安全扫描拦截

post-install-cmd 脚本能改权限，但只该用于项目目录

post-install-cmd 是唯一能“干预”权限的地方，但它只能在 vendor 解压完成后运行，且仅适合调整项目自身目录（如 storage、bootstrap/cache），不能修改 vendor/ 内部文件权限——那属于上游包作者的职责，强行改可能破坏签名验证或 autoload 逻辑。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 正确用法示例（写入 composer.json）：

  "scripts": {
    "post-install-cmd": [
      "@php -r \"mkdir('storage', 0775, true);\"",
      "@php -r \"mkdir('bootstrap/cache', 0775, true);\"",
      "chmod 644 .env",
      "chmod 755 storage bootstrap/cache"
    ]
  }

• 避免递归设权：chmod -R 775 vendor/ 是危险操作，会把 vendor/autoload.php 变成组可写，CI 工具常直接拒绝构建
• Windows 下 chmod 不生效，应改用 PHP 脚本判断 is_writable() 并 chmod()（需启用了 chmod 函数）

vendor 权限出问题？先看属主，不是 chmod 数字

报 Permission denied 时，错误路径里那个目录（比如 /var/www/app/vendor/）就是线索。立刻执行：ls -ld vendor/。如果第三列显示 root root 或 www-data www-data，说明是属主错位，不是权限不够。

• 修复命令：sudo chown -R $USER:$USER vendor/ composer.lock
• 全局缓存也得查：ls -ld $(composer config --global cache-dir)，同样要属主匹配当前用户
• WSL、Docker bind mount、macOS 外接 NTFS 盘上，chown 可能静默失败，此时应换路径（如 composer config -g cache-dir ~/composer-cache）

真正麻烦的从来不是数字权限，而是谁拥有这个目录——属主错位了，再调 chmod 也只是给漏洞贴胶布。