用conda创建物理隔离的python 3.8.10和3.11.9环境，禁用缓存与监控钩子，以pyperformance或pyperf运行纯解释器负载测试（如递归斐波那契、json序列化），重点关注p95延迟、内存峰值及统计显著性，而非平均耗时。
直接用conda创建隔离的3.8和3.11环境
别碰系统Python，也别改PATH——两个版本必须物理隔离，否则pip list或python -c "import sys; print(sys.version)"会串。用conda最稳，它能确保解释器、site-packages、pip缓存全分开。
- 先装Miniconda（不是Anaconda），避免预装包干扰测试
- 执行
conda create -n py38 python=3.8.10和conda create -n py311 python=3.11.9（注意：Windows上3.11最高支持到3.11.9，3.8推荐用3.8.10） - 激活后分别运行
python -m pip install --upgrade pip setuptools，不要装任何额外包，保持基准干净 - 验证：分别在两个环境中跑
python -c "import platform; print(platform.python_implementation(), platform.python_version())"，输出必须严格对应
选对测试代码，避开CPython优化陷阱
Python 3.11的“快60%”只在特定场景成立，比如函数调用密集、异常频繁、字典/列表操作多的逻辑。拿纯数值计算（如NumPy矩阵乘）去比，结果会被底层C库主导，根本测不出解释器差异。
- 推荐用官方
pyperformance工具：pip install pyperformance，然后在各自环境中分别跑pyperformance run -o py38.json和pyperformance run -o py311.json - 手动验证时，优先用递归斐波那契、JSON序列化/反序列化、大量
try/except嵌套、f-string拼接1000次等纯解释器负载任务 - 避免用
timeit.timeit单次运行——要加number=100000且重复repeat=5，取中位数，否则JIT warmup没起效，数据失真 - 禁用
__pycache__干扰：测试前加export PYTHONPYCACHEPREFIX=""（Linux/macOS）或set PYTHONPYCACHEPREFIX=（Windows）
Windows下特别注意Uvicorn和子进程行为差异
如果你测的是Web服务启动时间或ASGI吞吐，uvicorn在3.8和3.11上的表现可能因spawn/fork策略不同而剧烈波动——尤其在Windows上默认用spawn，而3.11对spawn路径解析有变更。
- 统一用
--workers 1 --loop asyncio启动，禁用--reload（热重载会引入文件监听开销） - 检查
uvicorn --version：3.11环境必须用uvicorn>=0.29.0，否则asyncio.run()调用路径不一致，测出来不是解释器性能而是兼容性bug - 子进程测试（如
subprocess.run(["python", "-c", "print(1)"])）在3.11里默认启用start_new_session=True，导致开销略增，需显式传start_new_session=False才公平 - 别信任务管理器里的CPU占用率——它包含后台服务，用
psutil.Process().cpu_times()取用户态时间更准
结果对比时忽略“平均值”，盯住P95延迟和内存峰值
单纯比“总耗时”容易误导。3.11的优化主要体现在尾部延迟（P95/P99）和GC压力上，而不是均值。一次跑10万次，前9万次可能都差不多，最后几千次3.11明显更稳。
- 用
pyperf而非手写脚本：它自带统计显著性检验（--rigorous）和内存分配追踪（--track-memory） - 重点关注
mem_peak_mb和max_rss：3.11的PyObject结构更紧凑，同等逻辑下内存峰值常低15%–20% - 如果测试涉及I/O（如读大文件），加
--affinity 0绑定单核，排除调度抖动干扰 - 3.11的
sys.monitoringAPI默认开启，若你用了coverage或pytest-profiling，务必关掉——它们会拖慢3.11更多
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
