pread线程安全但需独立缓冲区、确定offset、检查返回值及errno64位offset需编译宏或pread64小块随机读用pread高频连续读宜用mmap。pread 本身线程安全但文件偏移和缓冲区共享会破坏它pread 确实不修改文件描述符的当前偏移lseek 不影响它调用之间互不干扰——这是它比 read 更适合多线程的关键。但很多人一上手就错在用同一个 char* 缓冲区被多个线程同时写入或者把 offset 算错了比如基于共享变量递增没加锁。结果不是数据错位就是读到一半被覆盖。实操建议立即学习“C免费学习笔记深入”每个线程必须使用**独立分配的缓冲区**别共用全局 buffer 或栈上同一块内存offset 值要由调用方完全确定不能依赖 lseek(fd, 0, SEEK_CUR) 或其他可能被并发干扰的状态如果 offset 来自某个“任务队列”确保队列分发逻辑是线程安全的比如用 std::queue std::mutex或无锁结构不要在 pread 前后对同一 fd 调用 lseek、write、truncate 等可能改变文件状态的操作——虽然 pread 不改偏移但这些操作会影响其他线程对文件长度/内容的预期pread 返回值和 errno 必须每次都检查尤其 EINTR 和 EINVALLinux 下 pread 可能因信号中断返回 -1 并置 errno EINTR也常因传入负 offset 或超出文件大小返回 EINVAL。不检查就直接 memcpy轻则读到垃圾数据重则 core dump。实操建议立即学习“C免费学习笔记深入”永远用 ssize_t n pread(fd, buf, count, offset); 接收返回值别用 int检查 n -1 后立刻判断 errnoif (errno EINTR) continue;重试else if (errno EINVAL) 就该打日志并跳过该 offset注意 n 0 表示已到 EOF哪怕 offset 在文件末尾不是错误但 n 0 才表示成功读取了对应字节数别假设 count 一定能读满——即使 offset 合法且文件足够长内核也可能只返回部分数据比如磁盘 I/O 暂时受限64 位 offset 需要 __off64_t 和 pread64glibc 版本和编译选项有坑Linux 默认 pread 的 off_t 是 32 位在某些旧系统或未定义宏的编译环境下超过 2GB 的文件 offset 会被截断。直接传一个 uint64_t offset 0x100000000ULL进去就变 0读的全是开头。 文小言 百度旗下新搜索智能助手有问题问小言。