PHP调用n8n webhook触发成功需满足三要素：必须用POST方法、Content-Type为application/json、body为合法JSON字符串；n8n端Response Format不可设为None，否则PHP收到200即返回而实际流程未完成；字段名须字面量一致映射。
PHP 调用 n8n webhook 时如何确保触发成功
n8n 的 webhook 触发失败，绝大多数情况不是 n8n 配置错了，而是 PHP 发起的请求没满足它的“准入门槛”。n8n 默认只接受 POST 请求，且要求 Content-Type 为 application/json，同时 body 必须是合法 JSON 字符串——哪怕你只传一个空对象，也得是 {}，不能是空字符串或 null。
常见错误现象：400 Bad Request 或 n8n 日志里显示 Invalid JSON payload。这时候别急着改 n8n 设置，先检查 PHP 这边：
- 用
json_encode()显式编码数据，别直接拼字符串 - 手动设置
Content-Type: application/json请求头（cURL 需用curl_setopt($ch, CURLOPT_HTTPHEADER, [...])） - 确保
json_encode()返回非false，可用json_last_error()检查编码失败原因（比如中文未加JSON_UNESCAPED_UNICODE导致乱码进而解析失败） - 如果 PHP 使用
file_get_contents()+stream_context_create()，注意http选项里的content必须是字符串，不能是数组
n8n Webhook 节点的 Method 和 Response 选项怎么选
n8n 的 Webhook 节点有两个关键开关直接影响 PHP 调用逻辑：一个是 Response Format，另一个是 HTTP Method。它们不是“设了就行”，而是和 PHP 端的等待行为强绑定。
典型场景：PHP 需要等 n8n 执行完某个任务（比如发邮件、写数据库）再继续后续逻辑。这时必须：
立即学习“PHP免费学习笔记（深入）”；
-
HTTP Method设为POST（其他方法如GET不支持带 body，无法传参） -
Response Format设为First Entry或All Entries，不能选None——否则 n8n 会立即返回200 OK，但不等下游节点执行完，PHP 收到响应就以为完成了 - 若选
First Entry，n8n 只等第一个成功输出的节点；若流程中有条件分支或多个并行节点，建议用All Entries避免漏数据
反例：设成 None 后 PHP 收到 200 就往下走，但 n8n 实际还在跑 Slack 通知或 MySQL 写入，结果 PHP 认为“已处理”，用户却没收到消息。
PHP 传参字段名与 n8n $input.body 的映射关系
n8n 的 $input.body 是个原生 JavaScript 对象，它不自动做下划线转驼峰、不忽略大小写、也不过滤空格。PHP 传过来的字段名，必须字面量一致才能取到。
比如 PHP 用 json_encode(['user_id' => 123, 'is_active' => true]) 发送，n8n 里就得写 $input.body.user_id 和 $input.body.is_active，不能写 userId 或 USER_ID。
容易踩的坑：
- PHP 数组键含空格或特殊字符（如
'order date'），n8n 里必须用方括号语法：$input.body['order date'] - PHP 传了
null值，n8n 里对应字段就是null，不是空字符串或undefined，做条件判断时注意用=== null而非== false - 如果 PHP 用了
JSON_FORCE_OBJECT把索引数组转成对象，n8n 接收后仍是对象；但如果没加，而 PHP 数组是纯数字键（[1,2,3]），json_encode()会输出数组，n8n 中$input.body就是数组，此时$input.body.user_id会是undefined
调试时如何快速定位是 PHP 还是 n8n 的问题
两边都报错、日志都不够细，最有效的方法是“分段截断”：先绕过 PHP，用 curl 直接模拟请求，确认 n8n 能正常触发；再在 PHP 里打印原始请求体和响应头，看是否被中间件（如 Nginx、WAF）拦截或修改。
实操建议：
- 在终端跑：
curl -X POST http://your-n8n-url/webhook/xxx -H "Content-Type: application/json" -d '{"test":1}'，观察 n8n 日志是否出现Webhook received - PHP 中用
curl_getinfo($ch)查状态码和响应头，特别关注http_code和redirect_url（防 301 重定向丢失 body） - n8n 日志级别调到
debug（启动时加N8N_LOG_LEVEL=debug），它会在日志里打出完整的req.body和解析后的$input.body，比前端 UI 更可信 - 如果 n8n 日志里
req.body是空，但curl能通，基本锁定是 PHP 没发对 Content-Type 或 body 格式
真正麻烦的往往不是配置项本身，而是 HTTP 协议层的隐性约束——比如某些代理会静默丢弃非标准 header，或 PHP 的 allow_url_fopen 关闭导致 file_get_contents 失败却只报超时。这些细节不打日志根本看不到。
