解决Composer镜像同步过程中Vendor包文件权限丢失问题-composer-PHP中文网

镜像同步后vendor/bin脚本无执行权限，主因是阿里云等镜像源解压dist包时丢弃chmod+x位；应验证ls -l vendor/bin/phpunit是否为-rw-r--r--，临时用chmod +x vendor/bin/*修复，长期在post-install-cmd中自动补0755权限。

解决composer镜像同步过程中vendor包文件权限丢失问题

为什么镜像同步后 vendor 里的 bin 脚本没执行权限

国内镜像（如阿里云、腾讯云）同步 packagist 时，会重新打包或解压 dist 文件，但部分镜像源在构建过程中丢弃了原始 tar 包的 chmod +x 位——尤其影响 vendor/bin/phpunit、vendor/bin/phinx 这类可执行脚本。现象是：命令行直接运行 ./vendor/bin/phpunit 报 Permission denied，而 php vendor/bin/phpunit 可用。

这不是 Composer 错，也不是你本地 umask 问题，而是镜像源上游打包行为不一致导致的。官方 packagist.org 的 dist 包保留了执行位，但某些镜像为节省空间或兼容旧工具链，强制重设了文件权限为 644。

验证方式：ls -l vendor/bin/phpunit —— 如果显示 -rw-r--r--（无 x），就是它
临时补救：chmod +x vendor/bin/* 2>/dev/null || true
长期解法：在 composer.json 的 scripts 中加 post-install-cmd 自动修复（见下节）

如何让 post-install-cmd 自动修复 vendor/bin 权限

Composer 不会自动设执行位，但你可以用 post-install-cmd 在每次 composer install 后补上。注意：该脚本只在 Linux/macOS 生效，Windows 需单独处理。

把这段加进 composer.json 的 scripts 段：

Discussion Composer

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

下载

{
  "scripts": {
    "post-install-cmd": [
      "@php -r "if (is_dir('vendor/bin')) { $files = glob('vendor/bin/*'); foreach ($files as $f) { if (is_executable($f)) continue; chmod($f, 0755); } }""
    ],
    "post-update-cmd": ["@post-install-cmd"]
  }
}

它只对 vendor/bin/ 下已存在且非可执行的文件设 0755，不递归、不碰其他目录
避免用 find vendor/bin -type f -exec chmod +x {} \; —— 会把非脚本文件（如空 README）也设成可执行，部分 CI 工具会报 warning
如果项目用 Docker 构建，建议把这个脚本放在 docker build 阶段之后执行，而非依赖宿主机环境

镜像源切换后 vendor 权限错乱的根本原因

不是所有镜像都“只是加速”，有些会做二次处理：比如腾讯云镜像曾默认启用 --no-symlinks 解包、阿里云某版本对 dist tar 做过 tar --no-same-permissions 解压。结果就是：vendor/ 目录本身属主正确，但内部文件权限被重置为 644/755 统一值，破坏了原包设计意图。

查证是否镜像惹的祸：composer config --global repo.packagist 看当前源；再切回官方源试一次：composer config -g repo.packagist composer https://packagist.org，然后 rm -rf vendor && composer install
若官方源下权限正常，就确认是镜像问题 —— 别硬修，换镜像或提 issue
别用 chmod -R 755 vendor/ 全局修复：这会让 vendor/symfony/console/Resources/ 下的模板文件变成可执行，PHP 加载时可能跳过解析

Docker 构建中 vendor 权限丢失的隐蔽点

CI/CD 或本地 docker build 里，即使用了正确镜像，仍可能因构建上下文挂载方式导致权限丢失。典型场景：COPY . /app 后运行 composer install，但宿主机上的 vendor/ 是之前用 root 生成的，COPY 进容器后 UID 不匹配，容器内用户无法写入子目录。

最稳做法：不在 Dockerfile 中 COPY 已存在的 vendor/，而是 COPY composer.json composer.lock .，再 RUN composer install --no-dev --optimize-autoloader
若必须复用缓存（如 GitHub Actions 的 actions/cache），确保缓存解压后执行 chown -R www-data:www-data vendor/（根据容器内实际用户调整）
Alpine 镜像要额外注意：musl libc 下 tar 对权限位支持弱，加 --no-same-permissions 是默认行为，此时只能靠 post-install-cmd 补

真正难搞的不是权限数字本身，而是不同环节对“执行位”“组写位”“符号链接”的处理逻辑不一致 —— 镜像源、Docker 构建、CI 缓存、甚至 PHP-FPM 用户切换，每一步都可能悄悄抹掉一个 x。盯住 vendor/bin/ 和 vendor/composer/installed.json 这两个关键路径，比全局 chmod 有用得多。