PYTHONOPTIMIZE是Python启动时控制字节码优化级别的环境变量，值为0/1/2分别对应无优化、移除assert、额外移除docstring，影响__debug__、.pyc路径及内容，需确保字节码缓存与运行时级别严格匹配。
PYTHONOPTIMIZE 环境变量是 Python 启动时控制字节码优化级别的底层开关，它直接决定 __debug__ 的值、是否移除 assert 语句、是否丢弃文档字符串（docstring），并影响最终生成的 .pyc 文件内容。它比命令行 -O / -OO 更适合在容器、CI/CD 或 Serverless 环境中统一控制行为。
为什么用 PYTHONOPTIMIZE 而不是每次加 -O
命令行参数只作用于单次执行，而环境变量对整个 Python 进程及其子进程生效，尤其适用于：
- WSGI/uWSGI/Gunicorn 启动的 Web 应用（避免漏掉某个 worker）
- Docker 容器中运行多个脚本（统一优化策略，无需改启动命令）
- AWS Lambda 或阿里云函数计算等 Serverless 平台（冷启动时一次生效，避免重复编译）
PYTHONOPTIMIZE=1 和 =2 的实际差异
数值不是“越高越好”，而是有明确语义：
-
PYTHONOPTIMIZE=0：默认值，不启用优化（即使没设该变量，也等价于 0） -
PYTHONOPTIMIZE=1：等效于python -O，移除所有assert语句，设__debug__ = False -
PYTHONOPTIMIZE=2：等效于python -OO，额外移除所有文档字符串（__doc__变为None）
注意：PYTHONOPTIMIZE=3 或更高值会被忽略，Python 只识别 0/1/2。
加载字节码时的真实影响
设置 PYTHONOPTIMIZE 不仅影响运行时行为，还改变字节码缓存路径和内容：
立即学习“Python免费学习笔记（深入）”；
- 生成的
.pyc文件会落在__pycache__/xxx.cpython-312.opt-1.pyc（对应=1）或.opt-2.pyc（对应=2） - 如果已存在未优化的
.pyc，Python 不会复用，而是重新编译生成带 opt 标记的新文件 - 模块首次导入时，若源码未变但
PYTHONOPTIMIZE值变了，就会触发重编译——这在部署时容易被忽略，导致冷启动变慢
示例：同一段代码，在 PYTHONOPTIMIZE=1 下，assert x > 0 对应的 ASSERTION_ERROR 字节码直接消失，函数体变短，栈操作减少。
Serverless 场景下必须检查的三个点
在 Lambda、FC 等平台使用 PYTHONOPTIMIZE 时，以下三点最容易出问题：
- 打包前未清理
__pycache__：残留的非优化.pyc文件可能被误打包，运行时仍加载旧字节码 - 本地开发用
=0，线上用=1，但 CI 脚本未强制指定，导致环境不一致 - 依赖包（如
requests）内部含大量assert或 docstring，=2可能破坏某些库的调试逻辑（比如help()返回空）
推荐做法：在构建阶段显式执行 PYTHONOPTIMIZE=1 python -m compileall -b -f .，确保所有 .py 都按目标级别编译，且不保留未优化缓存。
opt-1 和 opt-0 的后缀，就可能让优化失效。 
