proc_open双向交互需严格对齐管道描述符、流时序与关闭逻辑：0/1/2索引必须显式声明且模式匹配，写stdin后fflush，读stdout/stderr需非阻塞+stream_select超时监控，关闭须按stdin→stdout/stderr→proc_close顺序执行。
proc_open 能实现双向实时交互，但默认配置下几乎必然失败——根本原因不是 PHP 版本，而是管道描述符、流操作时序和关闭逻辑这三处没对齐。
proc_open 描述符数组必须显式声明 0/1/2 且模式匹配
漏掉任意一个索引，或写成 array(1 => ["pipe", "w"]) 这类稀疏数组，proc_open 就不会创建对应管道，后续读写直接 false 或阻塞。PHP 8.0 并未放宽这个约束，反而对资源管理更严格。
- stdin（索引 0）必须设为
["pipe", "r"]：PHP 往里写，子进程从这读 - stdout（索引 1）必须设为
["pipe", "w"]：子进程往里写，PHP 从这读 - stderr（索引 2）必须设为
["pipe", "w"]：同上，独立于 stdout - 调用后立刻检查返回值：
if (!is_resource($process)) { throw new RuntimeException('proc_open failed'); }，否则$pipes可能未定义
读写必须分时序 + 非阻塞 + 主动刷新
子进程 stdin 写入后不 fflush，很多命令（如 python -i、bash）会缓存输入；而 stdout/stderr 若用阻塞模式读，fgets 会卡死在 EOF 前——尤其当子进程还没输出第一行时。
- 对
$pipes[0]（stdin）写完后必须调用fflush($pipes[0]) - 对
$pipes[1]和$pipes[2]设置非阻塞：stream_set_blocking($pipes[1], false) - 读取时用循环 +
usleep(10000)避免空转耗 CPU，不要依赖单次fgets - 判断流结束不能只靠
feof，要配合stream_select检查可读性，否则可能永远等不到 EOF
关闭顺序错一环，整个交互就乱套
proc_open 的管道是“有状态”的：子进程是否还在读 stdin、是否已 flush stdout，都影响你能否安全关闭。PHP 8.0 下资源回收更激进，提前关流容易触发 warning 或丢数据。
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
立即学习“PHP免费学习笔记（深入）”；
- 先关闭
$pipes[0]（stdin），告诉子进程“输入结束了” - 再循环读尽
$pipes[1]和$pipes[2]，直到stream_get_contents返回空且feof为真 - 最后才调用
proc_close($process)，它会等子进程真正退出并返回 exit code - 绝对不要在读 stdout 前就
fclose($pipes[1])，这会导致子进程 SIGPIPE 中断
stream_set_timeout 对 stdout 有效，但 stderr 不吃这套
想防命令卡死？给 stdout 流设超时是可行的，但 stderr 默认不走同一套机制——stream_set_timeout 对 $pipes[2] 无效，它仍可能无限阻塞。真要超时控制，得自己用 stream_select 统一监控所有可读流。
- 正确做法：把
$pipes[1]和$pipes[2]都加入stream_select的读集合，设统一 timeout - 读到数据就处理，超时就调用
proc_terminate($process)强杀 - 注意
proc_terminate后仍要调proc_close清理资源，否则子进程变僵尸 - 别信
pcntl_alarm，PHP-FPM 环境下信号处理不可靠，stream_select是唯一稳的路
最易被忽略的是：子进程输出换行符可能是 \r\n 或 \n，而 fgets 默认按 \n 切割，导致最后一行读不全；还有编码问题，比如子进程输出 UTF-8 带 BOM，PHP 侧不清理就直接 echo 会破坏 JSON 格式。这些细节不处理，交互看起来“通了”，实际数据早就歪了。
