容器内Python日志需显式配置StreamHandler到sys.stdout并强制刷新，时区问题须在运行镜像中安装tzdata并设TZ环境变量，避免依赖%(asctime)s而应自定义formatTime。
容器内Python日志不输出到stdout/stderr？
默认情况下，Python的logging模块不会自动将日志刷到标准输出——尤其在Docker中，若未显式配置，日志可能被缓冲、丢失或写入文件（而容器期望日志走stdout）。关键不是“有没有日志”，而是“容器能否捕获并转发它”。
- 确保
StreamHandler绑定到sys.stdout（而非sys.stderr，除非你明确要区分错误流），且setLevel不低于实际调用级别 - 禁用
logging.basicConfig的默认行为（它可能静默覆盖已有handler），改用显式Logger实例配置 - 添加
handler.setFormatter时避免使用%(asctime)s等依赖本地时区格式化的字段——否则时间戳会乱，见下文时区部分 - 强制刷新：对
StreamHandler设置stream.flush()，或在logging.basicConfig中加force=True, handlers=[...]并手动handler.flush()
示例最小可靠配置：
import logging
import sys
<p>logger = logging.getLogger("myapp")
logger.setLevel(logging.INFO)
handler = logging.StreamHandler(sys.stdout)
handler.setFormatter(logging.Formatter("%(levelname)s %(message)s"))
logger.addHandler(handler)</p><h1>关键：避免缓冲</h1><p>handler.stream.flush = lambda: None # 或更稳妥地，在每次log后调用 handler.stream.flush()
Docker容器里Python显示的时间比宿主机慢8小时？
这不是Python的问题，是容器默认使用UTC时区，而你的应用代码（比如datetime.now()）没指定tz，又没挂载宿主机时区文件，结果全按UTC算——看着就像“慢了8小时”（以东八区为例）。
- 不要在Python里硬编码
pytz.timezone("Asia/Shanghai")或zoneinfo.ZoneInfo("Asia/Shanghai")来“修复”——这会让镜像失去可移植性 - 正确做法是在
Dockerfile中声明时区：ENV TZ=Asia/Shanghai，再RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone - 如果用Alpine基础镜像，需先
apk add --no-cache tzdata，否则/usr/share/zoneinfo不存在 - 验证是否生效：容器内运行
date，输出应与宿主机一致；Python中from datetime import datetime; print(datetime.now().strftime("%Z %z"))应显示CST +0800而非UTC +0000
为什么设置了TZ环境变量，logging.Formatter里的%(asctime)s还是UTC时间？
%(asctime)s默认调用time.localtime()，但它受time.tzset()影响——而Python启动后才读取TZ环境变量，Docker容器里常因启动顺序问题导致tzset()未触发。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
- 最稳方案：不用
%(asctime)s，改用%(created)f+ 自定义formatter，在formatTime方法里显式调用datetime.fromtimestamp(record.created, tz=zoneinfo.ZoneInfo("Asia/Shanghai")) - 次选方案：在Python入口脚本开头强制重置时区：
import time; time.tzset()（仅Linux有效，且要求TZ已设好） - 避免踩坑：
logging.basicConfig必须在time.tzset()之后调用，否则handler内部缓存的time.localtime仍为UTC
多阶段构建中时区和日志配置容易漏掉哪一环？
常见错误是只在build阶段装tzdata（如Alpine的apk add tzdata），但最终FROM python:3.11-slim镜像里没这个包，/usr/share/zoneinfo为空——导致ln -sf软链失败，TZ环境变量形同虚设。
- 必须在最终运行镜像中安装时区数据：
RUN apt-get update && apt-get install -y tzdata && rm -rf /var/lib/apt/lists/*（Debian系）或apk add --no-cache tzdata（Alpine） - 日志配置不能只靠
requirements.txt——logging是标准库，但它的行为依赖运行时环境（如sys.stdout是否为TTY、是否被重定向），务必在容器启动命令前验证python -c "import sys; print(sys.stdout.isatty())"返回False（非交互模式） - CI/CD流水线中，若用
docker build --target dev测试，别忘了切换回prod目标再验证最终镜像，否则时区和日志路径可能不一致
最易被忽略的是：容器进程的stdin/stdout/stderr是否被Docker守护进程正确接管——如果启动时用了--detach但没加-t（伪TTY），某些Python日志handler会悄悄降级为文件输出。直接跑docker run --rm your-image python -c "import logging; logging.warning('test')"看终端是否立刻打印，比查文档更快定位问题。
