for循环比while循环快，因range()是C实现的迭代器，仅存start/stop/step，next()在C层递增无对象开销；而while中i+=1需多次Python字节码操作，每次循环多出两次解释执行。
for 循环在绝大多数常见场景下确实比手写的 while 循环快，核心原因不是语法糖本身，而是 Python 解释器（CPython）对 range() 和迭代协议做了深度 C 层优化，而 while 中的边界判断和变量更新全是解释执行的纯 Python 操作。
range() 是 C 实现的迭代器，不是 Python 对象
range(10000000) 创建的对象不真正存储所有数字，它只存 start/stop/step 三个整数，__iter__ 返回一个用 C 实现的 range_iterator。每次 next() 调用都直接在 C 层递增并返回，不涉及 Python 对象创建或属性查找。
- 对比
i += 1：每次都要查变量i、取值、加 1、装箱成新int对象、再赋值回局部变量——全是 Python 字节码操作（LOAD_FAST、BINARY_ADD、STORE_FAST） -
range迭代器的步进由 C 函数rangeiter_next完成，没有对象分配开销 - 你用
dis.dis(for_loop)看字节码，会发现循环体里没有LOAD_FAST i或INPLACE_ADD；而while版本里这两条指令每轮都出现
while 循环多出两次纯 Python 判断和更新
一个典型的计数型 while 循环，如 i = 0; while i ，每轮必须执行：
- 一次
LOAD_FAST i+LOAD_CONST n+COMPARE_OP <—— 边界检查 - 一次
LOAD_FAST i+LOAD_CONST 1+INPLACE_ADD+STORE_FAST i—— 自增 - 这两组操作在 CPython 字节码层面就是实实在在多出来的指令，且全部走 Python 的对象模型路径
- 哪怕你把
i += 1换成i = i + 1，性能几乎不变，因为底层字节码仍是BINARY_ADD+STORE_FAST
for 循环加冗余操作会立刻变慢
一旦你在 for 循环体内手动加入原本由解释器隐式处理的逻辑，性能优势就消失了：
- 写
for i in range(n): s += i; i += 1→ 多出一轮INPLACE_ADD，实测比纯for慢约 40% - 写
for i in range(n): if i → 多出一次 <code>COMPARE_OP和分支跳转，慢约 30% - 这些操作本身不改变逻辑，但让字节码膨胀、缓存局部性下降、触发更多解释器开销
别忽略真实场景中的“隐性成本”
性能差距在小循环（比如几十次）里几乎不可测，但当循环体简单、次数上百万时，差异就会放大。更重要的是：while 的可读性和可维护性代价常被低估。
立即学习“Python免费学习笔记（深入）”；
- 手写
while容易漏掉i += 1或写错边界条件，导致无限循环 -
for i in range(n)的语义是“执行 n 次”，边界由range一次性确定，无运行时歧义 - 如果你真需要非线性步进（比如
i *= 2），while不可避免，但这时性能通常已不是瓶颈，逻辑正确性优先
for 基于 range 的写法就是更优解。但别为了省那零点几秒去重构一个只跑一次的初始化循环——那个地方的 while 读起来反而更直白。 
