composer.json 不支持环境级权限控制，因其仅为构建时静态配置；权限由 umask、安装用户身份及后置 chmod 共同决定，需在 CI 中按环境执行差异化部署脚本。
composer.json 里不能配环境级权限控制
Composer 本身不识别“开发环境”“生产环境”这类运行时概念，composer.json 是构建时静态配置，所有字段（包括 config、scripts）在 install 或 update 阶段就已解析完毕。你无法在里面写 "if ENV == 'prod' then chmod 644" 这类逻辑——它根本不会执行条件判断。
真正起作用的是 umask + 安装用户 + 后置 chmod
权限最终由操作系统决定，关键三点：
-
umask决定新建文件/目录的默认权限：部署前跑umask 0022，确保文件是644、目录是755 - 安装用户身份很重要：绝不用
root或高权限用户执行composer install；CI 中应切换到非特权用户（如deploy） - 必须加后置加固步骤：哪怕 umask 设对了，某些包的
post-install-cmd仍可能创建可写 symlink 或目录，所以安装完立刻执行：find vendor/ -type f -exec chmod 644 {} \;<br>find vendor/ -type d -exec chmod 755 {} \;<br>chmod 755 vendor/bin/*
不同环境用不同 .env 文件控制部署行为
虽然 composer.json 不支持环境分支，但你可以用外部变量驱动安装流程。比如在 CI 脚本中：
- 开发环境：
umask 0002 && composer install --no-dev（宽松一点，方便本地调试） - 生产环境：
umask 0022 && composer install --no-dev --optimize-autoloader && ./fix-perms.sh - 把
fix-perms.sh当作环境专属脚本，不放进vendor/，只在部署流水线里调用
注意：.env 文件对 Composer 无直接作用——它只影响 docker-compose 或应用层读取，别指望靠它改 composer install 的行为。
别碰 auth.json 的环境隔离幻想
有人想为 dev/staging/prod 各建一个 auth.json，再按环境切换——这行不通。因为：
-
auth.json只能存在于用户主目录（~/.composer/auth.json），且权限必须是600 - 项目根目录下放
auth.json是严重安全错误，会泄露凭据，且 Composer 会忽略它（除非显式用--auth指定） - CI 场景下应动态注入：
composer config http-basic.repo.example.com $USERNAME $TOKEN --global，而不是生成多个静态文件
真正的环境隔离点不在 Composer 配置里，而在部署用户、umask、文件系统挂载选项（如 noexec）、以及 Web 服务器运行用户与 vendor 目录的属组关系上——这些才是权限是否落地的关键。
