没必要手写红黑树，Python中sortedcontainers和bisect已覆盖绝大多数需求；仅教学、嵌入式或特殊比较场景才需手写，且易出错、性能差。
红黑树在Python里真有必要手写吗
Python标准库没有内置红黑树，但sortedcontainers（第三方）和bisect模块已覆盖绝大多数有序集合需求。手写红黑树仅在极少数场景合理：教学理解、嵌入式受限环境、或需深度定制比较逻辑且对dict/set的哈希不可控（比如自定义对象频繁比较但无法稳定哈希）。否则，用sortedlist或rbtree（Cython封装）更可靠。
从节点定义开始就容易错的颜色字段
红黑树核心是五条性质，其中“每个节点非红即黑”看似简单，但实现时常见错误是把颜色存成字符串"red"/"black"或布尔值True/False——这会拖慢旋转和重着色判断。推荐用整数枚举：RED = 0、BLACK = 1，或直接用bool但统一约定True为红色（注意：部分教材反着来，必须全文一致）。
- 颜色字段必须是实例属性，不能靠类变量模拟
- 插入后首次着色为红色，不是黑色；否则破坏性质5（从任一节点到其每个叶子的所有路径都包含相同数目的黑节点）
-
None节点（空子树）必须视为黑色，这是所有修正逻辑的前提
插入后的修复逻辑比BST复杂在哪
BST插入只需递归定位，红黑树插入后必须调用fix_insert，它处理三种情况（叔节点颜色+当前节点位置），每种都可能触发旋转+重着色。关键点：
- 修复必须自底向上进行，但Python递归栈深有限，建议用迭代+父指针方式，避免
RecursionError - 左旋/右旋函数必须同时更新父子关系和颜色，漏掉
parent.color或new_root.color会导致后续判断失效 - 当前节点
z的祖父g和叔节点u必须显式获取，不能假设g.left == u——如果z在g右子树，u其实是g.left - 情况2（叔黑，且
z与父节点方向不一致）必须先旋转再进入情况3，顺序颠倒会导致结构错误
删除操作为什么几乎没人完整实现
删除比插入难得多：需先找到中序后继（或前驱），交换值后再删叶子/单子节点，接着从被删位置向上修复。问题在于：
立即学习“Python免费学习笔记（深入）”；
- 修复分四种情形（双黑节点的兄弟颜色+侄子结构），代码分支多且易漏
- Python没有指针，节点替换时
parent引用极易丢失，导致树断裂 - 实测表明，纯Python实现的红黑树在插入10万节点后，删除耗时可能比
sortedlist.remove()慢8–12倍，主要卡在Python对象创建和属性访问开销上
真正需要高性能有序结构时，别卡在“手写正确性”，优先试sortedcontainers.SortedList，它底层用分块数组，均摊O(log n)，实测比手写红黑树更稳更快。手写只适合理解原理，上线请绕道。
