根本原因是终端能力检测失效：Python 的 sys.stdout.isatty() 在 CI、Docker、systemd 或重定向场景下返回 False，但 rich、click 等库仍强行输出 emoji 或 ANSI 色彩，导致乱码。

为什么 print 在非交互环境会乱码或显示异常 emoji

根本原因是终端能力检测失效：Python 的 sys.stdout.isatty() 在 CI、Docker、systemd 或重定向场景下返回 False，但某些库（如 rich、click 或自定义美化 print）仍强行输出 emoji 或 ANSI 色彩。这不是 print 本身的问题，而是上层封装未适配输出目标。

用 os.environ.get("TERM") 和 sys.stdout.isatty() 双重判断是否启用 emoji

单靠 isatty() 不可靠（例如 tmux 内的伪终端、某些容器中它为 True 但实际不支持 emoji）。应结合环境变量和能力探测：

• sys.stdout.isatty() == False → 直接禁用 emoji，不犹豫
• os.environ.get("TERM") in ("dumb", "unknown", None) → 视为哑终端，跳过所有富文本
• CI 环境（os.environ.get("CI") == "true"）强制降级，无需试探

示例逻辑：

import os
import sys
def safe_print(*args, **kwargs):
use_emoji = (
sys.stdout.isatty()
and os.environ.get("TERM") not in ("dumb", "unknown")
and os.environ.get("CI") != "true"
)
若需 emoji，再拼接；否则用纯文本 fallback
args = [str(a).replace("✅", "OK").replace("❌", "FAIL") for a in args] if not use_emoji else args
print(*args, **kwargs)

替换 print 前必须拦截所有第三方库的输出路径
很多库（如 rich.print、click.echo、logging）不走原生 print，直接写 sys.stdout.buffer 或调用 os.write。只 monkey patch builtins.print 没用。
									文心大模型
百度飞桨-文心大模型 ERNIE 3.0 文本理解与创作

对 rich：初始化时传 Console(force_terminal=False, emoji=False, highlight=False)

对 click：设环境变量 NO_COLOR=1，或调用前执行 click.disable_unicode_literals()

对 logging：避免在 Formatter.format 中硬编码 emoji；改用动态字段，如 %(status_emoji)s，并在 handler 中根据环境填充空字符串

CI/CD 中最稳妥的全局降级方式：启动时注入环境变量
比代码里层层判断更可靠的是从运行时源头控制。几乎所有主流 CI（GitHub Actions、GitLab CI、Jenkins）都预设了 CI=true，且多数日志系统识别 NO_COLOR、FORCE_COLOR=0。

在 entrypoint 或启动脚本开头统一设置：export NO_COLOR=1 FORCE_COLOR=0 PYTHONIOENCODING=utf-8

Docker 运行时加参数：-e NO_COLOR=1 -e CI=true

systemd service 文件中写入：Environment=NO_COLOR=1 CI=true


这样连 pip install、pytest 自带的进度条和符号都会自动退化为 ASCII，不用动一行业务代码。
真正容易被忽略的点是：emoji 降级不是“要不要显示”，而是“谁在决定要不要显示”——你得同时管住自己的代码、依赖库、运行时环境三者，缺一不可。只改 print 函数，大概率白忙。