触发器不能直接调用外部接口，因其设计上禁止阻塞型网络I/O；必须通过写入outbox表、LISTEN/NOTIFY或CDC工具异步解耦，由外围服务完成HTTP调用。
触发器里直接调用外部接口？不行，得绕道
SQL 标准触发器（比如 MySQL、PostgreSQL、SQL Server 的原生 TRIGGER）**完全不支持发起 HTTP 请求或执行系统命令**。这不是权限问题，是设计限制：触发器必须在事务上下文中快速完成，而网络 I/O 是阻塞、不可控、不可回滚的。硬要“调用外部接口”，会卡死事务、拖垮性能，甚至导致死锁或数据不一致。
可行路径只有一条：把「调用外部服务」这件事，从触发器内部移出来，交给外围程序承接。但用户真正需要的，往往是「数据一变，立刻通知下游」——所以重点不是“能不能在 trigger 里写 curl”，而是“怎么安全可靠地链路打通”。
PostgreSQL + PL/Python / PL/Perl 实现 UDF 调用 HTTP？危险，慎用
PostgreSQL 允许用 PL/Python 或 PL/Perl 写函数发起 HTTP 请求，再让触发器调用它。听起来像解法，实际埋雷：
- HTTP 调用失败（超时、网络断、下游挂）会导致整个
INSERT/UPDATE事务回滚——业务可能根本不想因通知失败丢数据 - Python 的
requests在数据库进程里运行，容易泄漏连接、耗尽 socket、引发内存碎片 - 多数生产环境禁用非安全语言插件（
shared_preload_libraries需重启，plpythonu默认关闭），上线前就得被 DBA 拦下 - 无法做重试、降级、熔断——而这些恰恰是外部调用最需要的
示例（仅说明风险，不推荐部署）：
CREATE OR REPLACE FUNCTION notify_webhook() RETURNS TRIGGER AS $$
import requests
requests.post("https://api.example.com/event", json={"table": TG_TABLE_NAME, "id": NEW.id})
return NEW
$$ LANGUAGE plpythonu;
真正落地的方案：触发器只写消息，由独立服务消费
核心思路：触发器不碰网络，只做最轻量的事——往一个地方“记一笔”。后续异步处理交给更合适的地方。
常用组合：
-
写入专用表：建一张
outbox表，字段含event_type、payload JSONB、created_at、status；触发器只做INSERT INTO outbox (...) VALUES (...) -
发到数据库内置队列：PostgreSQL 可用
LISTEN/NOTIFY，MySQL 8.0+ 可用EVENT+ 表轮询，SQL Server 用Service Broker - 对接外部消息中间件：通过 CDC 工具（如 Debezium、Canal）捕获 binlog / wal，投递到 Kafka / RabbitMQ，再由消费者服务调用外部接口
优势明显：触发器毫秒级返回；失败不影响主流程；重试、限流、监控全在应用层控制；DB 不承担业务逻辑。
MySQL 触发器 + UDF 调用外部服务？基本走不通
MySQL 的 CREATE FUNCTION UDF 必须用 C 编写、编译成 so/dll，且只能调用纯计算类逻辑。想在 UDF 里开 socket、发 HTTP？不仅极难实现，还会让 mysqld 进程不稳定——官方明确不支持、社区也极少维护这类扩展。
常见报错包括：ERROR 1126 (HY000): Can't open shared library 'http_udf.so'、mysqld crashes on SELECT。即使勉强跑通，升级 MySQL 版本或打补丁后大概率失效。
替代做法只有两个现实选择：
- 用
mysql-binlog-connector或Maxwell抓变更，推送到消息队列 - 在应用层监听关键表变更（比如 ORM 的 post_save hook），统一处理外发逻辑
别在数据库里造轮子。触发器的职责就该是校验、派生字段、维护简单衍生表——跨系统通信这事，交给 Go/Python/Java 写的服务更稳、更可测、更好查问题。
