phpEnv 中 posix 和 pcntl 扩展默认关闭，需手动启用并配置 declare(ticks=1)；信号处理需设标志位而非 exit；容器中须确保 PHP 进程为 PID 1 或使用 tini 透传信号。
phpEnv 里 posix 扩展默认是关闭的
phpEnv 编译 PHP 时默认不启用 posix 和 pcntl，哪怕你选了「CLI 模式支持」，这两个扩展也不会自动加载。没有它们，posix_kill、pcntl_signal 这类函数直接报 Call to undefined function 错误，信号处理无从谈起。
必须手动开启：
- 进入 phpEnv 安装目录（比如
/opt/phpenv），运行./phpenv install --reinstall --with-posix --with-pcntl - 或编辑当前 PHP 版本的配置文件（路径类似
~/.phpenv/versions/8.3.0/etc/php.ini），确认已存在extension=posix和extension=pcntl两行（不是注释掉的状态） - 改完后重启 CLI 环境：
phpenv rehash，再用php -m | grep -E "posix|pcntl"验证是否在列表中
pcntl_signal 不生效？检查 declare(ticks=1)
即使扩展开了，pcntl_signal 注册的回调也大概率不会被调用——因为 PHP 默认不主动轮询信号队列。必须配合 declare(ticks=1) 让解释器每执行一条语句就调用一次 pcntl_signal_dispatch()。
常见错误写法：pcntl_signal(SIGTERM, fn() => $should_exit = true); while (true) { // do work }
这段代码里信号永远不会触发，因为没声明 ticks，也没手动调用 pcntl_signal_dispatch()。
- 正确结构是：在 while 循环外加
declare(ticks=1);，且确保循环体里有可中断的语句（比如sleep(1)或usleep(10000)） - 不要在信号回调里直接
exit()或die()，会导致资源清理失败；应设全局标志位（如$should_exit），主循环检测它 - 若主循环里全是密集计算（无 sleep/usleep），需在关键位置手动插入
pcntl_signal_dispatch()
向自己发信号测试：用 posix_kill(0, SIGUSR1)
调试信号处理逻辑时，别依赖外部 kill 命令——容易混淆进程 PID，尤其在容器或 phpEnv 多版本共存环境下。最稳妥的方式是让脚本自己给自己发信号：
立即学习“PHP免费学习笔记（深入）”；
posix_kill(0, SIGUSR1); // 向当前进程组所有进程发 SIGUSR1 // 或更精准地： posix_kill(posix_getpid(), SIGUSR1); // 只发给当前进程
注意：posix_kill(0, ...) 的 0 表示「当前进程组」，不是「PID 为 0 的进程」；它比硬写 PID 更可靠，避免因子进程 fork 后 PID 变化导致测试失败。
- 测试前先确认信号常量已定义：
var_dump(SIGUSR1);，若报错说明posix扩展未生效 -
SIGUSR1和SIGUSR2是用户自定义信号，适合开发阶段验证逻辑，不影响系统行为 - 避免用
SIGKILL（9）或SIGSTOP（19）做测试——它们无法被捕获或忽略
Docker 容器里收不到 SIGTERM？检查 init 进程和信号透传
phpEnv 常用于本地模拟容器环境，但真实容器中信号处理失败的主因往往不是 PHP 代码问题，而是 Docker 层面没把信号透传给 PHP 进程：
- 如果容器启动命令是
php worker.php（即 PHP 进程是 PID 1），Docker 发来的SIGTERM会被内核直接终止进程，根本进不了 PHP 的pcntl_signal回调 - 解决方案：用
tini或docker-init作为 PID 1，再由它转发信号；或改用exec php worker.php（Bash 的 exec 会替换自身进程，让 PHP 成为 PID 1，但仍能接收信号） - 验证方式：在容器内运行
ps -o pid,ppid,comm，确认 PHP 进程的 PPID 是 1（即它确实是 init 进程），否则信号可能被中间 shell 吞掉
这个环节最容易被忽略——PHP 代码写得再规范，信号到不了进程，一切白搭。
