curio 项目已于2025年12月21日由david beazley正式归档，停止所有维护，不再修复安全漏洞、适配新python版本或更新windows api；推荐迁移至trio、anyio或asyncio，并警惕api差异导致的隐性错误。
Curio 已停止维护，2025 年底正式归档
Curio 项目已于 2025 年 12 月 21 日由创始人 David Beazley 宣布终止维护，README 中明确写道：“经过十年，我决定放弃 Curio 项目。预计不会有进一步的维护。”这不是暂停更新，而是彻底归档——pip install curio 仍能安装，但不会再有安全修复、兼容性适配（如 Python 3.13+）、Windows 新版 API 支持或 bug 修复。
这意味着：如果你正在评估新项目技术栈，或计划将现有 Curio 服务长期运行，必须立刻启动迁移；如果只是阅读旧代码或教学演示，它依然可运行，但不应作为生产依赖引入。
替代方案怎么选：Trio vs AnyIO vs asyncio
Curio 停更后，实际可用的主流替代不是“另一个轻量框架”，而是三个方向明确的选项，选错会导致后续重构成本陡增：
-
Trio：适合追求“结构化并发”和强错误隔离的新项目。它的
trio.run()和trio.move_on_after()让超时、取消、嵌套任务管理更直观，但生态略窄（比如部分 HTTP 库需额外适配）； -
AnyIO：适合已有
asyncio代码想平滑过渡，或需要同时支持 Trio/asyncio 后端的库作者。它用统一接口屏蔽底层差异，anyio.create_task_group()行为在不同后端一致，但调试时堆栈可能变长； -
asyncio（标准库）：仍是兼容性最广、文档最全的选择。Python 3.11+ 的
asyncio.timeout()和 3.12 的asyncio.Runner已大幅简化使用门槛，但需警惕混入阻塞调用（如time.sleep()）导致整个事件循环卡死。
简单判断：团队刚接触异步？选 Trio。要对接现有 aiohttp/httpx 生态？优先 AnyIO 或直接 asyncio。写开源库供他人集成？AnyIO 是最稳妥的抽象层。
立即学习“Python免费学习笔记（深入）”；
迁移 Curio 代码时最容易踩的坑
Curio 的 API 看似简洁，但设计理念与其它框架存在隐性冲突，直接替换函数名大概率出错：
-
curio.spawn()不等价于asyncio.create_task()—— 前者默认不返回 task 对象，后者必须显式 await 或保存引用，否则任务可能被垃圾回收； -
curio.timeout_after()是装饰器风格，而 Trio 用with trio.move_on_after():，asyncio 用async with asyncio.timeout():，语法位置和异常类型（curio.TaskTimeoutvstrio.TooSlowError）完全不同； - Curio 的
curio.socket是纯异步封装，但 asyncio 的asyncio.open_connection()返回的是流对象，若原代码直接调用.send()/.recv()，需重写为StreamReader/StreamWriter模式； - 所有
curio.run_in_thread()调用，迁移到 asyncio 必须改用loop.run_in_executor()或asyncio.to_thread()（Python 3.9+），且注意线程池复用策略差异。
建议先用 grep -r "curio\." your_project/ 扫出全部调用点，逐个对照目标框架的等效模式重写，不要依赖自动转换脚本。
为什么不再推荐“自己维护一个 Curio 分支”
有人会想 fork 一份继续修 bug，但这在工程上几乎不可行：
- Curio 严重依赖 Python 内部协程调度细节（如
sys.set_coroutine_origin_tracking_depth），CPython 小版本升级（如 3.12.4 → 3.12.5）就可能破坏其内核调度器； - 它没有 CI 测试矩阵覆盖 Windows + macOS + 多种 Linux 发行版，也没有对 ARM64（如苹果 M 系列、鲲鹏）做专门适配；
- 关键模块如
curio/kernel.py是高度定制的微调度器，缺乏文档和注释，二次开发成本远高于切换到 Trio 或 AnyIO。
真正省事的做法，是接受 Curio 作为一段已完成的历史——它完成了教育实验的使命，现在该让位给更可持续的方案了。
