Go语言中使用go关键字进行递归函数调用是否存在危险？

你测试中碰到的7秒耗尽32G内存、系统冻结只能硬重启的现象是完全真实的，这类问题的核心不是go关键字本身存在设计缺陷，是无节制创建协程的错误写法触发的资源失控。

先拆解你提到的危险示例的运行逻辑：

/* 警告：运行以下代码大概率会导致系统崩溃 */
package main

func infinity() {
LOOP:
	go infinity()
	goto LOOP
}

func main() {
	infinity()
}
/* 警告：运行以下代码大概率会导致系统崩溃 */

这段代码的协程数量是按指数级暴涨的：

• goto LOOP本身是没有退出条件的死循环，每轮循环都会触发一次go infinity()创建新协程
• 新创建的infinity协程，会重复执行死循环、再创建更多新协程的逻辑
  哪怕Go协程的初始栈仅约2KB，短时间内生成上亿个协程的话，累计占用的内存也会快速把系统内存占满，最终导致系统无响应。

你提到的“递归函数做并行计算时，细微漏洞触发无限循环”的顾虑是完全成立的：很多开发者会觉得协程足够轻量、创建成本极低，就毫无限制地起协程，但轻量不等于无成本，只要递归逻辑漏写了终止条件，就会触发和示例一致的协程数量爆炸问题。

关于“使用go关键字时搭配计数器、设置中止条件是否更稳妥”的问题：
这类防护思路的方向是正确的，但不需要把它变成僵化的固定规则，不同场景下的稳妥实现有差异：

• 针对递归并行计算场景：最核心的防护是写明确的递归终止阈值，比如当待计算的任务规模拆分到足够小时，就不再创建新协程，直接走同步计算流程，本身就给协程数量加了天然边界，不会出现无限制增长的问题。
• 针对服务端常驻协程场景：更通用的防护是配合并发数上限控制、可传递的退出信号，而不是硬编码全局计数器。比如通过带缓冲的信号量通道限制最大并发数，每启动一个协程就从通道中取一个令牌，协程退出时归还令牌，就算业务逻辑存在漏洞，协程总数量也不会超过预设阈值，不会把系统资源打满。
• 你测试的那种嵌套死循环无节制起协程的写法，本身就是极端的错误编码示例，正常生产代码中本来就不允许写无退出路径的死循环，只要保证协程有明确的退出逻辑、有可控的并发边界，就不会出现几秒耗尽全量系统内存的问题。

内容的提问来源于stack exchange，提问作者paladin