composer install --no-scripts --no-plugins是唯一官方支持的禁用所有脚本及插件钩子的方式，可防止post-install-cmd等恶意执行，确保生产与CI环境安全；两者必须同时使用，缺一不可。
直接禁用脚本执行：--no-scripts 是最有效的第一道防线
只要不加 --no-scripts，Composer 就会默认运行 post-install-cmd、post-update-cmd 等所有钩子——哪怕你只装一个包，恶意脚本也可能悄悄执行 shell_exec() 或写入 webshell。
生产部署、CI 构建、审计陌生项目时，必须强制加上：composer install --no-scripts --no-pluginscomposer update --no-scripts --no-plugins
注意两点：
• --no-plugins 必须和 --no-scripts 同时用，否则某些插件仍可能绕过脚本禁用逻辑触发执行
• 它不影响 vendor/autoload.php 生成，那是 Composer 自身流程，不是脚本
从源头掐断：清空 composer.json 中的 scripts 字段
命令行参数容易漏，尤其本地开发或 CI 配置不一致时。更可靠的做法是在项目级让脚本“根本不存在”：
把 composer.json 的 scripts 设为空数组：
"scripts": {<br> "post-install-cmd": [],<br> "post-update-cmd": [],<br> "pre-autoload-dump": [],<br> "post-autoload-dump": []<br>}这样即使忘了加
--no-scripts，Composer 也无事可做。但要注意：
• 不要用
null 或 false，Composer 会忽略并回退到默认行为• Laravel 类框架依赖
post-autoload-dump 生成优化类映射，清空后需手动运行 composer dump-autoload --optimize
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
警惕依赖来源：私有仓库和拼写错误包是高危入口
脚本本身未必恶意，但执行环境被污染就危险了。常见风险点：
• 运行 composer config repositories 查所有注册源，删掉未审核的 type: "composer" 私有源——很多自建 Satis 不支持 provider 签名，极易被掉包
• 检查 composer.lock 中每个包的 dist.shasum 是否存在且未被篡改，这是验证下载内容一致性的唯一可靠依据
• 避免 "^1.0" 这类模糊版本约束，攻击者可能在 1.0.x 后续小版本中注入恶意脚本
• 不要信任 dev-master 或 fork 仓库，它们的 composer.json 可随时被改写
签名验证与权限收紧：让恶意代码即使进来也跑不动
Composer 2.5+ 默认启用 Packagist 签名验证，但需确认是否真生效：
运行 composer show --security，输出含 Signature verification: enabled 才算到位
同时必须：
• 禁用 root 权限运行 Composer，普通用户权限足够，也限制了脚本能干的事
• Web 服务器禁止访问 /vendor/ 目录（Nginx 加 location ^~ /vendor/ { return 403; }）
• 生产环境永远不跑 composer update，所有变更必须在 CI 中生成新 composer.lock 再同步
最常被忽略的是：很多人以为加了私有源就更安全，其实只是扩大了攻击面——一个配置错误的私有源，就能让整个依赖链失效。
