生产环境不该禁用.pyc生成，否则会显著增加冷启动延迟；唯一可靠方式是设pythondontwritebytecode=1环境变量，需在各部署环节透传并验证sys.dont_write_bytecode为true。
为什么生产环境通常不该禁用.pyc生成
禁用 .pyc 会强制每次 import 都重新编译源码，冷启动延迟明显升高——尤其在 Flask/Django 等框架加载数十个模块时。生产部署本就该利用字节码缓存提速，除非遇到只读文件系统、容器镜像构建阶段需清理残留、或调试特定缓存失效问题。
PYTHONDONTWRITEBYTECODE=1 是唯一可靠方式
它在 C 层解析命令行前就生效，能覆盖标准库（如 os、json）的字节码写入，而 sys.dont_write_bytecode = True 在你的脚本执行时才起作用，早已错过 site.py 初始化阶段。
- Linux/macOS：在启动服务前执行
export PYTHONDONTWRITEBYTECODE=1，确保被 systemd、supervisord 或容器 runtime 继承 - 容器中（Docker）：在
Dockerfile中写ENV PYTHONDONTWRITEBYTECODE=1，不要依赖 entrypoint 脚本里的 export - Kubernetes：通过
env字段注入，避免在command中用sh -c "export ...; python app.py"—— 子 shell 的环境变量不传给 python 进程 - 注意：若同时用了
python -B，环境变量仍优先生效；但-B无法用于python -m http.server这类模块启动方式
常见失效场景和验证方法
明明设了环境变量，__pycache__ 还是出现，大概率是环境没透传成功。
- 检查是否真生效：启动 Python 后运行
import sys; print(sys.dont_write_bytecode)，输出必须为True - IDE 或进程管理器（如 gunicorn 的
--preload）可能重置环境，需在配置里显式声明该变量 - 某些 CI/CD 工具（如 GitHub Actions 的
run步骤）默认不继承父 shell 环境，得用env:块注入 -
importlib.util.cache_from_source(__file__)可查某 py 文件本该生成的 pyc 路径；如果该路径所在目录仍被创建，说明禁用失败
禁用后必须处理的副作用
不是设个变量就完事——Python 仍会尝试往 __pycache__ 目录写文件，只是被拦截。但若该目录权限异常或磁盘只读，解释器不会报错，而是静默跳过缓存，导致后续所有 import 都变慢。
- 确认项目根目录及所有
sys.path条目下的__pycache__可写（或根本不存在） - 容器镜像中建议
RUN find /app -name '__pycache__' -type d -exec rm -rf {} +彻底清理历史残留 - 若用
sys.pycache_prefix（Python 3.12+）自定义缓存位置，禁用后该设置无效，无需额外处理
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
