生产环境严禁直接运行composer install，因其必然引发权限混乱、PHP版本不匹配和敏感文件暴露三类硬伤；必须在构建阶段执行--no-dev --optimize-autoloader --classmap-authoritative --no-interaction --prefer-dist，同步已清理vendor目录，并通过Nginx硬隔离/vendor/及.env等路径。
生产环境为什么不能直接运行 composer install
因为这不是“不够安全”，而是根本违反部署边界——它会触发三类不可控风险：权限混乱（file_put_contents(./composer.json): failed to open stream: Permission denied）、PHP 版本不匹配（Your platform does not meet the requirements）、敏感文件暴露（.env、composer.json 被 Nginx 错配后直供下载）。这些错误排查成本远高于预防成本。
真正安全的做法是：所有 composer install 必须在构建阶段完成，生产机只同步已构建好的 vendor/ 目录，且禁止部署用户拥有写 vendor/ 或 composer.lock 的权限。
- CI/CD 流水线中执行
composer install --no-dev --optimize-autoloader --classmap-authoritative --no-interaction --prefer-dist，缺一不可 - 安装后立即清理高风险路径：
vendor/bin/、vendor/**/tests/、vendor/**/.git、vendor/composer/installed.json - 验证
vendor/autoload.php中是否含'classmap-authoritative' => true，并确认vendor/composer/autoload_classmap.php非空
composer.lock 不是配置文件，是可执行快照
composer.lock 不是缓存，也不是“建议性锁定”，它是 Composer 安装行为的唯一指令源。只要它存在，composer install 就完全忽略 composer.json 里的 ^ 或 ~ 版本约束，只按里面写的精确版本、dist.sha256、source.reference 和完整依赖树执行。
关键字段就这几个：packages（生产依赖）、packages-dev（开发依赖）、每个包下的 version、dist.url 和 dist.sha256。删掉它，composer install 就会退化成一次不受控的 composer update，哪怕你只是多敲了一个空格导致 content-hash 不匹配，也会触发警告甚至失败。
-
composer install报No lock file present，不是提示你“该生成一个”，而是明确拒绝执行 - Git 合并冲突时绝不能手动编辑
composer.lock—— 它的字段顺序、嵌套层级、空格都参与哈希计算 - 正确解法：先确保
composer.json无冲突，删掉当前composer.lock，再跑composer update --lock（输出应为0 installs, 0 updates, 0 removals）
Nginx 必须硬隔离 vendor 和敏感文件路径
即使 vendor/ 已安全部署，Nginx 配置不当仍会让攻击者通过 URL 直接下载 .env、composer.json 或遍历整个 /vendor/ 目录。这不是假设风险，而是真实攻击链起点。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
必须在 server 块中添加以下规则，并用 curl -I http://yoursite.com/composer.json 验证返回 403：
location ~ /\.(env|json|lock|git|hg|svn)$ { deny all; }location ^~ /vendor/ { return 403; }location = /composer.json { return 403; }
注意：^~ /vendor/ 优先级高于正则匹配，能防止 /vendor/some-package/.git/config 这类路径绕过。
如何防止恶意包混入生产环境
提交了 composer.lock 也不等于绝对安全——它只锁版本和哈希，不锁来源和执行逻辑。攻击者可通过控制作者账号，在不改版本号的前提下把 dist.url 指向恶意 ZIP，或往 scripts 里塞 post-install-cmd。
分层堵漏才是关键：
- 在
composer.json中显式设"allow-plugins": {"*": false}，只白名单授权必要插件（如"composer/installers": true） - 禁用自定义仓库：
repositories字段必须为空或仅含{"type":"composer","url":"https://packagist.org"} - CI 中加
composer validate --strict检查scripts异常，加composer audit --format=json | jq '.advisories | length'让漏洞数 >0 时直接失败 - 部署时强制用
--no-dev --prefer-dist：前者跳过开发依赖（常含高危插件），后者绕过post-install-cmd执行
真正容易被忽略的是：vendor/bin 下残留的 phpunit、phpcs 并非由 --no-dev 删除，而是其他包声明的 bin 脚本。它们物理存在，但不应被 Web 可访问 —— 必须配合 "bin-dir": "bin" 配置挪出 Web 根目录，并在部署脚本中清理无关符号链接。
