难度与性能调优
难度不是越高越好。真正要平衡的是三个量：访客等待、服务端验算耗时、批量请求成本。
两个旋钮
| 旋钮 | 影响客户端 | 影响服务端 |
|---|---|---|
CAP_CHALLENGE_COUNT | 线性增加总计算量 | 线性增加验算次数 |
CAP_CHALLENGE_DIFFICULTY | 每题期望尝试 ×16 / 档 | 几乎不变（只验算命中答案） |
因此想提高攻击成本，优先调难度；想平滑单次耗时，优先调子挑战数量。但两者的乘积决定兑换接口的整体时间。
时间预算
在无服务器函数里，兑换请求必须在一个固定的时间上限内完成。默认 20 × 3 在缓存路径下约 20 ms 求解，服务端验算远低于上限。
警告
把 MAX_DURATION 当成硬约束：提高参数前先实测最慢设备的求解时间，再确认服务端验算没有逼近上限。参数一旦超出预算，表现不是「慢一点」，而是整批验证请求超时。
推荐起点
| 场景 | 建议 |
|---|---|
| 一般站点 | 保持默认 20 × 3 |
| 移动端占比高 | 降到 12 × 3，观察等待时间 |
| 遭受批量刷接口 | 升到 20 × 4，同时加业务限流 |
| 低端设备反馈卡顿 | 优先降数量，不要直接降难度到 2 |
观测什么
- 客户端：从盒子出现到通过状态的耗时（P50 / P95）
- 服务端：兑换接口耗时与超时率
- 业务：验证失败后重试率是否上升
提示
难度调整务必配合业务限流。单靠计算成本拦不住由真人操作的打码农场。