why the below two code cause escape in golang

I'm investigating the golang's escape analysis, but in the post http://npat-efault.github.io/programming/2016/10/10/escape-analysis-and-interfaces.html, I have two points of confusion:

Code one:

func Ok(f os.File) []byte {
	var x [128]byte
	b := x[:]
	n, _ := f.Read(b)
	r := make([]byte, n)
	copy(r, b[:n])
	return r
}

func NotOk(c net.Conn) []byte {
	var x [128]byte
	b := x[:]
	n, _ := c.Read(b)
	r := make([]byte, n)
	copy(r, b[:n])
	return r
}

go build -gcflags "-m -l" part3_escape.go

The output:

# command-line-arguments
./part3_escape.go:64:9: leaking param: f
./part3_escape.go:68:11: make([]byte, n) escapes to heap
./part3_escape.go:73:12: leaking param: c
./part3_escape.go:74:6: moved to heap: x
./part3_escape.go:77:11: make([]byte, n) escapes to heap
# command-line-arguments
runtime.main_main·f: function main is undeclared in the main package

I do not know why x escape (moved to heap: x)

Code two:

type S struct {
    s1 int
}

func (s *S) M1(i int) { s.s1 = i }

type I interface {
    M1(int)
}

func g() {
    var s1 S  // this escapes
    var s2 S  // this does not
        
    f1(&s1)
    f2(&s2)
}

func f1(s I) { s.M1(42) }
func f2(s *S) { s.M1(42) }

go build -gcflags "-m -l" part3_escape.go

The output:

# command-line-arguments
./part3_escape.go:63:7: s does not escape
./part3_escape.go:77:9: leaking param: s
./part3_escape.go:78:9: s does not escape
./part3_escape.go:70:6: moved to heap: s1
<autogenerated>:1: leaking param: .this
# command-line-arguments
runtime.main_main·f: function main is undeclared in the main package

I do not know why s1 escape (moved to heap: s1)

It would be great if someone could help explain it,thx😄

The compiler is unable to prove that a call through the interface doesn't store a pointer somewhere. There may be a potential implementation of the interface that stores a pointer, hence it must assume the values can escape.

Newer Go versions can devirtualise calls when inlining and potentially avoid values escaping. You will see this when removing the -l flag in your second example.

There is some discussion on https://github.com/golang/go/issues/33160.

Basically escape analysis happens at the compile time. If the compiler can't decide if a memory(variable in a function) will be accessed even after the function returns, it will be escaped to the heap because memory in the stack will be invalid after the function returns. Compiler here acts pessimistic, if it can't decide at the compile time that a memory will be accessed later it will be escaped to heap.

Coming to your question:

func g() {
    var s1 S  // this escapes
    var s2 S  // this does not
        
    f1(&s1)
    f2(&s2)
}

Here the s1 escapes to the heap because it's accepting interface type, interface type doesn't know what it will executing at the compile time, it only happens during runtime. So s1 escapes.

s2 doesn't escape because we are passing the pointer down the stack, not up the stack. To know more about this please refer https://www.ardanlabs.com/blog/2017/05/language-mechanics-on-escape-analysis.html
snippet 1:

func Ok(f os.File) []byte {
    var x [128]byte
    b := x[:]
    n, _ := f.Read(b)
    r := make([]byte, n)
    copy(r, b[:n])
    return r
}

func NotOk(c net.Conn) []byte {
    var x [128]byte
    b := x[:]
    n, _ := c.Read(b)
    r := make([]byte, n)
    copy(r, b[:n])
    return r
}

The problem here is same, that net.Conn is an interface type, while os.File is not, it is a struct. When the compiler sees a call to a method of net.Conn there is no way to know (at compile time) if the method’s implementation somehow retains a copy of it’s reference argument. The compiler being pessimistic, x will be escaped to the heap.

To know more about escape analysis, you can follow the below 2 links
https://www.ardanlabs.com/blog/2017/05/language-mechanics-on-escape-analysis.html
https://www.ardanlabs.com/blog/2017/06/language-mechanics-on-memory-profiling.html