一段简单的程序

package main

func main() {
    f1()
}

func f1() (result int) {
    defer func() {
        result = result + 1
    }()
    return 12
}
// Output:
// 13

来看看汇编

(gdb) disas
Dump of assembler code for function main.f1:
   0x000000000044ebe0 <+0>:     mov    rcx,QWORD PTR fs:0xfffffffffffffff8
   0x000000000044ebe9 <+9>:     cmp    rsp,QWORD PTR [rcx+0x10]
   0x000000000044ebed <+13>:    jbe    0x44ec55 <main.f1+117>
   0x000000000044ebef <+15>:    sub    rsp,0x20
   0x000000000044ebf3 <+19>:    mov    QWORD PTR [rsp+0x18],rbp
   0x000000000044ebf8 <+24>:    lea    rbp,[rsp+0x18]
   0x000000000044ebfd <+29>:    mov    QWORD PTR [rsp+0x28],0x0
   0x000000000044ec06 <+38>:    lea    rax,[rsp+0x28]
   0x000000000044ec0b <+43>:    mov    QWORD PTR [rsp+0x10],rax
   0x000000000044ec10 <+48>:    mov    DWORD PTR [rsp],0x8
   0x000000000044ec17 <+55>:    lea    rax,[rip+0x21d92]        # 0x4709b0
   0x000000000044ec1e <+62>:    mov    QWORD PTR [rsp+0x8],rax
   0x000000000044ec23 <+67>:    call   0x420f70 <runtime.deferproc>
   0x000000000044ec28 <+72>:    test   eax,eax
   0x000000000044ec2a <+74>:    jne    0x44ec45 <main.f1+101>
=> 0x000000000044ec2c <+76>:    mov    QWORD PTR [rsp+0x28],0xc
   0x000000000044ec35 <+85>:    nop
   0x000000000044ec36 <+86>:    call   0x4217f0 <runtime.deferreturn>
   0x000000000044ec3b <+91>:    mov    rbp,QWORD PTR [rsp+0x18]
   0x000000000044ec40 <+96>:    add    rsp,0x20
   0x000000000044ec44 <+100>:   ret
   0x000000000044ec45 <+101>:   nop
   0x000000000044ec46 <+102>:   call   0x4217f0 <runtime.deferreturn>
   0x000000000044ec4b <+107>:   mov    rbp,QWORD PTR [rsp+0x18]
   0x000000000044ec50 <+112>:   add    rsp,0x20
   0x000000000044ec54 <+116>:   ret
   0x000000000044ec55 <+117>:   call   0x446f20 <runtime.morestack_noctxt>
   0x000000000044ec5a <+122>:   jmp    0x44ebe0 <main.f1>

可以看出，系统先执行了deferproc然后给result赋值12再去执行了deferreturn。
如果说defer内的闭包是在deferproc内执行的话，这里的赋值操作会将result直接赋值，
不管闭包内对其做的任何操作，输出的结果应该为12。

来看看deferproc都做了什么

func deferproc(siz int32, fn *funcval) { // arguments of fn follow fn
    if getg().m.curg != getg() {
        // go code on the system stack can't defer
        throw("defer on system stack")
    }

    // the arguments of fn are in a perilous state. The stack map
    // for deferproc does not describe them. So we can't let garbage
    // collection or stack copying trigger until we've copied them out
    // to somewhere safe. The memmove below does that.
    // Until the copy completes, we can only call nosplit routines.
    sp := getcallersp()
    argp := uintptr(unsafe.Pointer(&fn)) + unsafe.Sizeof(fn)
    callerpc := getcallerpc()

    d := newdefer(siz)
    if d._panic != nil {
        throw("deferproc: d.panic != nil after newdefer")
    }
    d.fn = fn
    d.pc = callerpc
    d.sp = sp
    switch siz {
    case 0:
        // Do nothing.
    case sys.PtrSize:
        *(*uintptr)(deferArgs(d)) = *(*uintptr)(unsafe.Pointer(argp))
    default:
        memmove(deferArgs(d), unsafe.Pointer(argp), uintptr(siz))
    }

    // deferproc returns 0 normally.
    // a deferred func that stops a panic
    // makes the deferproc return 1.
    // the code the compiler generates always
    // checks the return value and jumps to the
    // end of the function if deferproc returns != 0.
    return0()
    // No code can go here - the C return register has
    // been set and must not be clobbered.
}

在这里并没有做闭包的调用

再看看deferreturn

func deferreturn(arg0 uintptr) {
    gp := getg()
    d := gp._defer
    if d == nil {
        return
    }
    sp := getcallersp()
    if d.sp != sp {
        return
    }

    // Moving arguments around.
    //
    // Everything called after this point must be recursively
    // nosplit because the garbage collector won't know the form
    // of the arguments until the jmpdefer can flip the PC over to
    // fn.
    switch d.siz {
    case 0:
        // Do nothing.
    case sys.PtrSize:
        *(*uintptr)(unsafe.Pointer(&arg0)) = *(*uintptr)(deferArgs(d))
    default:
        memmove(unsafe.Pointer(&arg0), deferArgs(d), uintptr(d.siz))
    }
    fn := d.fn
    d.fn = nil
    gp._defer = d.link
    freedefer(d)
    jmpdefer(fn, uintptr(unsafe.Pointer(&arg0)))
}

// asm_amd64.s

// void jmpdefer(fn, sp);
// called from deferreturn.
// 1. pop the caller
// 2. sub 5 bytes from the callers return
// 3. jmp to the argument
TEXT runtime·jmpdefer(SB), NOSPLIT, $0-16
    MOVQ    fv+0(FP), DX    // fn
    MOVQ    argp+8(FP), BX  // caller sp
    LEAQ    -8(BX), SP  // caller sp after CALL
    MOVQ    -8(SP), BP  // restore BP as if deferreturn returned (harmless if framepointers not in use)
    SUBQ    $5, (SP)    // return to CALL again
    MOVQ    0(DX), BX
    JMP BX  // but first run the deferred function

在这里才是闭包的真正调用

总结

之前一直信奉别人所说的defer执行是在作用域返回前，以为一定会在return之前执行，
经过自己的深入才发现执行的真正顺序。执行的顺序一定要去分析才能了解，
下次再去分析一下panic和defer的调用顺序。

有什么不对的地方欢迎指出