GetModuleFileNameA(NULL, path, MAX_PATH)可安全获取当前exe完整路径；须传NULL、提供足够缓冲区并检查返回值，避免截断或失败。
Windows下用GetModuleFileName获取可执行路径
在Windows平台，GetModuleFileName是最直接可靠的方式，它能返回当前进程主模块（即.exe文件）的完整路径。注意必须传入NULL作为第一个参数，表示获取当前模块；第二个参数需提供足够大的缓冲区（建议至少MAX_PATH字节），第三个参数是缓冲区大小。
常见错误是传入错误的模块句柄（比如用GetModuleHandle(NULL)再传给GetModuleFileName），其实直接传NULL更安全；另一个坑是没检查返回值——如果返回0或超过缓冲区长度，说明失败或截断，此时不应直接截取字符串。
示例关键片段：
char path[MAX_PATH] = {0};
DWORD len = GetModuleFileNameA(NULL, path, MAX_PATH);
if (len > 0 && len < MAX_PATH) {
// 成功，path包含完整路径
}
Linux/macOS用/proc/self/exe或_NSGetExecutablePath
Linux下标准做法是读取/proc/self/exe这个符号链接，它始终指向当前进程的可执行文件。用readlink即可获取路径，但要注意：返回值是字节数，不是null终止字符串，必须手动补 ；且/proc不是所有环境都可用（如容器中可能被挂载限制）。
立即学习“C++免费学习笔记（深入）”；
macOS不支持/proc，得用_NSGetExecutablePath（定义在<mach-o></mach-o>中），它会返回真实路径或带@executable_path的相对路径；首次调用时需传入足够大的缓冲区并检查返回的size，可能需要重试。
关键差异点：
-
readlink返回的是符号链接目标，可能含软链跳转；_NSGetExecutablePath返回的是解析后的绝对路径（除非沙盒限制） - 两者都不保证路径末尾有斜杠，提取目录需自行
dirname或查找最后一个/
跨平台封装时绕过argv[0]的陷阱
很多人第一反应是用argv[0]，但它不可靠：可能是相对路径、无路径的文件名（如只传了./myapp或myapp），甚至被篡改过。POSIX也不保证argv[0]指向实际可执行文件。
真正跨平台的稳健方案是条件编译+各自系统API：
- Windows走
GetModuleFileName - Linux走
readlink("/proc/self/exe", ...) - macOS走
_NSGetExecutablePath - 其他Unix-like系统（如FreeBSD）可fallback到
getprogname()或realpath(argv[0], ...)，但后者仍有argv[0]缺陷
别忘了处理路径分隔符：Windows用\，其他系统用/，提取目录时建议统一用/做strrchr查找，再用std::string::substr截取，避免依赖平台特定函数。
提取目录路径时小心路径结尾和符号链接
拿到完整可执行路径后，提取“所在目录”看似简单，实则有两个易忽略点：一是路径末尾可能带/或\，二是该路径可能是符号链接，而你真正想要的是链接指向的目录（还是链接本身的父目录？）
例如/usr/local/bin/myapp是链接到/opt/myapp/bin/myapp，调用dirname得到的是/usr/local/bin，但程序资源可能放在/opt/myapp/res。这时候是否需要realpath取决于你的用途——配置文件加载通常要真实位置，而日志写入可能按启动路径更合理。
实操建议：
- 先用
strrchr找最后一个/或\，截取前缀 - 若需真实路径，Linux/macOS上对结果再调用
realpath；Windows可用GetFullPathName - 不要假设路径一定存在或可读，后续打开文件前仍要检查
最麻烦的其实是容器、chroot、flatpak等环境，/proc/self/exe可能不可读，GetModuleFileName在某些沙盒里也会失败——这种场景下，退回到argv[0] + 当前工作目录拼接，反而更实用，尽管不完美。
