id() 和 is 比较对象在内存中的实际地址，即 PyObject* 指针值；引用计数增减由底层指针操作触发，循环引用需 gc 模块清理；sys.getrefcount() 结果恒比真实值多 1。
Python 的
id()
和
is
到底在比较什么
它们比较的是对象在内存中的实际地址，也就是 CPython 解释器中
PyObject*
指针的值。不是“值相等”，也不是“类型一致”，纯粹是同一块内存区域的标识。
常见误用：用
is
判断数字或字符串是否“内容相同”。比如
1000 is 10**3
在某些 Python 版本返回
False
，因为小整数（-5 到 256）会被缓存复用，但超出范围后每次字面量都会新建对象。
永远用
==
判断值是否相等，
is
只用于确认是否为同一对象（如
obj is None
）
id()
返回的整数在对象生命周期内不变，但不同对象可能在不同时刻有相同
id()
（内存复用）
多线程下
id()
不保证全局唯一，只在单次运行中对存活对象有效
引用计数怎么被触发增减
CPython 用引用计数作为主要内存管理机制，每个对象头里存着一个
ob_refcnt
计数器。它不是“变量引用次数”，而是“指向该对象的指针数量”。
增减发生在底层操作层面，比如：
立即学习
“
Python免费学习笔记（深入）
”；
赋值语句：
a = obj
→
obj
引用计数 +1；
a = b
→ 原
a
所指对象 -1，
b
所指对象 +1
容器插入：
lst.append(obj)
→
obj
计数 +1；
lst.pop()
→ 对应对象 -1
函数传参：调用时形参获得实参对象的新引用，函数返回后局部变量销毁 → 计数 -1
循环引用不会自动触发减计数，这是引用计数模型的根本缺陷，必须靠 gc 模块的周期性扫描来清理
为什么
sys.getrefcount()
总比预期多 1
因为调用
sys.getrefcount(x)
这个动作本身，会让
x
临时多一个引用 —— 参数传递过程会增加一次计数。
Python 3.14.3
微软官方的 Python 扩展，是 VS Code 安装量最高的扩展（209M+）。集成 IntelliSense（通过 Pylance）、调试（通过 Python Debugger）、代码检查、格式化、重构和单元测试等功能。支持 Jupyter Notebook、虚拟环境管理和多 Python 版本切换。
下载
例如：
import sys
a = []
print(sys.getrefcount(a)) # 输出通常是 2（不是 1）
这个“+1”是确定的、可预测的干扰项，不是 bug，也不是内存泄漏迹象。
不要用
getrefcount()
来调试循环引用，它掩盖了真实引用关系
想看对象被哪些地方持有时，用
gc.get_referrers(obj)
更直接（但注意它也可能引入临时引用）
在 C 扩展中手动调用
Py_INCREF/Py_DECREF
时，必须严格配对，否则计数错位会导致提前释放或内存泄漏
对象销毁时机与
__del__
的不可靠性
当引用计数降到 0，CPython 立即调用对象的
__del__
方法并释放内存。但这个“立即”仅限于当前线程、无异常、无循环引用的干净场景。
__del__
不保证执行顺序，多个对象互相引用时，谁先销毁无法预判
若
__del__
抛出异常，解释器只会打印警告，不会中断程序，也不会重试
模块卸载阶段（解释器退出时），全局变量和模块级对象的引用计数归零顺序不确定，
__del__
可能访问已销毁的其他对象
真正需要资源清理时，优先用
with
语句或显式
.close()
，而不是依赖
__del__
引用计数的简洁性是以牺牲确定性和跨实现兼容性换来的。一旦涉及多线程、C 扩展或长期运行的服务，就得直面它的边界 —— 那些没被
gc
捕获的循环、那些在解释器关闭时静默消失的
__del__
、还有那些你以为“应该被释放”却还挂在某个闭包里的对象。
