根本原因是终端能力检测失效：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 sysdef 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)替换
很多库（如
rich.print、click.echo、logging）不走原生sys.stdout.buffer或调用os.write。只 monkey patchbuiltins.print没用。
- 对
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 函数，大概率白忙。
