安全工具开发者如何平衡枚举速度与资源消耗？

最近在写一个子域枚举插件，突然被一个老同事抛来一句：“快点儿！”我当时愣了半秒，心里暗暗嘀咕：要是把CPU逼到爆表，客户的VPS不就直接变成烤箱了吗？于是我开始在速度和资源之间玩起了“猫捉老鼠”。

速度与资源的拉锯战

枚举本质上是一次又一次的网络请求，没错，越快请求越多，发现的子域也就越多。但每一次 DNS 查询都要占用线程、内存，甚至把机器的 CPU 拉满。记得有一次我把并发数直接调到 200，结果几秒钟后 top 里全是 python 的红字，机器卡得连 SSH 都连不上。那一刻我才明白，速度不是单纯的“越快越好”，而是要在硬件承受范围内找个恰到好处的点。

实战中的调参经验

我把调参过程拆成了三步走：

• 先用 单线程跑一次基准，记录下每秒能发多少请求、CPU 占比多少。
• 再逐步提升 并发数，每次加 20，观察 cpu、memory、latency 的曲线。
• 当 CPU 超过 70% 或响应时间开始飙升时，就按上一步的 “黄金点” 回滚。

有意思的是，这个黄金点并不是固定不变的。换了目标域名、不同的 DNS 服务器，甚至网络高峰期的带宽限制，都可能让同样的并发数表现出天壤之别。于是我把这些数据写进了配置文件，让工具在启动时自动读取上一次的最佳并发值，省得每次都手动调。

把握平衡的心理

说白了，这事儿跟做饭差不多：火太大，菜糊了；火太小，味道淡。作为开发者，我学会了把“快”当成调味料，而不是主菜。每当看到客户端的报告里出现“枚举完成率 95%”，我都会偷偷给自己点个赞，因为这背后隐藏的是一次次对资源的精细打磨。于是我把这套思路写进了 README，顺便配上一张“CPU 使用率 vs 并发数”的折线图，想让新手们也能感受那种“刚好够用”的快感。

所以啊，别把所有的算力都砸进去，给自己留点余地，等下次再冲刺时，机器还能稳稳地跑。