不能直接在生产机运行 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() 的配合——关了校验却不重载缓存，旧字节码还在跑，新代码根本不会生效。 
