/proc/self/fd/N 链接不一定可读：需进程仍持有fd、目标文件未被彻底删除、且调用者有/proc访问权限；readlink可能因ENOENT、EACCES或EINVAL失败。
/proc/self/fd/N 链接是否一定可读？
不是。/proc/self/fd/N 是符号链接，但readlink能否成功取决于三件事：进程是否仍持有该 fd、目标文件是否被删除、以及调用者是否有权限访问 /proc。
常见错误现象：readlink 返回 -1，errno 为 ENOENT（文件已关闭或路径失效）、EACCES（无 /proc 访问权限，比如容器中被限制）、EINVAL（fd 无效，如标准输入重定向到管道时 fd 指向匿名 inode）。
- 使用场景：调试时想确认某 fd 对应哪个文件；日志模块记录打开的配置文件路径；安全审计中验证 fd 来源
- 不要假设
readlink总能返回有意义字符串——比如 socket、eventfd、/dev/zero、memfd_create 创建的内存文件，都会指向socket:[...]或anon_inode:[...] - 务必检查返回值和
errno，不能只看缓冲区内容是否非空
readlink 的缓冲区大小怎么设才安全？
Linux 中路径最大长度是 PATH_MAX（通常 4096），但 /proc/self/fd/<code>N 的目标路径可能含大量嵌套符号链接，内核实际写入长度可能接近 PATH_MAX，且末尾需留 \0 空间。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::vector<char> buf(PATH_MAX + 1)</char>分配缓冲区，比固定栈数组更稳妥（避免栈溢出） - 调用前清零：`buf[0] = '\0'`，防止
readlink失败时残留旧数据被误当字符串 - 若返回值等于
PATH_MAX，说明缓冲区可能不足（虽然罕见），此时可考虑重试或截断处理，而非直接报错 - 别用
sizeof(buf)当长度传给readlink——容易传错，显式写buf.size() - 1
获取的路径是相对还是绝对？是否带解引用？
readlink 从 /proc/self/fd/<code>N 返回的是**已解析的绝对路径**，即内核自动展开所有符号链接后的最终路径（类似 realpath 效果），但不保证该路径当前仍可访问（比如原文件已被 unlink）。
关键细节：
- 如果 fd 指向一个被
unlink后未关闭的文件，readlink仍会返回原路径（如/tmp/foo (deleted)），括号里标注(deleted)是内核加的提示，不是路径一部分 - 路径不含 shell 层面的 ~、$HOME 展开，也不含当前工作目录隐式拼接——它就是 VFS 层看到的完整 dentry 路径
- 对 bind mount 或 overlayfs，返回的是挂载点下的路径，不是原始底层路径；对 namespace 隔离环境（如容器），返回的是该进程视角下的路径
C++ 封装时要不要用 std::filesystem::path？
可以，但要注意它不解决核心问题：路径有效性仍是运行时判断，且 std::filesystem 在旧 glibc 或交叉编译环境下可能不可用。
更务实的做法：
- 先用
readlink拿到 C 风格字符串，再按需构造std::string或std::filesystem::path - 别依赖
std::filesystem::exists()验证结果——它可能返回 false（因为文件已删），但这不影响你记录“当时打开的是这个路径” - 若需兼容 C++11，直接用
std::string+c_str()即可，std::filesystem不是必须项 - 注意：
std::filesystem::path构造函数不会做任何系统调用，只是字符串包装，性能无影响
真正容易被忽略的是：/proc 下的 fd 符号链接本身可能因进程退出、fd 关闭、或 /proc 被 umount 而瞬间失效——所以拿到路径后若需进一步操作（比如 openat），得重新校验，不能当作长期有效的句柄。
