Python 3 中只能用 range，xrange 已被彻底删除；range 行为与 Python 2 的 xrange 一致，是轻量、不可变、按需计算的序列对象，内存和性能无差异。
range 是 Python 3 的唯一选择，xrange 在 Python 3 中根本不存在 —— 它不是“应优先使用”，而是“只能用 range”。
Python 3 中写 xrange() 直接报错
这是最直接的现实约束。任何在 Python 3 环境下执行 xrange(10) 的代码，都会立刻抛出：
NameError: name 'xrange' is not defined
原因很明确：Python 3 已彻底移除 xrange，不是弃用，是删除。所有兼容性迁移工作早在 2010 年起就已推进，2026 年还在试图调用 xrange，通常意味着项目还卡在 Python 2 迁移半途，或复制了过时教程代码。
range 在 Python 3 中就是当年的 xrange
Python 3 的 range 不再返回 list，而是一个轻量、不可变的序列对象，行为和内存模型与 Python 2 的 xrange 完全一致：
- 不预分配整数列表，只存
start、stop、step三个参数 -
len(range(10**8))瞬间返回，不触发内存暴涨 - 支持
5 in range(1000000)、range(10)[::2]（切片返回新range） - 迭代时按需计算，GC 压力极小
换句话说，你写 for i in range(10**7)，和当年 Python 2 里写 for i in xrange(10**7)，底层机制一模一样 —— 只是函数名变了。
立即学习“Python免费学习笔记（深入）”；
误以为“Python 3 的 range 比 Python 2 的 xrange 慢”是个常见错觉
有些人拿 timeit 测出 Python 3 range 迭代略慢几十毫秒，就怀疑它退化了。实际问题往往出在：
- 测试用了
[x for x in range(N)]—— 这是在构造list，不是测range本身 - 混用了 32 位 Python 解释器（已严重过时），其整数运算和迭代器开销远高于 64 位
- 把
range和生成器表达式（如(x for x in range(N))）性能混为一谈
真实场景中，只要你不显式转成 list，Python 3 的 range 和 Python 2 的 xrange 在内存占用、启动延迟、循环吞吐上基本无差别。
唯一需要显式转 list 的情况，才用 list(range(...))
如果你确实需要一个可修改、可随机索引、可多次遍历的整数列表（比如要 .append()、.sort() 或反复 for 多次），那就主动转换：
indices = list(range(1000))
但注意：这一步会立刻分配内存并生成全部整数对象 —— 和 Python 2 的 range(1000) 行为一致。这不是 range 的问题，是你主动选择了“加载全部”的语义。
try/except NameError 去 fallback 到 xrange，这毫无必要。2026 年的新项目，应该直接锁定 Python 3.8+，把 range 当作原生、高效、唯一的整数序列构造方式来用。 
