Composer如何在Nginx+PHP-FPM环境中部署？（生产配置）

不能直接在生产机运行 composer install，因会触发权限错误、超时及安全隐患；须在构建阶段完成并同步 vendor 目录，禁用生产环境 composer 命令，配合 –no-dev 等参数优化 autoload，并确保 opcache 配置正确（如 validate_timestamps=0）及部署后重置缓存。

为什么不能直接在生产机上运行 composer install

因为 Composer 默认会写缓存、生成 autoload 文件、执行 post-install-cmd 脚本——这些操作在 php-FPM 进程里跑，容易触发权限错误或超时。更关键的是：vendor/ 目录若由 web 用户（如 www-data）生成，PHP-FPM 读取时可能因 umask 或 SELinux 策略失败；反过来，若用 root 装，又可能留安全隐患。

实操建议：

立即学习“PHP免费学习笔记（深入）”；

• 所有 composer install 必须在构建阶段完成（CI/CD 或本地打包），产出完整 vendor/ 和 autoload.php，再整体同步到生产机
• 禁用生产环境的 composer 命令：删掉二进制或限制权限，避免误操作
• 用 --no-dev --optimize-autoloader --classmap-authoritative 参数，减少运行时扫描和文件 I/O
• 确认 opcache.enable=1 且 opcache.validate_timestamps=0（部署后需手动 opcache_reset() 或重启 PHP-FPM）

nginx 配置里哪些路径必须禁止访问

PHP-FPM 是以 fastcgi 协议把请求转给 PHP 的，Nginx 本身不解析 PHP，所以它只管“别让不该暴露的文件被直接下载”。常见踩坑点是忘了屏蔽 composer.json、.env、vendor/ 下的源码。

实操建议：

立即学习“PHP免费学习笔记（深入）”；

• 在 server 块里加 location 规则，例如：

  location ~ /.(env|json|lock|git|hg|svn)$ { deny all; }

• 显式拒绝 vendor/：

  location ^~ /vendor/ { return 403; }

• 不要依赖 try_files $uri $uri/ /index.php?$query_string 就万事大吉——它不拦 .json 后缀，也不防目录遍历
• 如果用了 laravel 的 public/ 入口，确保 root 指向 public，而非项目根目录

PHP-FPM pool 权限配错的典型表现

最常遇到的是 502 Bad gateway，但 php-fpm.log 里只有 “connect() to unix:/run/php/php8.1-fpm.sock failed”，其实根本原因是 socket 文件权限不对，或者 pool 用户没权限读 vendor/autoload.php 中的类文件。

实操建议：

立即学习“PHP免费学习笔记（深入）”；

• 检查 www.conf 里的 user 和 group（比如 www-data），确认它们对 vendor/、storage/、bootstrap/cache/ 有读+执行权限（目录要 +x 才能进入）
• socket 文件路径（listen = /run/php/php8.1-fpm.sock）的父目录 /run/php/ 必须允许该 user 写入；否则改用 listen = 127.0.0.1:9000 绕过 Unix socket 权限问题
• 避免用 chmod -R 777 storage/ —— 改成 chown -R www-data:www-data storage/ + chmod -R 755 storage/ 更安全
• 如果开了 security.limit_extensions = .php，确保 Nginx 的 fastcgi_split_path_info 没把非 PHP 文件误传给 PHP-FPM

autoload 优化后仍慢？可能是 opcache 配置漏项

即使用了 --optimize-autoloader，如果 opcache 没加载 classmap 或跳过 timestamp 校验，每次请求仍要 stat 文件、解析 class 定义，尤其 vendor 里成千上万个文件时延迟明显。

实操建议：

立即学习“PHP免费学习笔记（深入）”；

• 确认 php.ini 中启用了 opcache.enable=1 和 opcache.enable_cli=0（CLI 不需要）
• 关键配置补全：

  opcache.validate_timestamps=0<br>opcache.revalidate_freq=0<br>opcache.max_accelerated_files=20000<br>opcache.memory_consumption=256

• 部署新代码后，别只 reload nginx，要 systemctl reload php8.1-fpm 或调用 opcache_reset()（需在白名单 IP 或 CLI 下执行）
• 用 opcache_get_status() 查看 opcache.hit_rate，低于 95% 就说明还有文件没进缓存或配置不合理

实际部署时最容易被忽略的，是 opcache.validate_timestamps=0 和 opcache_reset() 的配合——关了校验却不重载缓存，旧字节码还在跑，新代码根本不会生效。