linux默认用epoll（无轮询、零拷贝、无1024限制），windows仅支持selectselector或proactoreventloop，二者在可扩展性、延迟精度和fd管理上存在底层硬性差异。
根本原因不是框架“写得不好”，而是 Windows 和 Linux 底层事件通知机制完全不同：Linux 默认用 epoll，Windows 只能用 SelectSelector 或 ProactorEventLoop，两者在可扩展性、延迟精度、fd 管理逻辑上存在硬性差异。
Linux 用 epoll 是默认行为，不是优化选项
Python 3.8+ 在 Linux 上会自动尝试 selectors.EpollSelector；只要内核支持（2.6+），就直接启用。它不轮询、不拷贝 fd 集合、无 1024 限制，单次 epoll_wait() 就能返回所有就绪 fd。
- 你不用做任何事，
asyncio.run()就走 epoll - 手动指定
selector=select.SelectSelector反而会退化成低效轮询，且连接数超 1024 后新 socket 被静默丢弃 -
strace -e trace=select,recv,send能清晰看到 select 每次调用都复制全部 fd，而 epoll 只注册一次、后续零拷贝
Windows 的 ProactorEventLoop 并不等于“高性能”
Windows 默认启用 ProactorEventLoop（3.8+），但它依赖 IOCP，对某些场景反而更脆弱：
- 启动时大量
create_task()可能卡住不动，或报WindowsError: [Errno 10038] - 单调时钟分辨率默认仅 15.6ms，
loop.call_later(0.01, ...)实际延迟常达 16–30ms - 不支持
loop.create_unix_server()、loop.add_reader()等 Unix 原语，管道和子进程行为也与 Linux 不同 - 若你混用
subprocess+ stdin/stdout 异步读写，容易触发死锁——Proactor 对标准句柄的处理逻辑和 Selector 完全不同
跨平台代码最危险的“一致假象”
看起来一样的代码，在两边实际调度节奏可能差 10 倍：
-
asyncio.sleep(0.01)：Linux 下通常 ≈10ms，Windows 下常 ≈16ms，macOS 下可能 ≈50ms -
loop.call_soon()调度延迟：Linux 稳定在 sub-ms 级，Windows 因消息队列机制可能堆积毫秒级延迟 - 异常传播路径不同：Windows 上未捕获的 task 异常更容易导致整个窗口闪退；Linux 下往往只 log 后继续运行
- 最隐蔽的是时序依赖——比如靠
await asyncio.sleep(0)让出控制权，在 Windows 下因调度延迟大，可能让其他协程等太久而“饿死”
真正难处理的从来不是“怎么让它跑起来”，而是“怎么让它在三套完全不同的内核接口上，表现出可预测的响应节奏”。不要试图靠调参抹平差异，该分平台初始化策略就分，该加精度补偿就加，该把高精度 tick 改成时间戳驱动就改——底层机制不统一，强行统一行为只会放大故障面。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
