我有以下簡單的基于泛型的go包，它實現了 GoF 訪客模式：package patternstype Social interface {    AcceptVisitor(visitor *Visitor)}type Component struct {}func (c *Component) AcceptVisitor(visitor *Visitor) {    visitor.VisitComponent(c)}type Collection[T Social] struct {    Component    items[]T}func (c *Collection[T]) AcceptVisitor(visitor *Visitor) {    visitor.VisitCollection(c) // <- Error Here}type Visitor struct {}func (v *Visitor) VisitComponent(component *Component) {}func (v *Visitor) VisitCollection(collection *Collection[Social]) {    for _, item := range collection.items {        item.AcceptVisitor(v)    }}編譯器給出以下錯誤：./patterns.go:20:26: cannot use c (variable of type *Collection[T]) as  type *Collection[Social] in argument to visitor.VisitCollection這對我來說似乎很奇怪，因為通用類型 T 被限制為 Social。我嘗試了幾件事：用接口定義替換了訪問者抽象類型。這導致了社交和訪客界面之間的循環依賴。從修復問題的聲明中刪除了泛型，但我們非常需要 Collection 類型的泛型。看起來go應該能夠處理這段代碼中的泛型。可能的解決方案：在與@blackgreen 進行了非常有幫助的討論之后，我們決定問題出現的原因有以下幾點：Go 是（真正）嚴格類型化的，不允許將傳遞給函數的參數“縮小”為原始類型的子集，即使編譯器仍然可以證明它是安全的。Go 是否應該允許縮小范圍是有爭議的。Go 不允許對方法進行泛型約束，因為約束可能會與與方法關聯的結構上的泛型約束發生沖突。Go，沒錯，不允許循環依賴。我們可以將訪問者模式的所有依賴項抽象為接口，但隨后將具有該模式的“雙重分派”方面所需的循環依賴項。為了繞過這些項目，并仍然獲得訪問者模式的好處，我們可以將訪問者結構中的 VisitXYZ() 方法更改為（可能是通用的）函數，每個函數都將 *Visitor 參數作為函數的第一個參數和被訪問的對象作為第二個參數。我在 Go Playground 中發布了這個解決方案：https ://go.dev/play/p/vV7v61teFbj注意：即使這個可能的解決方案看起來確實可以解決問題，但實際上并沒有。如果您考慮編寫幾種不同類型的訪問者（一種用于漂亮打印，一種用于復制，一種用于排序等），您很快就會意識到，由于 VisitXYZ() 函數不是方法，因此您不能為每個函數擁有多個版本每個訪客類型。最后，Visitor 模式確實需要 Social 接口和 Visitor 接口之間的循環依賴這一事實注定了 Go 的失敗。我將關閉這篇文章，但會留下分析，這樣其他人就不需要重復了。