Go默认线程数为何难限制？

我目前遇到的主要困扰是：Go语言默认启动的系统线程数量偏多。即便只运行两个简单的常驻型程序，用htop观察时，几乎全部线程槽位都会被占满，导致其他任务难以直观监控和管理。因此，在本地开发服务类应用时，我倾向于选择另一种更轻量、可控性更强的语言，其核心要求如下：首先必须支持编译，优先考虑静态编译或AOT编译方式，避免运行时依赖；其次需具备良好的跨平台能力，便于在不同操作系统间迁移部署；第三，最好内置垃圾回收机制，以显著降低内存管理的认知负担；第四，运行时环境应尽可能精简，不占用过多内存与系统资源；第五，最终生成的可执行文件体积要小，便于分发与快速启动；第六，执行性能并非首要考量，响应及时即可；第七，需配备功能完备、覆盖面广的标准库，减少重复造轮子；第八，社区活跃、使用者广泛，文档丰富、教程易得、问题容易找到参考解法。
目前初步选定Nim语言，它在编译模式、体积控制、运行时大小及GC支持等方面基本契合上述需求，唯独用户基数相对有限，生态成熟度略逊一筹。C亦属备选，虽具备强大生态与稳定运行时，但编译产物体积偏大，对轻量场景稍显冗余。至于Go，若能将底层线程数稳定约束在2个左右，其实已非常接近理想状态。有人建议通过GOMAXPROCS调控，但需明确的是：该参数仅影响goroutine调度器所用的逻辑处理器数量，并不能限制实际创建的OS线程数。实测表明，即使不启用任何额外goroutine（main中仅维持空循环），系统仍默认维持5个线程；调整GOMAXPROCS为2对此毫无影响；而当启用大量goroutine后，线程数仍保持在5个左右——只有当GOMAXPROCS设为较大值时，线程数才可能进一步增长。这说明Go运行时内部维护了一个约5线程的固定池，用于协同执行调度与垃圾回收等后台任务。