刚学 Python 写了个爬虫，跑得慢，立马加个 import cython？写个简单脚本卡了一下，马上去搜“如何加速 JavaScript 解释器”？先别急着改配置、换工具、上 C 扩展——很多所谓“性能问题”，其实压根不是解释器的锅。
误区一：以为“解释执行 = 天然慢”
很多人一听“解释器”，脑中就自动弹出“比编译型语言慢十倍”的弹窗。但现实是：现代 Python（CPython 3.12+）、JavaScript（V8）、PHP（8.0+）都带即时编译（JIT）或字节码缓存机制。你写的 for 循环，解释器早把它转成高效中间表示了；反复调用的函数，可能已经被热编译过。真瓶颈往往在 I/O 等待、正则回溯、或者一个没加索引的 list.index() 上，而不是“解释”本身。
误区二：迷信“一行代码替换 = 性能翻倍”
看到别人把 for i in range(len(lst)): 换成 for item in lst: 就说“快了3倍”，立马照搬。可实际测一下？
lst = list(range(100000))
# 方式A
for i in range(len(lst)):
_ = lst[i] * 2
# 方式B
for item in lst:
_ = item * 2在 CPython 下，B 通常快 15%~20%，不是3倍。更关键的是：如果这个循环里还夹着一次 requests.get()，那这点差异连网络抖动的零头都不到。
误区三：把全局变量当“性能加速器”
为了少写 math.sqrt，有人这么干：
import math
sqrt = math.sqrt # 认为省掉点号查找就更快
for x in data:
result.append(sqrt(x))确实有微弱提升（纳秒级），但在 Python 中，这种“局部变量缓存”对大多数场景毫无意义。反而容易让代码变晦涩，比如 sqrt = str 这种手滑，调试时能找半天。
误区四：不看数据规模，硬套“最优算法”
听说“字典查找是 O(1)”，于是把 10 个元素的配置项全塞进 dict；又听说“列表切片比循环快”，结果对一个只有 3 个元素的列表写 my_list[1:] + [new]。小数据下，函数调用开销、内存分配成本，常常比算法复杂度影响更大。与其纠结哈希表还是数组，不如先确认：你处理的是 10 行日志，还是每秒百万条传感器数据？
误区五：把 profiler 输出当“圣旨”
运行 python -m cProfile myscript.py，看到 urllib.parse.unquote 占了 40% 时间，马上想重写 URL 解码逻辑。但点进去一看：原来是你批量请求了 200 个带中文参数的 URL，而每个请求前都无脑调用了一次 unquote——其实参数压根没编码，纯属白算。性能分析要看上下文，不是数字大就得动。
真正的性能敏感点，藏在你读文件时用 readlines() 加载 2GB 日志到内存里，藏在你用 json.loads() 解析一个嵌套 20 层的响应体，藏在你每轮循环都新建一个正则对象 re.compile(r'...')。盯紧自己的数据流和调用链，比背一百条“Python 性能技巧”管用得多。