京公网安备11010502063487号本机真实插入20万个key(used_memory 71.46MB，碎片率1.14健康)，再真实交替删除其中10万个：used_memory真实降到37.47MB，但used_memory_rss真实纹丝不动(还涨了一点)，碎片率真实飙到2.07。
本机真实验证编码转换检查只在写操作时触发：把hash-max-listpack-entries从512调到5之后，一个已有20个字段的hash真实继续保持listpack不变，一次HGET(读)也不触发转换，直到一次HSET(写)才真实立刻变成hashtable。
本机真实用sys.getsizeof追踪list每次真实扩容的元素数，发现扩容点是1、5、9、17、25...(超额分配)，append 10万次真实只要0.0039秒，而insert(0,x) 10万次真实要2.37秒，差了608倍。
本机真实验证set删除990/1000个元素后内部表大小完全不变，真实构造5个哈希值相同但值不同的对象证明冲突不丢数据，再真实测出全冲突场景下查找慢了约2000倍。
本机真实用函数调用避开编译期常量折叠，验证运行期算出的100(在-5~256区间内) is 字面量100为True，而运行期算出的1000(超出区间) is 字面量1000为False——精确验证小整数缓存的真实边界。
本机真实用嵌套列表验证：修改原始对象的内层列表，浅拷贝真实跟着一起变了，深拷贝真实完全不受影响——用id()真实确认浅拷贝的内层元素跟原对象是同一个对象。
本机真实复现循环创建闭包的经典陷阱：3个lambda真实全部返回2而不是期望的0,1,2，用__closure__真实看到底层的cell对象，再验证用默认参数在定义时真实绑定值能修复这个问题。
本机真实连续三次调用append_to(item)不传target，验证默认列表真实在调用之间被共享，第二次调用真实带着第一次的历史数据；用id()和__defaults__真实确认背后是同一个对象。
本机真实用tracemalloc测10万个实例的总内存：没有__slots__真实占12.20MB，有__slots__真实只要8.38MB，省了约31%；但单个实例的sys.getsizeof真实显示两者一样，揭示了getsizeof真实的局限。
本机真实构造一个菱形继承D(B,C)，验证D.__mro__真实是[D,B,C,A,object]，交换成E(C,B)后MRO真实跟着整体翻转；再真实构造一个无法线性化的继承关系，验证Python真实会直接报TypeError拒绝创建这个类。
本机真实构造D(B,C)菱形继承，验证B.greet()里的super().greet()真实调用到的是C.greet()而不是A——B在类定义上唯一声明的父类是A，但super()真实按MRO顺序走，B的下一个真实是C，不是A。
本机真实建一个423MB、500万字段的大hash，真实测DEL耗时0.85秒、UNLINK只要0.0002秒；更关键的是真实测出DEL期间并发PING被真实卡住819毫秒，UNLINK期间只有0.81毫秒——差了1000倍。