我试图让我的头脑围绕这样一个事实，即Golang的类型Assert只适用于显式定义为接口类型的变量，而不适用于具体类型（即“string”，“int 32”等）。
下面是一个快速而简单的代码示例，它说明了我困惑的根本原因：

package main

import "fmt"

// here we define an interface type:
type Shape interface {
    DoubleSize() int32
}

// here we define a new type which is really just an int32:
type Rect int32

// here we make "Rect" type above comply with the "Shape" interface by implementing the methods of that interface
// and so, since the interfaces in Go are implemented implicitly, this should make the "Rect" type an implicit instance of the "Shape" interface
func (theShape Rect) DoubleSize() int32 {
    return int32(theShape) * 2
}

// this function expects its "someShape" parameter to be of "Shape" type (or "the type that quacks like "Shape" interface does))
func whateverFunction(someShape Shape) int32 {
    return someShape.DoubleSize()
}

func main() {
    var newRect = Rect(5)
    // ^^ if this is instead written as "var newRect Shape = Rect(5)" no error with type assertion happens down the line

    whateverFunction(newRect) // the function works just fine because "newRect" implicitly implements the "Shape" interface — the one that this function expects to receive.  

    // !! but type assertion doesn't work on "newRect"
    v, ok := newRect.(Shape) // error: invalid operation: newRect (variable of type Rect) is not an interface
    if !ok {
        fmt.Println("type assertion failed")
        return
    }
    fmt.Println("This is v:", v)
}

正如这个问题的标题所暗示的，我无法理解实现类型Assert只对接口类型起作用的背后的推理，并检查分配给实现该接口的变量的底层值是否是我们在“”中指定的。（T）”Assert方法。这让我觉得“类型Assert”是一个无意的用词不当，暗示它适用于所有类型，但不是，仅适用于接口类型。
我的意思是，这个语言设计决策背后显然一定有一个原因，我认为这可能与惯用Golang的编写方式有关，但是尽管我已经看到了很多关于这个问题的资源，他们从来没有指定这个原因。
对我来说有意义的原因是，如果Go程序应该，“最好（我假设，因为显式接口定义是可选的）”，用所有表示某个接口（行为）的变量来编写，因此为了清晰和可读性的目的，在变量上定义显式接口是有意义的。
但正如我所提到的，我从来没有看到任何资源指定为什么这是Go中“类型Assert”功能的实现方式，我希望你能帮助我澄清这个困惑。

• -- upd 1* -添加一点来澄清我的问题：

在它的核心，我想，我的问题是关于为什么（我不明白）类型Assert只在变量的接口被显式实现时有效，而不是在接口被隐式实现时。
正如“whateverFunction”所展示的，代码确实考虑“newRect”来实现“Shape”接口，或者“成为“Shape”接口的实现”（否则函数将无法使用该变量，但它确实如此），但类型Assert“.（T）”方法后面的代码不考虑“newRect”作为“Shape”接口的实现。
因此，如果Golang在考虑接口实现方面存在差异，我认为这样的设计决策背后一定有原因（差异化）。
这就是为什么我提到到目前为止我能想到的唯一原因是，如果这是一种让人们以某种方式编写Go代码的方法。