Composer脚本如何调用外部API？自动化部署中的高级玩法-composer-PHP中文网

composer脚本无法直接调用api，需通过shell命令或php脚本（如curl_init、file_get_contents）封装实现；敏感信息须通过环境变量注入，禁止硬编码；自定义钩子名非内置，需显式调用；http失败必须返回非零退出码以保障ci/cd可靠性。

composer脚本如何调用外部api？自动化部署中的高级玩法

Composer脚本里不能直接“调用API”，得靠shell或PHP封装

Composer scripts 本身不提供 HTTP 客户端能力，所谓“调用外部 API”，本质是让 curl、wget 或 PHP 脚本去发请求。硬写 "notify:slack": "curl -X POST https://hooks.slack.com/... -d '{\"text\":\"deploy done\"}'" 看似可行，但会立刻暴露三个问题：敏感 Token 明文、JSON 引号嵌套混乱、错误时无反馈。

推荐做法是把逻辑抽到独立 PHP 文件中，利用 Composer 自动加载和环境变量注入能力：

scripts/notify.php 里用 file_get_contents() 或 curl_init() 发请求，通过 getenv('SLACK_WEBHOOK') 读 Token
在 composer.json 中注册："notify:slack": "@php scripts/notify.php slack"
调用前确保 SLACK_WEBHOOK 已设为环境变量（CI/CD 中配置，本地用 .env + vizual/vizual-dotenv 加载）

post-deploy 钩子在远程服务器上根本不会触发

很多人以为在 composer.json 里写了 "post-deploy": "curl ..."，然后跑 ssh user@prod 'cd /app && composer install' 就能自动通知——实际不会。因为 post-deploy 是自定义脚本名，不是 Composer 内置钩子；而 post-install-cmd 默认只在 --dev 模式下启用，生产环境 composer install --no-dev 后它压根不执行。

正确姿势是显式调用：

部署流程末尾加一步：ssh user@prod 'cd /app && composer run-script notify:slack --no-dev'
或者在远程执行的 PHP 脚本里主动触发，比如 scripts/deploy-finish.php 最后调用 file_get_contents($webhookUrl)
别依赖任何未显式声明的钩子名，pre-*/post-* 前缀只是命名习惯，不是语法糖

HTTP 请求失败时，脚本必须退出非零码，否则 CI/CD 会误判成功

默认情况下，curl 即使返回 400/500 状态码，只要网络通、命令没崩，退出码仍是 0。这会导致部署流水线继续往下走，掩盖真实故障。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

解决方法分两层：

Shell 层：用 curl -f（--fail）参数，遇到 4xx/5xx 自动返回非零退出码
PHP 层：检查 http_response_code() 或响应 body 是否含 error 字段，明确 exit(1)
在 CI/CD 脚本中加判断：if ! composer run-script notify:slack; then echo "Notify failed"; exit 1; fi

Webhook URL 和请求体千万别硬编码在 composer.json 里

composer.json 是要提交进 Git 的，把 https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX 直接塞进 scripts 字段，等于公开泄露凭证。更糟的是，不同环境（staging/prod）该打不同 webhook，硬编码会让脚本失去环境适配能力。

安全且可维护的做法：

URL 和 payload 结构通过环境变量注入，例如：SLACK_WEBHOOK_STAGING、SLACK_WEBHOOK_PROD
PHP 脚本里用 $env = $_SERVER['APP_ENV'] ?? 'prod'; $url = getenv("SLACK_WEBHOOK_".strtoupper($env));
payload 模板存在 resources/notify/slack-template.json，用 str_replace() 注入动态字段（如 commit hash、branch name）

真正容易被忽略的点是：很多团队在 PHP 脚本里用 $_ENV 读变量，但默认 PHP 不填充它——得用 putenv() 或先 getenv()，否则永远读不到。