readlink()返回值不能直接当字符串用，因为它不自动添加' '终止符，仅返回字节数；需手动检查返回值len>0后执行buf[len]=' '，再使用。
readlink("/proc/self/exe") 返回值为什么不能直接当字符串用
因为 readlink 不会自动在缓冲区末尾写 ' '，它只返回实际读到的字节数（不含终止符）。如果直接用 std::string(buf) 或 printf("%s", buf)，可能触发越界读或输出乱码——尤其当缓冲区里残留旧数据时。
正确做法是手动补 ' '：
- 检查返回值
len：必须 > 0 才有效；len == -1表示失败（如权限不足、/proc 未挂载），len == 0极少见，但也要处理 - 确保缓冲区有至少 1 字节空余：
readlink(path, buf, sizeof(buf) - 1) - 写入终止符：
buf[len] = ' '，之后再转std::string或 C 字符串操作
缓冲区大小设多大才安全
PATH_MAX 看起来合理，但实际不保险：Linux 内核对路径长度限制是 4096 字节（MAX_PATH 宏通常定义为此值），但某些容器环境或精简系统可能禁用 /proc，或路径本身含大量符号链接未展开——此时 readlink 返回的是原始链接目标，未必是最终绝对路径。
更稳妥的做法：
- 用
std::vector<char> buf(4096)</char>替代固定栈数组，避免栈溢出 - 若返回值等于缓冲区大小减 1（即
len == buf.size() - 1），说明可能被截断，应扩容重试（比如翻倍再调一次） - 不要依赖
getcwd()或pwd命令作 fallback，它们返回的是进程当前工作目录，不是可执行文件所在目录
为什么 std::filesystem::read_symlink 在这里容易失败
很多新项目习惯用 std::filesystem::read_symlink 替代原始 readlink，但在 Linux 下它底层仍调用 readlink 系统调用。问题出在标准库实现差异：
- C++17 标准未规定其行为对
/proc/self/exe这类特殊伪文件的支持程度 - 某些 libc 实现（如 musl）或旧版 libstdc++ 可能对
/proc路径做额外校验，导致抛出std::filesystem::filesystem_error - 而原生
readlink是内核直通接口，只要/proc/self/exe可读，就一定成功
所以生产环境建议坚持用 readlink + 手动缓冲区管理，别图省事换封装。
获取目录而非完整路径时要注意路径分隔符
从 /proc/self/exe 得到的是完整可执行文件路径（如 /home/user/app/bin/myapp），要提取目录需找最后一个 '/'。但别用 strrchr 或 std::string::find_last_of("/") 就完事——Linux 下路径分隔符只有 '/'，但代码可能跑在 WSL 或混合环境中，有人会误写成 '\'。
实操要点：
- 明确只搜索
'/'，Windows 兼容逻辑应单独处理，不要混在一起 - 注意边界：如果路径是
/myapp，find_last_of('/') == 0，substr(0, 0)返回空串，需判断是否为根目录 - 避免用
dirname()函数：它修改原缓冲区，且线程不安全；C++ 中优先用std::string操作
最易忽略的一点：/proc/self/exe 指向的是“被 exec 的那个文件”，如果程序是通过硬链接启动的，或者用了 LD_PRELOAD 注入，路径仍是原始可执行文件位置，不是 symlink 自身路径——这点和 shell 脚本里的 $(readlink -f "$0") 本质不同。
