os.Stat 默认跟随软链接因其调用 POSIX stat(2) 系统调用，直接返回目标文件元数据；os.Lstat 不跟随，可检测链接本身；安全展开需手动循环 Lstat/Readlink 并防环路。
Go 语言里“软链接追踪”不是自动发生的，而是由你显式选择是否跟随、何时跟随、怎么防止循环——os.Stat 默认跟随，os.Lstat 不跟随，仅此而已。没有隐藏逻辑，也没有中间层自动解析。
为什么 os.Stat 会“自动追踪”软链接
os.Stat 底层调用的是 POSIX stat(2) 系统调用，它默认解析符号链接并返回目标文件的元数据。这不是 Go 的设计选择，是操作系统行为。只要路径最终指向一个存在的文件或目录，os.Stat 就成功；如果目标被删了，就报 os.ErrNotExist。
- 常见错误现象：
os.Stat("/path/to/symlink")返回目标文件的Size()和ModTime()，你以为在查链接本身，其实查的是它指向的东西 - 想确认某个路径是不是软链接？不能靠
os.Stat—— 它永远不告诉你“这是个链接”，只会告诉你“它指向什么” - 跨平台一致性：Linux/macOS/WSL2 下行为一致；Windows 上若链接无效或权限不足，
os.Stat可能直接失败而非返回目标信息
如何安全地展开软链接链（含多级）
Go 没有内置递归展开函数，必须手动循环调用 os.Lstat + os.Readlink，每次拼接新路径后重新检查。关键点是：路径必须相对于当前链接所在目录解析，且要防环路。
- 第一步永远是
os.Lstat(path)，判断fi.Mode() & os.ModeSymlink != 0 - 第二步用
os.Readlink(path)拿到原始字符串，再用filepath.Join(filepath.Dir(path), linkTarget)构造下一级真实路径 - 必须维护已访问路径集合（如
map[string]bool），把每次展开后的绝对路径存进去，避免A → B → A死循环 - 别用
filepath.Abs直接处理os.Readlink返回值——它可能是相对路径，filepath.Abs会按当前工作目录算，而软链接的相对路径是相对于它自身所在目录
filepath.EvalSymlinks 是最简方案，但有硬限制
filepath.EvalSymlinks 看起来是“一键展开”，但它要求路径**必须存在且可访问**，且不处理循环引用（直接 panic），也不支持部分展开（比如只展开前两级）。
立即学习“go语言免费学习笔记（深入）”；
- 它内部先做
filepath.Abs，再逐级os.Readlink+filepath.Join，最后os.Stat校验终点是否存在 - 失败场景很常见：链接指向不存在的路径、某一级权限被拒、路径中含 Windows junction（它不识别）、容器里挂载的 overlayfs 禁用了
symfollow - 不要把它当“安全替代品”：如果只是想判断链接是否有效，
os.Lstat+os.Stat目标路径更轻量、可控 - Windows 上对 NTFS 符号链接有效，但对
.lnk快捷方式或目录 junction 完全无效
遍历时要不要跟随软链接，取决于你的工具定位
filepath.Walk 默认不跟随，filepath.WalkDir（Go 1.16+）给你控制权——但“跟随”不是加个 flag 就完事，得自己处理路径构造、环路、权限和错误传播。
- 用
filepath.WalkDir时，拿到fs.DirEntry后先entry.Type() & os.ModeSymlink != 0判断，再os.Readlink+filepath.Join构造目标路径 - 想进软链接指向的目录？得确保目标是目录类型（
os.Stat(target).IsDir()），否则跳过或报错 - 错误处理不能只看
err != nil：比如os.Readlink失败可能因为权限不足，此时应记录警告但继续遍历其他项；而os.Stat目标失败则大概率说明链接已损坏 - 性能敏感场景（如扫描百万小文件），避免在每次回调里重复
filepath.EvalSymlinks——它内部做了多次系统调用，开销远大于一次os.Lstat+ 一次os.Readlink
软链接不是透明代理，它是带语义的文件系统对象。你写的每行路径处理代码，都要明确回答一个问题：“我现在操作的是链接本身，还是它背后的东西？”漏掉这个判断，后面所有逻辑都可能跑偏。
