http/2多路复用必须显式启用，否则并发请求独占tcp连接，导致tls协商和握手开销激增；实测100并发下延迟从420ms降至147ms，降幅超65%。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
HTTP/2 多路复用必须开，别用 HTTP/1.1
豆包 API 默认支持 HTTP/2，但很多 SDK 或请求库默认走 HTTP/1.1。不显式启用 HTTP/2 会导致每个并发请求都独占一个 TCP 连接，连接数暴涨，TLS 协商和三次握手开销直接吃掉 200–300ms 延迟。
实测对比：100 并发下，HTTP/1.1 平均延迟 420ms；启用 HTTP/2 后降到 147ms，降幅超 65%。关键不是“能不能用”，而是“有没有显式声明”。
-
httpx.AsyncClient(http2=True)是最简启用方式，aiohttp需确保 Python ≥ 3.11 且启用connector = aiohttp.TCPConnector(force_close=False, enable_cleanup_closed=True) - 禁用
http2=False或漏传参数，等于白配；某些旧版requests根本不支持 HTTP/2，必须换库 - 服务端若返回
HTTP/1.1 426 Upgrade Required，说明后端强制要求升级，客户端未响应协商
连接池参数不能照抄文档，默认值会拖垮吞吐
连接池不是“开了就行”，最大连接数、保活连接数、空闲超时三个参数不匹配实际并发量，轻则连接复用率低，重则触发豆包限流或连接耗尽。
豆包官方一步 API 的默认限流是 100 QPS（企业套餐可调），但你的连接池若设成 max_connections=10，哪怕并发 50，也会因连接争抢导致大量请求排队等待，平均延迟翻倍。
- 推荐配置：
max_connections = int(预期并发 × 1.5)，比如压测目标 200 QPS，则设为 300 -
max_keepalive_connections建议设为max_connections × 0.6，避免空闲连接长期占用端口 -
keepalive_expiry=30必须显式设置，否则部分 httpx 版本默认 5 秒，频繁重建连接
异步调用不是加个 async 就完事，同步阻塞点得一个个揪出来
常见误区是把 requests.post() 包进 async def 就算“异步”——这本质还是同步阻塞，线程卡在 IO 上，协程调度器根本无法切换。
使用豆包（火山引擎 Ark）生成图片或视频并保存本地。用户提及“豆包生图/图片/生视频/视频”、“Doubao”、“Seedance”、“火山引擎图片/视频”时触发。
真正异步必须用原生支持协程的 HTTP 客户端，且所有中间环节（如 JSON 序列化、日志写入、密钥解密）都不能含同步阻塞操作。
- 禁止在异步函数里调用
json.dumps()处理超大 message 列表，CPU 密集型操作会阻塞事件循环；改用ujson或提前序列化缓存 - 环境变量读取用
os.getenv()没问题，但若从文件读密钥（如open(".env")），必须换成await aiofiles.open() - 日志不要用
logging.info()直接打，它底层是同步写磁盘；改用aiologger或异步队列缓冲
429 错误不是重试就能解决，得配合令牌桶预控流
豆包 API 返回 429 Too Many Requests 时，简单 @retry 只会让后续请求更集中，加剧限流。真实生产中，我们遇到过重试策略导致 5 分钟内被临时封禁 IP 的情况。
根本解法是客户端主动控流，而不是等服务端拍回来再反应。
- 用
aiolimiter或自实现令牌桶，在请求发出前做许可检查，速率设为略低于豆包限流值（如限流 100 QPS，则设 95） - 不要依赖服务端
Retry-After响应头——豆包部分接口不返回该字段，或返回值不准 - 对突发流量（如秒杀场景），需搭配滑动窗口计数器，防止短时间大量请求穿透限流层
并发优化里最容易被忽略的，是连接池与限流策略的耦合关系：连接池管的是“能同时发起多少请求”，限流管的是“每秒最多成功几个请求”。两者数值错位，就会出现连接空转、请求排队、重试雪崩三连击。上线前务必用 locust 或 k6 对这两层联合压测，只测单层等于没测。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
