能，但仅限源fd为普通文件、目标fd为socket或pipe的场景；若目标fd是普通磁盘文件，则退化为内核态复制，不满足严格零拷贝。
sendfile在Linux下能真正零拷贝吗
能，但前提是源文件是普通文件（regular file），目标fd必须是socket或另一个支持splice的文件（如pipe）。如果目标fd是普通文件（比如磁盘上的日志文件），sendfile会退化为内核态复制，不走DMA直接路径，也就不是严格意义的零拷贝——它只是省去了用户态内存拷贝，但仍在内核缓冲区间复制。
关键限制：源fd不能是socket、tty或设备文件；目标fd不能是常规磁盘文件（除非内核≥5.12且启用了CONFIG_SENDFILE增强支持，但默认仍不启用）。
怎么调用sendfile才不会返回EINVAL
sendfile失败最常见的原因是fd类型不匹配或offset参数非法。比如传入一个已关闭的fd、非阻塞socket配了超时但没处理EAGAIN、或者offset指向了文件末尾之后的位置。
- 确保源fd由
open()打开，且带O_RDONLY标志；不能是stdin（/dev/tty）或pipe - 目标fd必须是已连接的TCP socket（
SOCK_STREAM），或支持写入的pipe fd - 若传入
offset指针，它必须指向合法地址，且初始值 ≤ 文件大小；若传NULL，则从当前文件偏移开始，且会自动更新该偏移 - 注意：
sendfile不支持TLS socket（即SSL套接字），必须在TLS层之下使用
sendfile和splice+tee组合有什么实际区别
sendfile只能单向传输（file → socket），而splice+tee可实现多路复用（比如同时发给两个socket，或边转发边记录到pipe）。但splice要求至少一端是pipe，所以常见模式是：sendfile把文件写入pipe，再用splice把pipe内容分发出去。
立即学习“C++免费学习笔记（深入）”；
性能上，纯sendfile路径最短，CPU开销最小；splice链路稍长，但更灵活。glibc封装的sendfile在小文件（
示例片段（简化错误检查）：
off_t offset = 0;
ssize_t sent = sendfile(sockfd, filefd, &offset, 64 * 1024);
if (sent == -1 && errno == EAGAIN) {
// 非阻塞socket未就绪，需重试或等待epoll通知
}为什么sendfile在容器或网络命名空间里有时失效
本质是fd跨命名空间可见性问题。如果socket fd来自另一个网络命名空间（比如CNI插件创建的veth对端），而进程运行在host network namespace中，sendfile仍可工作；但如果socket属于某个隔离的netns，而调用进程没进入该netns，sendfile会因fd无效或权限不足失败（EBADF或EACCES）。
更隐蔽的问题是seccomp配置：某些容器运行时（如Docker默认profile）禁用了sendfile系统调用，此时会直接返回EPERM。检查方法是运行strace -e sendfile your_program，看是否被拦截。
另外，tmpfs或overlayfs挂载的“文件”可能不支持sendfile——它们不是真正的块设备backed文件，内核无法对其执行DMA直接传输，会fallback到普通copy。
