你正在使用哪个版本的Go( go version )?
go version go1.10 linux/amd64这个问题在最新版本中是否重现？
是的，我在 b001ffb 上尝试过。
你正在使用什么操作系统和处理器架构( go env )?
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/ainar/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/ainar/go"
GORACE=""
GOROOT="/home/ainar/go/go1.10"
GOTMPDIR=""
GOTOOLDIR="/home/ainar/go/go1.10/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build197597232=/tmp/go-build -gno-record-gcc-switches"你做了什么？
https://play.golang.org/p/Jz6y0GkqTNW
你期望看到什么？
要么
direct: main.go:11
deferred: main.go:10要么文档中的 runtime.Caller 提到延迟函数的行号指向 return 之后的行。
你看到了什么？
direct: main.go:11
deferred: main.go:12并且在 runtime.Caller 或 runtime.Callers 文档中没有提到 defer 。
我理解为什么会这样，甚至创建了一个奇怪的解决方法( on Russian SO , on Playground )。但我认为在函数文档中提及这种行为及其基本原因会很好。
4条答案
按热度按时间ftf50wuq1#
简要记录这个是可以的。我只是想评论一下，我认为当前的行为是有道理的。延迟函数在defer语句的点上不会被调用。这就是调用被推迟的地方，而不是它被做出的地方。延迟函数实际上是在推迟函数返回的时候被调用的。这就是
runtime.Caller报告的内容。shstlldc2#
关于
panic的情况呢？例如 https://play.golang.org/p/LcG_3IOEyr7。我希望deferred能打印出panic被调用的行，类似于return。但它却打印出了asm_amd64.s:459,这似乎并没有什么帮助。这里的行为对于
Caller是否已经定义好了呢？我应该为它单独报告一个问题吗？tnkciper3#
我必须同意打印
asm_amd64.s:459是毫无意义的。如果我们可以，应该修复它。bq3bfh9z4#
关于恐慌的一个问题。