vendor目录不能简单chmod -r 555，因为php进程需执行位（x）遍历子目录，缺x位会导致opendir()失败及autoload.php无法加载；同时框架可能需写vendor/composer/下文件，故须分层控制：目录755、文件644、bin脚本单独+x、动态映射文件按需设664。
vendor目录为什么不能简单chmod -R 555
PHP 进程需要执行位（x）才能进入子目录，chmod -R 555 vendor/会让opendir()失败，直接报Warning: require(/path/vendor/autoload.php): failed to open stream。更麻烦的是，某些框架会在vendor/composer/下尝试写autoload_static.php或installed.json，触发Permission denied——这不是配置问题，是权限模型错配。
生产环境vendor权限的正确分层设置
只读 ≠ 全局不可写，而是按用途精细控制：
-
chown -R deploy:deploy vendor/→ 归属部署用户，避免root残留 -
chmod 755 vendor/→ 目录必须有执行位，否则无法遍历 -
find vendor/ -type f -exec chmod 644 {} \;→ 所有PHP文件、autoload映射设为仅所有者可写 -
chmod +x vendor/bin/* 2>/dev/null || true→ 仅放行明确需执行的二进制（如phinx、phpunit），其余脚本不保留x位 - 若用动态类映射（如插件热加载），单独
chmod 664 vendor/composer/autoload_classmap.php，否则预生成后设为644
CI/CD同步后权限丢失的典型原因
rsync或cp -r会继承源端umask或挂载点权限，导致部署后www-data无法读取autoload_*.php：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
file_put_contents(/var/www/app/vendor/composer/autoload_static.php): Permission denied→ 实际是vendor/composer/属主为root，而PHP进程以www-data运行且未加入deploy组 -
Could not scan for classes inside "app/Console"→ CI中composer dump-autoload生成的文件权限为600，部署后www-data无读权 - 修复关键：确保
www-data属于deploy组：usermod -aG deploy www-data
Docker与CI中vendor属主错位的隐蔽源头
容器或CI里vendor/属主为root，往往不是命令写错，而是UID不匹配或缓存继承：
- Docker构建时用
USER root跑composer install→ 镜像内vendor/属主是root，但运行时PHP进程（如www-data）无权读取 - GitHub Actions用了
cache: composer，解压后文件继承上一次构建的root属主 -
sudo -u www-data composer install没重设$HOME→ 它仍从/root/.composer/cache加载，缓存属主错位 - 修复方案：Dockerfile中优先
USER appuser；CI脚本加chown -R $GITHUB_ACTOR:$GITHUB_ACTOR vendor/
真正卡住权限加固的，从来不是数字调大调小，而是属主归属和执行位缺失这两处细节——它们在部署日志里不报错，却让autoload静默失败。
