os.stat 总是返回目标文件信息，因其底层调用 posix stat(2) 系统调用，默认解析符号链接；要判断路径是否为软链接，必须使用 os.lstat 并检查 fi.mode() & os.modesymlink != 0。
os.Stat 为什么总是返回目标文件信息
因为 os.Stat 底层调用的是 POSIX stat(2) 系统调用，它默认解析符号链接并返回目标路径的元数据。这不是 Go 的“智能判断”，而是操作系统行为——只要软链接最终指向一个存在的文件或目录，os.Stat 就成功；如果目标被删了，就直接报 os.ErrNotExist。
常见错误现象：os.Stat("/path/to/symlink") 返回的是目标文件的 Size() 和 ModTime()，你以为在查链接本身，其实查的是它指向的东西。更危险的是，你根本无法从 os.Stat 结果里看出“这是个软链接”。
所以：想确认某个路径是不是软链接，os.Stat 完全不可靠；必须换 os.Lstat。
怎么可靠判断一个路径是软链接
os.Lstat 是唯一可信方式——它只读取路径自身的 inode 元数据，不解析链接内容。调用后检查 fi.Mode() & os.ModeSymlink != 0 才能确定。
实操建议：
- 永远先
fi, err := os.Lstat(path)，再判断err == nil和fi.Mode() & os.ModeSymlink != 0 - 在 rootless 容器或只读挂载点上，
os.Lstat可能因权限失败，需用os.IsPermission(err)做降级处理 - Windows 上若软链接指向不存在的目标，
os.Lstat可能返回file does not exist，而不是明确的链接类型信息 - 别依赖
fi.Size()或fi.ModTime()判断目标状态——它们反映的是软链接自身的字节数和修改时间（即最后一次ln -sf的时间）
如何安全展开多级软链接链
Go 没有内置递归展开函数，filepath.EvalSymlinks 虽然方便，但要求路径**必须存在且可访问**，且不防环路、不支持部分展开——传入循环链接会 panic。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
手动展开的关键点：
- 第一步永远是
os.Lstat(path)，确认是软链接 - 第二步用
os.Readlink(path)拿到原始字符串，再用filepath.Join(filepath.Dir(path), linkTarget)构造下一级真实路径——注意：不能直接对os.Readlink返回值调filepath.Abs，它是相对于链接所在目录的相对路径 - 必须维护已访问路径集合（如
map[string]bool），每次拼出绝对路径后存进去，避免 A→B→A 死循环 - 每轮都要重新
os.Lstat检查新路径是否仍是软链接，直到不是为止
filepath.EvalSymlinks 的真实用途和陷阱
filepath.EvalSymlinks 只做一件事：把路径里所有软链接逐级展开，返回最终物理路径。但它不做任何安全校验——如果你传入 /var/www/uploads/link_to_etc_passwd，它真就给你返回 /etc/passwd。
它适合的场景很窄：
- 路径已知存在且可信（比如配置文件中硬编码的路径）
- 你只需要“规范化路径字符串”，不关心是否越界或是否在白名单内
- 你确定不会遇到循环链接（否则 panic）
容易忽略的细节：
- 顺序不能错：必须先
filepath.Abs得到规范绝对路径，再传给filepath.EvalSymlinks；否则相对路径可能找不到起点 - Windows 上对 junction、hard link 支持有限，可能静默失败
- 它不处理权限问题——路径存在但无读权限时，
EvalSymlinks仍会失败
真正要防越界、做白名单校验时，必须自己走 Lstat → Readlink → Join → Abs → 比对根目录 这套流程，不能图省事全交给 EvalSymlinks。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
