纯 HTTP 高并发提交程序里踩过的坑

一开始想用浏览器自动化做，跑了两天就放弃了：一个实例吃几百兆内存，几十并发就把机器压垮，而且慢得离谱。改成直接构造 HTTP 请求之后，同样的机器能跑出两个数量级的差距。

代价是所有浏览器替你做的事，现在都得自己做。

表单不是你看到的那些字段

抓包才发现，提交时带的参数比页面上的输入框多得多：页面加载时种下的随机 token、停留时长、鼠标轨迹的摘要、每道题的作答耗时。少一个就被判为异常。

处理办法是把「取页面 → 解析隐藏字段 → 构造提交」做成一次完整会话，而不是把参数硬编码。站点改版的时候，解析层坏掉比提交层坏掉容易修得多。

时间字段不能是常数

早期版本里作答耗时是固定值，结果批量提交全被标记。后面改成按题目文本长度估一个基准，再叠一个正态扰动，整体时长分布看起来才正常。

这类字段的共性是：服务端不看单条，看分布。任何常数都会在分布上露馅。

连接池比并发数重要

httpx 的默认连接池上限比我想的小，把并发拉到几百之后，实际瓶颈在等连接而不是等响应。调大 max_connections 和 max_keepalive_connections 之后吞吐直接翻倍。

另外要给每个请求单独设超时。有一次某个接口挂了，没设超时的协程全卡在那里，整个事件循环看起来像死了。

关于用途

这个工具是给自己和同学处理重复问卷用的，仓库里写了适用范围。技术上它就是个 HTTP 客户端，怎么用是使用者的事，但我不打算把它包装成别的东西。