os.lstat 更适合查符号链接，因为它不跟随链接而返回链接自身的元信息，可通过 mode() & os.modesymlink 判断是否为符号链接，并需配合 os.readlink 安全获取目标路径。
os.Lstat 为什么比 os.Stat 更适合查符号链接
因为 os.Lstat 不会跟随符号链接，它返回的是链接文件本身的元信息（比如链接路径、权限、创建时间），而 os.Stat 默认会解析并返回目标文件的信息。如果你要判断一个路径是不是符号链接、或者想读取链接指向的原始路径，必须用 Lstat —— 用错就等于“看不见链接本身”。
- 常见错误现象：
os.Stat("symlink")返回目标文件的Mode()，IsDir()或IsRegular()都是目标的，不是链接的 - 使用场景：扫描目录时识别符号链接、备份工具跳过或单独处理链接、构建文件系统快照
-
Lstat返回的os.FileInfo.Mode()会包含os.ModeSymlink标志位，这是唯一可靠判断方式
怎么安全地读取符号链接的目标路径
os.Lstat 只告诉你“这是一个链接”，但不告诉你它指向哪；得配合 os.Readlink 才能拿到目标路径。两者必须一起用，缺一不可。
- 先调
Lstat，检查fi.Mode() & os.ModeSymlink != 0，再调Readlink；不能反着来，否则对非链接路径调Readlink会报invalid argument -
Readlink返回的是原始字符串（可能相对路径），不做自动解析，也不校验目标是否存在 - 注意路径拼接：如果链接内容是相对路径（如
"../data/config.json"），需用filepath.Join(filepath.Dir(linkPath), target)才能得到绝对路径
循环链接和权限问题怎么避免 panic
Lstat 本身不会因循环链接 panic，但后续 Readlink 或递归遍历时可能陷入死循环；同时，没有权限读取某些目录时，Lstat 会直接返回 error，不是 nil。
- 永远检查
Lstat的 error：常见错误是permission denied，不是no such file；别假设 “没报错=能读” - 处理循环链接：记录已访问的 inode（
sys.UnixStat().Ino）或已解析的绝对路径，重复出现就中断 - 不要在未验证前对
Readlink结果做Lstat—— 如果目标本身又是链接，且你没设深度限制，容易栈溢出或无限递归
Windows 下 os.Lstat 的行为差异
Windows 从 Vista 开始支持符号链接（需管理员权限创建），但 Go 的 os.Lstat 在 Windows 上仍可能返回不一致的 Mode()：有时 ModeSymlink 不置位，尤其对 junction 或旧式快捷方式。
立即学习“go语言免费学习笔记（深入）”；
- 跨平台代码里，不能只依赖
fi.Mode() & os.ModeSymlink判断；可加一层os.IsNotExist(err)+strings.Contains(err.Error(), "symbolic link")做兜底（不推荐，仅调试用） - 更稳的做法：用
syscall.GetFileInformationByHandle（Windows）或stat -c "%F" path（Linux/macOS）做二次确认，但会牺牲纯 Go 优势 - Go 1.22+ 对 Windows 符号链接支持更好，但默认编译下仍建议测试真实环境中的
Lstat输出
真正难的不是调用 Lstat，而是搞清你到底要“链接本身”还是“链接指向的东西”——选错一步，后面所有路径拼接、权限判断、递归逻辑都会偏航。
