Go的List操作上的一个小“坑”

一直想不清楚一个问题，简单设计的东西到底是“坑多”还是“坑少”呢？ 复杂的设计，考虑的太全面，使用起来更麻烦，使用者容易陷入乱，落入自身的陷阱;而简单的设计呢，在许多方面上又顾及不周，如果使用者对其“设计”没仔细研究，或者其实现本身又是一个黑盒子，也容易掉入到设计本身遗留下来的“陷阱”。下面是我刚开始使用Go写代码时碰到的一个小“坑”，这个“坑”的原因我归结为后者。

这个“小坑”来自于go的container/list package的使用上。导致“坑”的代码大概如下所示：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

package main import ( "container/list" "fmt" ) func main() { //初始化一个list l := list.New() l.PushBack(1) l.PushBack(2) l.PushBack(3) l.PushBack(4) fmt.Println("Before Removing...") //遍历list，删除元素 for e := l.Front(); e != nil; e = e.Next() { fmt.Println("removing", e.Value) l.Remove(e) } fmt.Println("After Removing...") //遍历删除完元素后的list for e := l.Front(); e != nil; e = e.Next() { fmt.Println(e.Value) } }

以上代码很简单，按常理来看，应该能得到正确的结果，list最后将会被清空。可事实却完全不是这样，执行后结果如下：

1 2 3 4 5 6

Before Removing... removing 1 After Removing... 2 3 4

从结果可以看出，list根本没有清空，而只是删除了第一个元素。这是为何？原因就在container/list package的实现上了。这应该是我见过的实现最简单list了，出去注释也就100来行实现代码，而且它不只是一个简单链表，而且可以当做stack，当做queue来使用。

下面是Remove方法的代码：

1 2 3 4 5 6 7 8 9 10

// remove removes e from its list, decrements l.len, and returns e. func (l *List) remove(e *Element) *Element { e.prev.next = e.next e.next.prev = e.prev e.next = nil // avoid memory leaks e.prev = nil // avoid memory leaks e.list = nil l.len-- return e }

这下问题原因就明显了，就出现在e.next = nil 这行代码上。当执行玩remove,e.next就变成了nil,list遍历当然也就终止了。找出问题的原因，我们就容易找到workaround的办法了，将e.next用中间变量保存起来就OK了，代码如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

package main import ( "container/list" "fmt" ) func main() { l := list.New() l.PushBack(1) l.PushBack(2) l.PushBack(3) l.PushBack(4) fmt.Println("Before Removing...") var n *list.Element for e := l.Front(); e != nil; e = n { fmt.Println("removing", e.Value) n = e.Next() l.Remove(e) } fmt.Println("After Removing...") for e := l.Front(); e != nil; e = e.Next() { fmt.Println(e.Value) } }

正常结果输出：

1 2 3 4 5 6

Before Removing... removing 1 removing 2 removing 3 removing 4 After Removing...