生产环境禁用 composer install 自动执行脚本，因 post-install-cmd 等脚本以 web 用户权限运行，可能越权操作、执行未知代码或触发未审核的数据库迁移；必须使用 --no-scripts --no-dev --optimize-autoloader 组合，将必要操作（如迁移、缓存预热）剥离为独立受控流程。
生产环境里直接运行 composer install 或带 post-install-cmd 的脚本，等同于在服务器上执行未知来源的 PHP 代码——风险极高，且多数团队没意识到。
为什么 production 下不能用 composer install 自动执行脚本
Composer 脚本（尤其是 post-install-cmd、post-update-cmd）默认以当前用户权限运行，而生产环境通常以 www-data 或 nginx 用户启动 Web 进程。一旦脚本中包含数据库迁移、文件写入、缓存清理等操作，就可能因权限越界或路径错误导致服务中断。
- 脚本内容不经过代码审查，
composer.json可被依赖包动态修改（例如通过插件或钩子） -
composer install在无--no-scripts时会强制执行所有声明的脚本，无法按需跳过 - 某些脚本依赖开发工具（如
phpunit、phpmetrics），这些不应出现在生产镜像中
composer install --no-scripts --no-dev 是生产部署的底线
这条命令不是“可选优化”，而是必须写进 CI/CD 流水线和 Dockerfile 的硬性约束。它确保：
- 不加载
require-dev中的包（如测试框架、静态分析工具） - 跳过所有
scripts字段定义的命令，避免意外执行 - 只还原
vendor/目录，保持最小攻击面
示例 Dockerfile 片段：
FROM php:8.2-fpm-alpine # ... 其他基础配置 COPY composer.json composer.lock ./ RUN composer install --no-scripts --no-dev --optimize-autoloader COPY . . # 后续手动触发必要操作（见下节）
哪些操作必须移出 Composer 脚本，改由部署流程显式控制
以下动作看似方便放在 post-install-cmd 里，但在生产中应剥离并独立管理：
-
php bin/console doctrine:migrations:migrate—— 数据库变更必须人工审核、分环境执行，不能随代码自动触发 -
php bin/console cache:warmup—— 应在容器启动前完成，且需指定--env=prod防止开发配置污染 -
rm -rf var/cache/*类清理操作 —— 容器是无状态的，缓存目录应在ENTRYPOINT中初始化，而非靠脚本擦除 -
chown -R www-data:www-data var/—— 权限应在构建阶段固化，或由容器运行时（如user:指令）控制，不靠运行时脚本干预
如果真要执行某条脚本，该怎么安全落地
唯一可接受的方式是：**明确调用、限定上下文、隔离权限**。
- 不写进
composer.json，改用独立 shell 脚本（如deploy-migrate.sh），并纳入版本控制与审批流程 - 执行前校验目标环境（例如检查
APP_ENV是否为prod） - 使用专用部署用户（非
root，也非www-data），并通过sudo -u www-data降权执行 - 所有数据库类操作必须加
--no-interaction --allow-no-migration等防护开关，避免卡住或误删
例如，在 Kubernetes Job 中执行迁移：
apiVersion: batch/v1
kind: Job
metadata:
name: doctrine-migrate
spec:
template:
spec:
restartPolicy: Never
containers:
- name: migrate
image: myapp:latest
command: ["/bin/sh", "-c"]
args: ["sudo -u www-data php bin/console doctrine:migrations:migrate --no-interaction"]
securityContext:
runAsUser: 1001
runAsGroup: 1001真正危险的从来不是“能不能做”，而是“谁在什么条件下、以什么权限、对什么数据做了什么”。Composer 脚本在生产里没有模糊地带——要么禁用，要么彻底收口。否则，一次 composer update 就可能让数据库表结构在凌晨三点悄悄消失。
