Windows下GetFileAttributes无法识别.lnk快捷方式，需先用PathFindExtension检查扩展名是否为".lnk"（大小写不敏感），再通过CoCreateInstance与IPersistFile::Load尝试加载验证。
Windows下用GetFileAttributes判断是否为快捷方式
GetFileAttributes 本身不能识别.lnk文件是否是快捷方式——它只返回普通文件属性。真正可靠的方式是检查后缀并尝试解析：PathIsRelative没用，GetShortPathName也不行。必须结合文件扩展名和COM接口。
- 快捷方式在Windows上本质是
.lnk文件，不是文件系统层面的“链接类型”，所以GetFileAttributes返回FILE_ATTRIBUTE_NORMAL或FILE_ATTRIBUTE_READONLY都正常，无法据此判断 - 正确做法：先用
PathFindExtension检查路径扩展名是否为".lnk"（注意大小写不敏感） - 若是
.lnk，再用CoCreateInstance+IPersistFile::Load尝试加载，能成功加载即确认为有效快捷方式（避免伪造后缀） - 不要依赖
GetFileType或GetFinalPathNameByHandle，它们对.lnk文件返回目标文件信息，而非快捷方式自身
Linux/macOS用lstat判断是否为软链接
lstat 是唯一安全可靠的手段。用stat会自动跟随链接，失去判断依据；而lstat读取的是链接文件自身的元数据。
- 调用
lstat(path.c_str(), &st)后，检查st.st_mode & S_IFLNK是否非零 - 注意：
lstat在路径不存在时返回-1且errno == ENOENT，需先确保路径存在（可用access(path.c_str(), F_OK)预检，但有竞态，生产环境建议直接处理lstat错误） -
readlink可用于获取目标路径，但它不判断类型，仅当lstat确认是S_IFLNK后再调用 - 不要用
std::filesystem::is_symlink（C++17），它底层就是封装lstat，但某些旧libstdc++版本有bug，绕过它直接调用更可控
C++跨平台统一判断的常见误操作
很多人试图用std::filesystem::is_symlink覆盖所有情况，但它在Windows上永远返回false——因为Windows原生不支持POSIX软链接（除非启用了开发者模式并创建了mklink /D链接，且程序有权限）。而.lnk文件根本不在其检测范围内。
- Windows快捷方式（.lnk）和Unix软链接（symlink）是两类完全不同的机制，没有通用API能一并识别
- 不要写“if is_symlink || has_extension(".lnk")”这种逻辑：前者在Windows多数情况下失效，后者在Linux可能误判普通文本文件
- 真正跨平台的方案只能是运行时检测OS：
#ifdef _WIN32走.lnk路径解析，#else走lstat -
std::filesystem::status在Windows上对.lnk返回file_status(type::regular)，毫无区分度，别信它
为什么GetFinalPathNameByHandle不能用于判断快捷方式
GetFinalPathNameByHandle 的设计目标是获取“最终路径”，它会对.lnk文件自动解析并返回目标路径字符串——但这个行为掩盖了原始路径性质。
立即学习“C++免费学习笔记（深入）”；
- 即使传入一个.lnk文件的句柄，它也只返回目标路径，不提供“我刚解析了一个.lnk”的任何标识
- 如果目标路径本身也是.lnk（嵌套快捷方式），它仍只返回最末端路径，中间层级完全丢失
- 更糟的是：若.lnk指向不存在的位置，该函数可能失败（
ERROR_FILE_NOT_FOUND），但你无法区分是.lnk损坏，还是目标路径临时不可达 - 它适合路径规范化，不适合类型判断。要用就配合
GetFileAttributesEx查原始文件属性，再自己比对扩展名
实际项目里最容易被忽略的点是：把“快捷方式”和“符号链接”当成同一抽象来处理。它们连错误码语义都不一致——lstat失败可能是权限不足，而IPersistFile::Load失败可能是COM未初始化或.lnk格式损坏。得按机制分治，不能偷懒统一兜底。
