Python gRPC 服务在 Docker 中运行时 print() 日志无法通过 docker logs 查看，根本原因是标准输出被缓冲；设置 PYTHONUNBUFFERED=1 环境变量可强制实时刷新 stdout/stderr。
python grpc 服务在 docker 中运行时 `print()` 日志无法通过 `docker logs` 查看，根本原因是标准输出被缓冲；设置 `pythonunbuffered=1` 环境变量可强制实时刷新 stdout/stderr。
在容器化部署 Python gRPC 服务时，一个常见但容易被忽视的问题是：服务进程明明正常启动并响应请求（如 Node.js 客户端可成功调用），但 docker logs <container-id> 却完全无任何输出——包括 print("GRPC Server started...") 这类关键日志。这并非服务异常，而是 Python 默认的 行缓冲（line buffering）或全缓冲（full buffering）行为 在非 TTY 环境（如 Docker 后台容器）下被触发所致。
当 Python 检测到 sys.stdout 不连接到终端（即 os.isatty(sys.stdout.fileno()) == False）时，会自动启用全缓冲模式：所有 print() 输出暂存于内存缓冲区，直到缓冲区满、程序退出或显式调用 sys.stdout.flush() 才真正写入。而在 docker run -d 后台模式下，进程长期运行且未主动刷新，导致日志“消失”。
✅ 解决方案：启用 Python 无缓冲输出
在 Dockerfile 中添加环境变量 PYTHONUNBUFFERED=1，即可强制 Python 对 stdout 和 stderr 使用无缓冲模式（即每次 print() 立即写入）：
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"]
? 验证效果：构建并运行后，执行 docker logs -f <container-name> 即可立即看到 "GRPC Server started, listening on port 50051" 等日志，且后续请求处理日志（如需补充 context 日志）也将实时出现。
A Python CLI skill for Cutout.Pro visual APIs — background removal, face cutout, and photo enhancement. Supports file upload & image URL input.下载调用 Cutout.Pro 视觉处理 API 进行背景移除、人像抠图和照片增强，支持文件上传与图片 URL 输入。
? 其他注意事项与最佳实践
立即学习“Python免费学习笔记（深入）”；
- 不要依赖 print() 做生产级日志：建议改用 logging 模块，并配置 StreamHandler + Formatter，同时显式设置 logging.basicConfig(level=logging.INFO, force=True) 避免重复初始化；
- gRPC 服务需正确绑定地址：代码中 server.add_insecure_port("[::]:50051") 正确监听所有 IPv4/IPv6 接口，适配容器网络；若仅绑定 127.0.0.1 将导致外部客户端无法访问；
- Docker 端口映射必须匹配：docker run -p 50051:50051 与服务监听端口一致，且宿主机防火墙需放行该端口；
- 调试技巧：临时改用前台运行验证日志行为：docker run --rm -p 50051:50051 grpc-test-server（不加 -d），可直接观察控制台输出。
通过 PYTHONUNBUFFERED=1 这一轻量级配置，即可彻底解决容器内 Python 日志不可见问题，显著提升 gRPC 服务的可观测性与运维效率。
