为何docker run -t会将stderr重定向至stdout？如何分配伪TTY并保留stderr独立？

当你使用docker run添加-t/--tty参数时，Docker会为容器分配一个伪终端（PTY），而伪终端本质上只有一个双向数据流通道：容器内部的stdout和stderr默认都会绑定到PTY的从设备，两类输出会被合并为同一个流返回给Docker客户端，客户端会将所有从PTY拿到的输出统一写入到宿主机的stdout，所以就出现了stderr被"重定向"到stdout的现象，无法再通过标准流分离两类输出。

而通常CLI工具会自动检测当前输出是否为TTY设备，如果是就默认开启ANSI彩色输出，非TTY场景（比如重定向到文件、管道）默认关闭颜色输出，这也是你依赖-t参数的核心原因。

完全可以在不使用-t参数的前提下同时满足「保留stdout/stderr独立性」和「输出带颜色」的需求，该场景下的最优方案如下：

• 给容器内运行的命令主动开启强制彩色输出，不需要依赖TTY检测：
  • 大部分通用CLI工具都提供强制彩色参数，比如ls用--color=always，grep用--color=always
  • 编程语言/框架类工具大多支持通过环境变量强制开颜色，比如前端Node.js生态的工具设置FORCE_COLOR=1，Python工具设置PY_COLORS=1，也可以统一传递TERM=xterm-256color环境变量兼容更多场景
• 对应你CI场景的需求，示例用法如下：

# 替换对应工具的强制颜色参数/环境变量即可，不需要加`-t`参数
docker run -e FORCE_COLOR=1 your-image my-command > out.json

该写法下，my-command的stdout会正常写入out.json，stderr的彩色警告、错误信息仍然会独立输出，可被日志采集器正常捕获展示颜色。

如果确实遇到无强制颜色参数的特殊老旧工具，也可以使用unbuffer、script等用户空间的伪终端工具在容器内部模拟TTY，同时手动分离流，不过这类场景非常少见。

内容的提问来源于stack exchange，提问作者Martin Jambon