结论：is在小整数（-5到256）上返回True，是因为CPython预创建并常驻这262个整数对象，所有赋值均复用同一内存地址；范围外则每次新建对象，is返回False。
直接说结论：is 在小整数（-5 到 256）上返回 True，不是因为“它更聪明”，而是 Python 解释器提前把这 262 个整数对象常驻内存，所有变量赋这些值时都复用同一块地址；超出这个范围，每次赋值就新建对象，is 自然返回 False。
小整数对象池的范围和触发条件
Python 的小整数缓存范围是固定的：-5 到 256（含）。这个范围在 CPython 源码中硬编码，所有符合该范围的字面量整数（如 a = 100、b = 256）都会被指向同一个对象。
- 范围外的整数（如
257、-6、1000）不会进入对象池，每次赋值都调用PyLong_FromLong创建新对象 - 这个机制只对**字面量或编译期可确定的整数**生效；动态计算出的值（如
x = 255 + 1）即使结果是 256，也不一定命中驻留（取决于优化级别和执行环境） - 交互式解释器（
python命令行）和脚本文件执行行为一致，但某些 IDE（如 PyCharm）可能因底层优化表现出更宽泛的驻留，不可依赖
为什么 is 和 == 在小整数上看起来“一样”
这不是逻辑等价，而是巧合 —— 因为驻留让两个变量恰好指向同一内存地址，所以 is 成立；而值相等本来就成立，所以 == 也成立。二者本质完全不同：
-
==调用对象的__eq__方法，比较的是数值语义 -
is是纯地址比较，等价于id(a) == id(b) - 一旦脱离驻留范围（比如
a = 1000; b = 1000），a == b仍为True，但a is b很可能为False
常见误用场景和坑
把 is 当作“高效版 ==”来用，尤其在整数比较中，是危险的。真实项目里最容易踩的几个点：
立即学习“Python免费学习笔记（深入）”；
- 用
if x is 0:替代if x == 0:—— 看似省事，但x若来自用户输入、JSON 解析或计算表达式（如int("0")），不保证驻留，行为不稳定 - 在单元测试里写
assert result is 256—— 如果函数内部做了类型转换或重新构造，哪怕值没变，is也可能失败 - 跨模块或跨函数传递小整数后做
is判断 —— 驻留是全局的，这点没问题；但若中间经过序列化/反序列化（如pickle、json），对象就重建了，is必然失效
什么时候该用 is？只有一种情况
唯一安全、明确、被官方推荐的 is 使用场景，是跟单例对象比较：
-
if x is None:—— 必须用is，这是 PEP 8 强制规范 -
if flag is True:或is False:—— 不推荐，直接用if flag:或if not flag:更 Pythonic -
if obj is ...:（Ellipsis）或is NotImplemented:—— 这些也是单例，可用is
拿小整数做 is 判断，就像靠太阳东升西落写定时任务——短期能跑，长期必翻车。驻留机制是实现细节，不是语言契约。
