container/list删除节点必须显式调用list.Remove()，仅置e = nil无效；遍历时需先保存next再remove；value内存需手动管理，无自动GC清理。
container/list 足够用，别急着手写链表
绝大多数业务场景下，container/list 就是正确答案。它开箱即用、内存布局合理、API 稳定，且已通过大量生产验证。手写单链表唯一合理的动机只有三类：算法题训练、教学演示、或对节点内存布局有硬性要求（比如嵌入式设备中避免额外指针开销）。
常见错误包括：
-
head == nil时直接访问head.Next→ panic: invalid memory address - 尾插循环写成
for curr != nil { curr = curr.Next }，结束后curr是nil，再赋值curr.Next = newNode崩溃 - 头插后没更新
head指针，新节点永远不被遍历到 - 函数参数传
Node值类型，形参修改不影响原链表
正确做法：所有操作函数接收 *Node；插入前必判 head == nil；尾插循环终止条件为 curr.Next != nil；最后一步才执行 curr.Next = newNode。
红黑树别自己实现，优先用成熟第三方包
Go 标准库没有红黑树，container/tree 不存在，container/heap 也不是平衡 BST。硬要自己写，99% 的人会在删除修复、重复 key 处理、Comparator 类型适配上翻车——尤其在并发写入时，panic: invalid memory address 几乎必然出现。
立即学习“go语言免费学习笔记（深入）”；
推荐直接 go get github.com/Arafatk/DataViz/trees/redblacktree。它结构清晰、核心逻辑独立、不依赖可视化模块，且 API 明确区分 comparator 类型：
- 存
intkey → 用redblacktree.NewWithIntComparator() - 存
stringkey → 用redblacktree.NewWithStringComparator() - 存自定义 struct → 必须提供 comparator 函数，并做类型断言防护，例如：
func(a, b interface{}) int { return a.(LogEntry).Time - b.(LogEntry).Time }
切记：用 int comparator 存 string key 不会报错，但 tree.Put("123", v) 实际按 int 解析失败后默认为 0，后续 tree.Get(123) 返回 nil，而 tree.Get(0) 才能取到值。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
遍历中删节点必须提前备份 next 指针
container/list 和第三方红黑树（如 gods/treemap）在遍历时删节点，都容易丢元素。根本原因是：e.Next() 返回的是「当前节点在链表中的下一个节点」，但一旦调用 l.Remove(e)，该节点就从链表中断开，e.Next() 的返回值可能已失效——特别是当 e 是最后一个节点时，e.Next() 原本返回 nil 或 head，移除后链接关系彻底破坏。
安全写法只有两种：
- 提前备份：
next := e.Next(); l.Remove(e); e = next - 头部更新式循环：
for e := l.Front(); e != nil; { next := e.Next(); /* do something with e */; l.Remove(e); e = next }
别信“先 Remove 再 Next 就没事”——e.Next() 在 Remove 后的行为未定义，Go 运行时不保证它还能返回有效节点。
并发写红黑树必须加锁，否则迟早 panic
所有主流 Go 红黑树实现（gods/treemap、Arafatk/DataViz、甚至自研版本）都不是线程安全的。Put 过程中会频繁修改 parent、left、right 指针，多个 goroutine 同时插入极易导致某个节点的 parent 指向已释放内存，或旋转时左右子树被不同协程同时篡改。
压测时突然出现 panic: runtime error: invalid memory address，90% 是这个原因。解决方案只有两个：
- 读多写少：用
sync.RWMutex，写操作全程加写锁，读操作只加读锁 - 写密集：考虑用
sync.Map替代，或引入分段锁（shard map），而非硬扛一棵全局红黑树
真正容易被忽略的是：哪怕你只在一个 goroutine 里初始化树、之后只读，只要其他 goroutine 可能触发写操作（比如后台定时刷新缓存），就必须加锁——Go 的内存模型不保证未同步的指针读写顺序。
