Go 语言无法直接获取当前文件名，必须通过 runtime.Caller(0) 获取调用点的 file 字段并用 filepath.Base 提取，因其无类似 file 的全局变量，且该方式受符号剥离、内联优化和 CGO 影响，需检查 ok 返回值确保可靠性。
Go 语言里 runtime 无法直接获取当前文件名，runtime 包不提供文件路径相关功能 —— 这是设计使然，不是漏掉了什么。
为什么 runtime.Caller 是唯一靠谱的起点
Go 没有类似 Python 的 __file__ 或 Node.js 的 __filename 全局变量。要拿到当前文件名，必须靠运行时栈帧反查：调用 runtime.Caller 获取调用者（即当前函数）的源码位置，再解析 file 字段。
-
runtime.Caller(0)返回的是当前函数调用点的位置（即这行代码所在文件和行号） -
runtime.Caller(1)才是上一层调用者，常用于日志封装等场景 - 返回的
file是绝对路径，需用filepath.Base(file)提取文件名 - 注意：如果二进制被移动或通过 symlink 启动，
file仍是编译时的绝对路径（Go 1.21+ 仍如此，无运行时重映射）
runtime.Caller 在 CGO 或内联函数中可能失效
当代码涉及 CGO、编译器内联（如小函数被 //go:noinline 以外的默认优化内联），runtime.Caller 可能跳过预期帧，导致 file 指向非预期源文件（比如标准库或生成代码）。
- 加
//go:noinline可强制保留栈帧，但会牺牲一点性能 - 在
init()函数中调用runtime.Caller(0)是安全的；但在go语句启动的 goroutine 初始函数中，需确认是否被调度器延迟执行而影响帧定位 - 交叉编译目标平台（如 macOS 编译 Linux 二进制）不影响
Caller行为，但file路径仍是构建机上的路径
别用 os.Args[0] 或 exec.LookPath 替代
os.Args[0] 是可执行文件路径，不是 Go 源文件名；exec.LookPath 查的是 PATH 中的同名程序，和当前 .go 文件完全无关 —— 这俩和「当前文件名」问题根本不匹配，属于典型误用。
立即学习“go语言免费学习笔记（深入）”；
- 有人试图用
debug.ReadBuildInfo()解析Settings获取vcs.revision，但这只对模块化项目且启用 vcs 有效，且不包含文件名 - 硬编码
"main.go"或依赖GOFILE环境变量都不可靠：前者错失包内其他文件，后者仅在go run时由 go 命令注入，go build && ./a.out场景下为空 - 真正稳定的做法只有
runtime.Caller+filepath.Base组合，没有捷径
文件名这种信息本质是调试/可观测性需求，不是运行时逻辑依赖项；只要接受它来自栈帧而非元数据，就很少踩坑。最易忽略的是：没检查 runtime.Caller 返回的 ok 布尔值 —— 在极少数环境（如某些 wasm 运行时或 stripped 二进制）下它可能为 false，直接 panic。
