答案是Python在Docker非TTY环境下启用全缓冲模式导致输出滞留内存；需设置ENV PYTHONUNBUFFERED=1使stdout实时写入，确保docker logs可见所有print()和logging输出。
日志“消失”不是容器坏了，是 Python 默认把 print() 和 logging 输出卡在内存里没刷出来——只要让 stdout 实时写入，docker logs 就能立刻看到。
为什么 docker logs 看不到 print() 输出？
Python 在非终端环境（比如 Docker 后台容器）下自动启用全缓冲模式：所有输出先攒在内存缓冲区，等满、退出或手动 flush() 才真正写出去。而 docker logs 只能读到已写入的标准流，缓冲区里的内容它看不见。
- 本地终端运行时有 TTY，
print()遇换行就自动刷新；Docker 默认不分配 TTY，所以不刷 -
docker run -it临时加 TTY 能缓解，但不推荐用于生产（会干扰信号处理） - 哪怕服务已响应 gRPC 请求、HTTP 健康检查成功，日志仍可能“静默”——这不是功能问题，是 I/O 流没打通
最稳妥的修复方式：在 Dockerfile 中设 PYTHONUNBUFFERED=1
这是零代码修改、一次生效、覆盖全部 Python 输出（print()、logging、异常 traceback）的方案。
- 放在
FROM之后、CMD之前，确保被所有后续指令继承 - 等效于启动时加
python -u，但更可靠（避免ENTRYPOINT脚本绕过参数） - 不要写成
ENV PYTHONUNBUFFERED True或1.0——必须是字符串"1"，否则 Python 不识别
FROM python:3.11-slim ENV PYTHONUNBUFFERED=1 WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD ["python", "server.py"]
如果必须用 shell 启动脚本，注意输出链别断掉
很多项目用 ENTRYPOINT ["./start.sh"] 包一层，但容易意外切断 stdout/stderr 流向。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
- 确保脚本最后用
exec "$@"（不是$@ &或后台启动），否则 Python 进程变成子进程，它的 stdout 会被 shell 截断 - 避免在脚本里重定向
> /dev/null或2>&1，除非你明确接管日志并重新输出到/proc/1/fd/1 - 测试方法：进容器执行
ps aux | grep python，确认 Python 是 PID 1；如果不是，说明启动链出问题
logging 模块也要配合，否则仍可能延迟
PYTHONUNBUFFERED=1 能解决大部分问题，但如果你用了 logging 且配置了文件 handler 或自定义 handler，缓冲行为可能不受影响。
- 确保
logging.basicConfig()没设handlers=[FileHandler(...)]——这会让日志写文件而非 stdout - 显式添加
StreamHandler()并设stream=sys.stdout，再配formatter - 避免多次调用
basicConfig()：第二次调用默认无效（force=True参数可覆盖，但不如一开始就配好）
import logging import sys <p>logging.basicConfig( level=logging.INFO, format="%(asctime)s - %(levelname)s - %(message)s", handlers=[logging.StreamHandler(sys.stdout)] )
真正容易被忽略的点是：缓冲问题只影响输出可见性，不影响程序逻辑。哪怕 docker logs 空着，服务也可能完全正常——所以别只盯着日志有没有，先确认进程是否真在跑、端口是否真在监听。
