异步I/O跨平台抽象不能靠裸指针实现，核心在于事件循环模型差异（IOCP/epoll/kqueue），void*仅辅助传上下文但无法解决类型安全、生命周期和线程模型问题，须采用分层策略+RAII+std::shared_ptr+统一回调调度。
异步I/O在C++里根本不能靠裸指针封装跨平台
直接说结论：用原始指针（int*、void*）去“封装”跨平台异步I/O，不仅做不到，还会掩盖本质问题。异步I/O的跨平台抽象核心是事件循环模型差异，不是内存地址传递问题。Windows用OVERLAPPED + IOCP，Linux用epoll/io_uring，macOS用kqueue——它们连就绪通知机制都不同，指针连个统一回调上下文都传不稳。
为什么void*用户数据指针救不了你
很多API确实提供void*参数（比如uv_udp_send的handle附带user_data，或IOCP的lpCompletionKey），但这只是传递上下文的*辅助手段*，不是封装基础：
-
void*不携带类型信息，C++里强转易出错，尤其涉及虚函数表或生命周期管理时 - 它无法自动绑定成员函数，
std::bind或lambda捕获对象后生成的可调用体不能直接转成void*安全传递 - 跨平台层必须自己管理该指针指向对象的生存期，而各平台完成通知时机不同（如
IOCP可能延迟返回，epoll就绪即通知），极易悬空 - Windows下
lpCompletionKey是per-handle的，而Linux下epoll_ctl没等价字段，强行模拟会破坏事件分发逻辑
真正可行的跨平台异步I/O抽象方式
放弃“用指针统一接口”的幻想，改用分层策略：
- 底层适配器按平台实现（
IOCPHandler/EpollDriver/KQueueLoop），各自持有原生句柄和事件队列，不暴露指针细节 - 中间层定义统一的非阻塞操作接口，例如
async_read(socket, buffer, callback)，其中callback是std::function<void size_t></void>，由适配器在就绪后调用 - 用户态绝不直接接触
OVERLAPPED*或epoll_event*，所有资源（缓冲区、socket、定时器）由RAII对象管理（如tcp_socket析构时自动取消挂起的WSARecv） - 若需传递上下文，用
std::shared_ptr包装状态对象，通过std::bind或lambda捕获，避免裸指针生命周期失控
示例片段（简化）：
class tcp_socket {
std::shared_ptr<io_context> ctx_; // 跨平台事件循环
void* native_handle_; // 各平台私有，不对外暴露
public:
void async_read(std::span<char> buf,
std::function<void(std::error_code, size_t)> cb) {
// 内部根据ctx_->backend()调用IOCP提交或epoll注册
// cb被包装进内部completion wrapper，绑定shared_ptr防止析构
}
};
最容易被忽略的陷阱：完成通知与线程模型耦合
异步I/O不是“发完就不管”，而是“谁来调用回调、在哪个线程、是否重入”——这点比指针类型重要十倍：
立即学习“C++免费学习笔记（深入）”；
- Windows
IOCP默认回调在任意线程池线程，Linuxepoll需主动epoll_wait再分发，二者线程安全假设完全不同 - 若用户回调里调用了另一个
async_write，在单线程epoll模型中可能触发立即就绪，导致递归调用；而IOCP不会——不统一调度层，裸指针传参毫无意义 - 很多跨平台库（如Boost.Asio、libuv）用
strand或work queue强制序列化回调，这才是实际需要封装的“跨平台行为”，不是指针本身
所以别纠结int*怎么跨平台，先想清楚你的回调是否允许并发执行、错误码如何映射、缓冲区所有权归谁——这些决定了架构，指针只是最表层的搬运工。
