根本原因是composer install不保留执行位且按umask重建文件，需用umask 002/022控制初始权限，再手动加固vendor/bin/*为可执行、php文件为644，禁用post-install-cmd自动chmod。

根本上，composer install 不会主动“破坏”权限——它只创建新文件、覆盖旧文件，而新文件的权限由系统 umask 和底层解压行为决定。所谓“破坏”，其实是原有权限被覆盖或继承了不匹配的默认值。防止的关键不是拦截 Composer，而是控制它运行时的环境和后续加固点。

为什么 vendor/ 权限总在 install 后“变掉”

常见现象是：你手动设过 chmod 755 vendor/，下次 composer install 后又变回 755 目录但里面 PHP 文件变成 644、脚本变成 644（不可执行）、甚至某些包的 bin/ 脚本丢了 x 位。原因有三：

• ZIP 包解压不保留 Unix 执行位，vendor/bin/phpunit 默认是 -rw-r--r--
• composer install 不读取也不应用你之前设的权限，它只管内容；旧文件被删、新文件按 umask 重建
• 某些包的 post-install-cmd 脚本（比如 Laravel 的 storage:link）会新建目录或符号链接，它们的权限取决于当前用户 umask，而非你期望的 775

用 umask 控制新建文件的初始权限

这是最轻量、最底层的干预方式。在运行 composer install 前临时设置 umask，能统一影响所有新建文件和目录的默认权限。

Discussion Composer

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

下载

• 开发/共享组环境推荐：umask 002 → 新建目录为 775，文件为 664（组可写）
• 生产/严格环境推荐：umask 022 → 新建目录为 755，文件为 644（仅属主可写）
• 别用 umask 000：虽能让所有文件可执行，但极大增加安全风险
• 验证是否生效：umask 命令输出应与你设的一致；之后 touch test && ls -l test 看权限是否符合预期

install 后必须立即加固 vendor/bin 和关键目录

即使 umask 设对了，vendor/bin/ 下的脚本仍大概率是 644。不能等、不能靠钩子自动跑（尤其跨平台），要作为部署流程的固定步骤：

• 修复可执行脚本：chmod +x vendor/bin/*（Linux/macOS）；Windows 用户请改用 php vendor/bin/phpunit 显式调用
• 禁止 vendor/ 下 PHP 文件被写入：find vendor/ -type f -name "*.php" -exec chmod 644 {} \;
• 确保 autoload.php 和 composer/ 子目录安全：chmod 644 vendor/autoload.php vendor/composer/*.json
• 慎用 chmod -R：递归设权容易误伤，比如把日志文件也设成 644，反而导致 PHP-FPM 写日志失败

别信 post-install-cmd 自动 chmod

在 composer.json 里写 "post-install-cmd": ["chmod -R 755 vendor/"] 是典型反模式：

• Windows 下直接报错退出，CI 流程中断
• 755 给所有文件加执行位，PHP opcache 可能拒绝加载，CI 工具常报 “unsafe permissions”
• 若 vendor/ 是符号链接（Docker volume 挂载），chmod -R 会穿透到源路径，改错地方
• 它掩盖了真正问题：你没控制好 umask，也没做安装后最小化加固

真正难的不是命令怎么写，而是得想清楚：权限该在哪一层定？是创建时（umask）、复制时（Docker --chown）、还是运行时（web server 用户组加入）？漏掉任意一层，都可能让 composer install 成为权限漂移的起点。