技能介绍

问题：选型不该只看热度

Python 生态里同一任务常有多套方案：requests 和 httpx 都能发请求，FastAPI、Flask、Django 都能写服务，pandas、polars、dask 都能处理表格。只按 Stars 或流行度选型，容易把重框架塞进小脚本，或用同步客户端去扛高并发；问题通常不在第一次运行，而在上线后暴露为事件循环阻塞、内存膨胀或部署形态不匹配。

核心机制：先画任务画像，再按域给边界

这个技能把“该用哪个库”拆成四步流程。第一步锁定任务画像，问清任务类型（Web 服务 / 数据清洗 / 爬虫 / CLI / 异步并发 / 文件处理 / ML）、运行形态（长期服务、一次性脚本、笔记本探索）和规模与约束（数据量、并发量、是否要类型检查、团队熟悉度）。第二步进入分域决策框架：HTTP 请求、Web 框架、数据处理、爬虫、测试、CLI、异步并发、文件/格式，每个域都给出主推 → 适用 → 边界 → 替代。

例如同步 HTTP 默认谈 requests，需要异步或 HTTP/2 时切到 httpx；API 服务倾向 FastAPI 的异步、自动文档和类型校验，超轻量脚本则可能退回 Flask；重业务系统再考虑 Django。数据处理中，pandas 是表格清洗的事实标准，超大数据或追求吞吐时评估 polars，内存放不下再考虑 dask。第三步要求输出“决策一句话”，把场景直接映射到选择，例如“要高并发 API + 自动文档 → FastAPI；几行脚本取数 → Flask 更轻”。第四步必须提示坑点，比如 requests 同步调用别放进事件循环、pandas 链式赋值注意 .copy()、Flask 开发服务器不能上生产、爬虫要遵守 robots.txt 与目标站条款并控制频率。

注意点：给替代，不替你拍板

内置速查表保留任务 / 首选 / 何时换 / 替代四列，适合贴进团队文档。用户点名“就要某个库”时，技能先尊重选择，再温和说明不匹配之处；遇到版本差异（如 pandas 2.x、FastAPI 0.100+），以所装版本官方文档为准；对维护状态或 API 不确定的库，会承认信息不足而不编造。它不负责判定业务逻辑或架构合法性，也不引导突破反爬；当需求跨出给定领域（例如分布式训练、消息中间件选型）时，需要继续补充实际部署约束。