必须检查 open() 返回值并循环 read() 以确保读满字节数；推荐用 O_RDONLY | O_CLOEXEC 打开 /dev/urandom，避免 fopen()/fread()/std::ifstream；每次需随机数时应 open+read+close。
open() 读取 /dev/urandom 前必须检查返回值
Linux 下 /dev/urandom 是字符设备文件，不是普通文件，open() 失败很常见——比如权限不足、内核禁用该接口（少见但存在）、或路径拼错。不检查 open() 返回值直接 read()，会导致对 -1 调用 read()，触发 EBADF 错误，程序可能静默出错或崩溃。
- 始终判断
open()返回值是否为-1，并用perror()或strerror(errno)查原因 - 推荐用
O_RDONLY | O_CLOEXEC标志打开，避免 fd 泄露到子进程 - 不要用
fopen()—— 它在某些嵌入式 libc（如 musl）里对设备文件行为不稳定，open()/read()更底层、更可控
read() 返回值小于请求字节数 ≠ 错误
对 /dev/urandom 调用 read() 时，即使设备就绪，也**可能返回比预期少的字节数**（例如请求 8 字节，只读到 4）。这不是错误，是内核的正常行为，尤其在高并发或低熵初期（极罕见），read() 不保证原子完成。
- 必须循环调用
read()直到累计读满所需字节数，或遇到EINTR/EAGAIN（后者几乎不会出现在/dev/urandom） - 忽略
EINTR并重试；若返回 0，说明已 EOF（理论上/dev/urandom不会返回 0，但健壮代码应处理） - 别用
fread()封装 —— 它内部不重试短读，容易拿到不完整随机数据
别把 /dev/urandom 当成“一次初始化、长期复用”的资源
有人习惯在程序启动时 open() 一次，存个全局 fd，后续反复 read()。这在大多数场景可行，但有隐性风险：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- fd 可能被意外
close()或被子进程继承后关闭（尤其用了fork()但没设O_CLOEXEC） - 长期运行的服务若 fork 多次，未设
O_CLOEXEC的 fd 会累积泄露，最终耗尽 fd 限额 - 某些容器环境（如 rootless Podman）会对 /dev 下设备节点做挂载限制，运行中设备节点可能失效
- 更稳妥的做法：每次需要随机数时
open()+read()+close()，开销极小，语义清晰
C++ 中用 std::ifstream 读 /dev/urandom 会失败
std::ifstream 底层依赖 fopen() 和 fread()，而 /dev/urandom 不支持 fseek()、ftell() 等流操作，部分 libc 实现会在构造时尝试探测文件大小或 seek 到末尾，导致 is_open() == false 或读取为空。
立即学习“C++免费学习笔记（深入）”；
- 绝对不要写
std::ifstream ifs("/dev/urandom"); - 如果坚持用 C++ 流风格，可封装一层：用
open()获取 fd，再用fdopen()转成FILE*，最后用std::istream绑定（但绕路且增加出错点） - 最简方案：老老实实用
int fd = open("/dev/urandom", O_RDONLY | O_CLOEXEC);配合read()循环
真正麻烦的从来不是怎么读，而是忘记检查 open() 是否成功、或以为 read() 一定读够字节数。这两个点一旦漏掉，在生产环境里可能表现为偶发密钥弱、token 可预测，但日志里连错误痕迹都没有。
