Windows 不支持 sys/epoll.h，因其无 epoll 内核机制；等效方案为 IOCP，跨平台应使用 libuv 或 Boost.Asio 等抽象库，而非直接移植。
sys/epoll.h 是 Linux 专有的 I/O 多路复用头文件，Windows 原生不提供，也不支持 epoll。直接在 Windows 上编译含该头文件的代码必然报错 —— 这不是配置问题，而是系统能力缺失。
为什么 Windows 编译不过 sys/epoll.h
Linux 的 epoll 属于内核级事件通知机制，依赖特定的 syscall 和内核数据结构；Windows 没有对应实现，Win32 API 中等效的是 IOCP（完成端口），而 MinGW/MSVC 默认都不暴露 epoll 兼容层。即使你手动把 Linux 头文件拷进项目，也无法链接到实际函数，更会因类型、宏、函数签名不匹配导致后续编译失败。
跨平台替换方案：优先用 std::filesystem + std::thread + select() 或抽象库
不要尝试“移植 epoll 到 Windows”，应重构或封装 I/O 等待逻辑。常见可行路径：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 对简单场景（如监听少量 socket）：用 POSIX 标准的
select()—— Windows 的 MSVC 和 MinGW 都支持，只需包含winsock2.h并初始化 Winsock；注意select()有 FD_SETSIZE 限制（通常 64），且性能随连接数线性下降 - 对高性能服务：用跨平台网络库封装，如
libuv、Boost.Asio或POCO。它们内部自动路由：Linux 走epoll，Windows 走IOCP或WSAPoll，上层 API 统一 - 避免手写平台判断：别在业务代码里写
#ifdef _WIN32 ... #else ... epoll_wait() ... #endif，容易漏掉初始化、清理、错误码转换等细节；应提取为独立模块，比如EventLoop类，只暴露add_fd()、run_once()等接口
CMake 中如何安全屏蔽或条件引入
若代码中已存在 #include <sys/epoll.h>，不能靠 -I 加路径解决。正确做法是让构建系统阻止它被包含：
立即学习“C++免费学习笔记（深入）”；
- 在
CMakeLists.txt中加编译定义：target_compile_definitions(your_target PRIVATE EPOLL_UNAVAILABLE) - 在对应源文件顶部加保护：
#if defined(EPOLL_UNAVAILABLE) || defined(_WIN32) #error "epoll is not available on this platform" #endif #include <sys/epoll.h>
- 更稳妥的是用 CMake 的
check_include_file自动探测，并配合configure_file生成平台适配的头文件，把epoll相关逻辑隔离到 .cpp 文件中，头文件只声明抽象接口
最容易被忽略的点
很多人改完头文件就以为搞定，但漏掉了三件事：一是 Windows 下所有 socket 操作前必须调用 WSAStartup()，且需配对 WSACleanup()；二是 epoll_ctl() 的事件注册逻辑（如 EPOLLET）没有 Windows 对应物，不能简单映射；三是 epoll_wait() 返回的就绪事件数组，在 Windows 上可能需要多次 WSAEnumNetworkEvents() 或轮询，行为不可直接等价。这些差异不是加几个宏就能抹平的，必须从设计层面接受“不同平台用不同机制”这一事实。
