pcntl_signal注册后需主动调用pcntl_signal_dispatch()或启用declare(ticks=1)才能触发，否则信号被忽略；回调中仅允许赋值、syslog等安全操作，禁止echo、exit等危险行为。
pcntl_signal 不是注册完就自动执行的函数，它只是把回调“记下来”。真正让信号生效，得靠你主动调用 pcntl_signal_dispatch() 或启用 declare(ticks=1) —— 否则 Ctrl+C 按下去，进程照常退出，什么都不会发生。
为什么 pcntl_signal 注册了却没反应？
常见现象：写了 pcntl_signal(SIGINT, $handler)，运行脚本后按 Ctrl+C，程序直接退出，$handler 一毛没执行。
- 根本原因：PHP 不像 C 那样在内核中断上下文中立即调用信号处理函数；它靠用户态轮询来“模拟”信号触发
- 没加
declare(ticks = 1)，且主循环里又没手动调pcntl_signal_dispatch()→ 信号永远卡在队列里，没人去取 -
pcntl_signal第三个参数默认为true（重启系统调用），但 CLI 脚本里多数情况不需要，设false更稳 - PHP 7.1+ 可用
pcntl_async_signals(true)替代 ticks，但它在容器或非标准 SAPI 下可能失效，不建议盲目切换
pcntl_signal_dispatch() 必须放在哪里？
长期运行的 CLI 脚本（比如消费者、守护进程）必须在主循环末尾显式调用它，不能依赖 declare(ticks=1) 自动触发 —— 否则性能损耗大，且容易漏信号。
- 推荐写法：
while (true) { // 处理业务逻辑，比如消费一条消息 consume_message(); // 关键：每次循环结束前检查并分发信号 pcntl_signal_dispatch(); // 避免空转占满 CPU，加个 sleep usleep(10000); } - 不要把它塞进
sleep()里面 ——sleep()是阻塞调用，期间信号来了也收不到，直到 sleep 返回才可能 dispatch - 如果业务逻辑本身耗时长（比如一次
file_get_contents超过 5 秒），要考虑拆成小步 + 中间插pcntl_signal_dispatch()，否则信号响应延迟严重
信号处理函数里能干啥？不能干啥？
信号回调不是普通函数，它运行在“伪异步”上下文，只能做极有限的安全操作。越界就会静默失败、崩溃，或留下脏数据。
- ✅ 安全操作：给全局变量赋值（如
$should_exit = true）、调用syslog()（POSIX 系统）、pcntl_alarm()、posix_kill() - ❌ 绝对禁止：
echo、print、file_put_contents()、exit()、die()、PDO 操作、任何涉及 PHP 内存管理或输出缓冲的动作 - 典型翻车现场：在 handler 里写日志文件 → 进程 segfault；调
exit()→ 主循环没机会清理资源，连接未关闭、临时文件残留 - 正确做法：设标志位，主循环检测到
$should_exit后，再执行清理、关闭连接、提交事务等收尾动作
Docker 容器中 SIGTERM 怎么优雅退出？
容器收到 SIGTERM 后只有 10 秒窗口，硬杀会丢消息、留脏数据。关键不是“立刻退出”，而是“控制退出节奏”。
立即学习“PHP免费学习笔记（深入）”；
- 必须监听
SIGTERM（Docker 默认发送的终止信号），不是SIGINT（那是 Ctrl+C） - handler 里只做一件事：
$graceful_shutdown_requested = true - 主循环中检测该标志后，停止拉新消息，但继续处理已取出的那条（哪怕要 9 秒），处理完再
exit(0) - 别忘了同时监听
SIGCHLD并调pcntl_waitpid(-1, $status, WNOHANG)回收子进程，否则僵尸进程堆积会导致容器无法终止 - 测试时用
kill -TERM $(pidof php)，别用kill -9—— 它绕过所有信号处理逻辑
echo，就可能让整个守护进程不可预测地崩掉。 
