STDIN、STDOUT、STDERR 是 PHP CLI 预定义文件句柄，无需 fopen 手动打开；STDIN 只读、逐行读取推荐 fgets(STDIN) 并 trim()；STDOUT/STDERR 只写，后者不被管道重定向影响；Web 环境中未定义。
CLI环境下直接读写STDIN/STDOUT/STDERR
在命令行（CLI）中，STDIN、STDOUT、STDERR 是预打开的资源常量，无需 fopen('php://stdin', 'r') 手动打开——手动打开反而多余，还可能干扰流状态。
常见错误是混用 fgets(STDIN) 和 fgets(fopen('php://stdin', 'r'))，后者会创建新句柄，但 PHP CLI 的 STDIN 本身已缓冲，重复打开容易丢数据或阻塞。
-
fgets(STDIN)是最安全的逐行读取方式；trim()必须显式调用，否则含换行符 - 向
STDOUT写入等价于echo或fwrite(STDOUT, $str)，但后者适合需要控制写入字节数的场景 -
STDERR专用于报错输出，不会被管道重定向影响（比如php script.php > out.txt时，STDERR仍打印到终端） - 这些常量在 Web SAPI（如 Apache/FPM）中未定义，直接使用会触发
Notice: Undefined constant
php://input 只在特定 POST 场景下可用
php://input 是只读流，用于读取原始请求体，但它在 enctype="multipart/form-data" 的表单提交中完全失效——此时 PHP 已将 body 解析为 $_FILES 和 $_POST，php://input 返回空字符串。
它真正起作用的场景是：前端发 Content-Type: application/json 或 text/plain 的 POST 请求，且未启用 enable_post_data_reading=Off（默认开启）。
立即学习“PHP免费学习笔记（深入）”；
- 读取前建议先检查
isset($_SERVER['CONTENT_TYPE'])和是否为multipart类型 -
file_get_contents('php://input')最常用，但大请求体可能吃内存；小数据用fread(fopen('php://input', 'r'), 1024)更可控 - 不能与
$_POST混用：一旦 PHP 解析了 POST 数据（如访问了$_POST），php://input就不可再读
php://memory 与 php://temp 的内存/磁盘策略差异
两者都提供内存中可读写的流，但行为关键区别在于容量超限时的 fallback 策略：php://memory 强制全程驻留内存，超限直接失败；php://temp 默认 2MB 后自动转存临时文件（路径由 sys_get_temp_dir() 决定）。
这个差异直接影响进程稳定性：在低内存容器或处理大日志片段时，硬用 php://memory 可能触发 OOM；而 php://temp 虽安全，但磁盘 I/O 带来延迟。
- 显式指定内存上限：
php://temp/maxmemory:524288（512KB），超限即落盘 - 强制禁用落盘（等效
php://memory）：php://temp/maxmemory:-1 - symfony/process 默认用
php://temp/maxmemory:1048576（1MB），就是为平衡内存与可靠性
向子进程写入输入时 setInputStream 的陷阱
用 symfony/process 向子进程传输入，setInput() 接收字符串、资源或 InputStream 实例，但最容易出问题的是资源类型。
例如用 fopen('php://memory', 'r+') 写入后忘记 rewind()，子进程读到的就是空流——因为指针停在末尾。
- 字符串输入最简单，但无法动态追加；适合已知全部输入内容的场景
- 流资源必须确保可读（
'r'或'r+'模式）、指针位于开头（rewind()或fseek($fp, 0)） -
InputStream类支持运行中写入，但需注意：子进程启动后才开始写，否则缓冲区可能提前关闭 - 避免用
php://stdin直接传给子进程——它代表当前 PHP 进程的 stdin，不是你构造的数据源
php://input 是 HTTP 请求体的入口，STDIN 是 CLI 进程的入口，二者绝不互通；又比如 php://temp 的 maxmemory 参数不写单位、只认字节，写成 maxmemory:1M 会静默失效。 
