生产环境部署PHP应用时应遵循Composer安全最佳实践：1. 禁止运行composer update，仅执行composer install以确保依赖版本一致；2. 提交并保护composer.lock文件以实现可重复部署；3. 使用--no-dev和--optimize-autoloader减少攻击面并提升性能；4. 限制执行权限，使用专用用户并控制目录写入；5. 验证依赖来源，启用HTTPS、定期审计漏洞；6. 在CI/CD中预安装依赖并打包，避免在生产机直接运行Composer；7. 清理敏感文件与缓存，防止配置泄露。坚持锁文件驱动、非交互式安装、最小权限和预构建部署原则，可显著提升安全性。
在生产服务器上运行 composer install 是 PHP 应用部署的关键步骤，但若操作不当，可能引入安全风险或服务中断。以下是为确保安全、稳定和高效部署而整理的 生产环境 Composer 部署安全核对清单。
1. 禁止在生产环境执行 composer update
composer update 会根据 composer.json 中的版本约束重新解析并更新依赖，可能导致意外升级第三方包，引入不兼容或恶意代码。
- 仅允许在开发环境中运行 composer update，确保所有变更经过测试。
- 生产环境只运行 composer install，它依据已提交的 composer.lock 文件精确安装指定版本。
- 可通过脚本或 CI/CD 流程强制检查，若检测到 composer.lock 有变更但未提交，则阻止部署。
2. 提交并保护 composer.lock 文件
composer.lock 记录了当前应用所依赖的所有包及其确切版本和哈希值，是实现可重复部署的基础。
- 必须将 composer.lock 提交到版本控制系统（如 Git）。
- 部署时确保该文件存在且未被篡改。
- 定期审查 lock 文件中的依赖项，及时发现废弃或高危包。
3. 使用 --no-dev 和 --optimize-autoloader 参数
减少生产环境的攻击面并提升性能。
- --no-dev：不安装 require-dev 中的开发依赖（如 PHPUnit、PHPStan），避免暴露调试工具。
- --optimize-autoloader（或 -o）：生成更高效的类映射，加快自动加载速度。
- 推荐完整命令：composer install --no-dev --optimize-autoloader --no-interaction
4. 限制 Composer 执行权限
避免以高权限用户运行 Composer，降低潜在风险。
- 使用专用部署用户（如 deploy 或 www-data）执行安装命令。
- 确保该用户仅拥有必要目录的写权限（如 vendor/），禁止写入应用核心代码。
- 部署完成后，重置文件权限，确保 web 可读但不可写。
5. 验证依赖来源与完整性
防止依赖供应链攻击（如恶意包注入）。
- 使用官方镜像或可信私有仓库（如 Satis、Private Packagist）。
- 启用 HTTPS 下载源（默认已开启）。
- 定期运行 composer audit（Composer 2.5+）检查已知漏洞。
- 考虑使用 Signed Commits 或 CI 安全扫描 来验证依赖变更。
6. 在隔离环境中预安装依赖
最佳实践是不在生产服务器直接运行 Composer。
- 在 CI/CD 流水线中预先执行 composer install --no-dev。
- 将生成的代码打包（如 tar.gz 或 Docker 镜像），再部署到生产环境。
- 这样可避免生产服务器暴露 PHP 和 Composer 解释器，减少攻击向量。
7. 清理敏感文件与缓存
防止泄露配置或临时数据。
- 部署后删除任何临时文件（如 .git、.env.example、phpunit.xml）。
- 不要将本地开发配置文件误推送到生产。
- Composer 缓存目录（~/.composer）不应存在于生产环境，或应定期清理。
基本上就这些。只要坚持“锁文件驱动 + 非交互式安装 + 最小权限 + 预构建部署”，就能大幅提升生产环境 Composer 使用的安全性。不复杂但容易忽略细节。
