根本原因是终端能力检测失效：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
<p>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"
)</p><h1>若需 emoji，再拼接；否则用纯文本 fallback</h1><pre class="brush:php;toolbar:false;">args = [str(a).replace("✅", "OK").replace("❌", "FAIL") for a in args] if not use_emoji else args
print(*args, **kwargs)
当用户提及 GitHub URL，或要求分析、审查、探索或理解任意 GitHub 项目、仓库或代码库时，请使用此技能。触发条件包括以下短语：“分析这个项目”、“看看这个仓库”、“analyze this repo”、“what does this project do”，或消息中包含任何 github.com URL。
替换 print 前必须拦截所有第三方库的输出路径
很多库（如 rich.print、click.echo、logging）不走原生 print，直接写 sys.stdout.buffer 或调用 os.write。只 monkey patch builtins.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 函数，大概率白忙。
