GetModuleFileNameW(NULL, buf, size) 是 Windows 下获取可执行文件绝对路径最可靠方法，返回含盘符和反斜杠的宽字符路径，需检查返回值并确保缓冲区足够；Linux 用 readlink("/proc/self/exe")，macOS 优先用 _NSGetExecutablePath。
Windows 下用 GetModuleFileNameW 获取可执行文件路径
Windows 不提供直接获取“当前工作目录下程序路径”的标准 API，argv[0] 可能是相对路径、无扩展名、甚至被篡改；真正可靠的是查加载的模块句柄。GetModuleFileNameW 传入 NULL（即主模块）能拿到完整绝对路径，且自动处理重定向和符号链接。
关键点：必须用宽字符版本（W 后缀），否则遇到中文路径会截断或乱码；返回值需检查是否为 0，失败时路径为空。
- 调用前确保
buffer至少有MAX_PATH（260）或更安全地用MAX_PATH * 2宽字符空间 - 返回路径含驱动器盘符和反斜杠（
），如L"C:\MyApp\app.exe" - 若程序被硬链接或从快捷方式启动，该函数仍返回真实磁盘路径，不是快捷方式目标
Linux/macOS 下用 /proc/self/exe 符号链接读取
Linux 和 macOS（自 10.10+）都支持通过 /proc/self/exe 这个符号链接拿到当前进程的可执行文件绝对路径。它比 argv[0] 可靠得多——即使程序被 chdir 过、argv[0] 被设为破路径，这个链接依然有效。
注意：readlink 返回的是原始路径，可能含 .. 或软链中间段，不等于“规范化”结果；而且 /proc 是 Linux 特有，macOS 对应路径是 /proc/self/path/a.out（仅部分版本支持），更稳妥的做法是用 _NSGetExecutablePath（macOS）。
立即学习“C++免费学习笔记（深入）”；
- Linux 示例：
char path[PATH_MAX]; ssize_t len = readlink("/proc/self/exe", path, sizeof(path)-1);，成功后需手动加 - macOS 应优先用
_NSGetExecutablePath(path, &size)，失败时再 fallback 到getcwd+argv[0]拼接（不推荐但有时不得不做） - 返回路径可能是软链接目标，不代表你启动时敲的那个路径；如需原始调用路径，得自己保存
argv[0]并手动 resolve
跨平台规范化斜杠：别用 std::filesystem::path 的 generic_string()
C++17 的 std::filesystem::path 看似能一劳永逸，但它的 generic_string() 实际只是把内部存储的分隔符统一成 /，并不做路径标准化（比如合并 foo/../bar）；而 lexically_normal() 才是真归一化，但它不处理符号链接解析，也不保证路径存在。
更现实的问题是：Windows 上 std::filesystem 在旧 MSVC（如 VS2017）默认未启用，需手动定义 _HAS_FILESYSTEM=1 且链接 libstdc++fs（GCC）或启用 C++17 标准库模块（MSVC）。线上环境兼容性风险不小。
- 安全做法：先用平台 API 拿到原始绝对路径字符串，再用
std::replace把\换成/（Windows）或忽略（Unix 类系统） - 若需真正“规范”（去
.、压平..、展开软链），Linux 应调用realpath()，Windows 用PathCchCanonicalize（Win10+）或自己写简易逻辑 - 不要依赖
std::filesystem::current_path()—— 它返回的是进程当前工作目录，不是程序所在目录
常见错误现象：argv[0] 为什么不能直接用
很多代码直接拿 argv[0] 然后调 std::filesystem::absolute()，结果在不同场景下崩得五花八门：服务模式下 argv[0] 是空字符串；容器里可能只有二进制名没路径；用 execvpe 启动时甚至可以被任意伪造。它根本不是“程序位置”，只是“启动时用户输入的第一段字符串”。
- 现象：程序在桌面双击正常，但用任务计划程序启动时报 “No such file or directory”
- 现象：Docker 中运行时，
argv[0] == "./myapp"，但当前目录是/，拼出来就是/./myapp，根本不存在 - 现象：Linux 下用
ln -s /opt/app/myapp /usr/bin/myapp，argv[0]是/usr/bin/myapp，但实际要找配置文件得去/opt/app/
路径这件事，操作系统层面就分“执行路径”和“工作路径”，混用等于给自己埋雷。真正要读同目录下的 config.json，必须先拿到可执行文件的绝对路径，再做 parent_path()，而不是信 argv[0] 或 getcwd()。
