Go语言中为何使用内部函数？两段代码差异解析

原代码通过启动goroutine并行处理订阅者，改写后的代码则在循环内串行执行逻辑，二者的关键差异如下：

1. 执行模式：并发 vs 串行 #

• 原代码：借助go func(...)()启动独立goroutine，所有订阅者的处理逻辑并行执行。比如每个处理流程里的time.After(time.Second)超时等待，所有订阅者会同时进入等待，总耗时约1秒。
• 改写后：循环内直接执行逻辑，只能逐个串行处理订阅者。若有N个订阅者且都触发超时，总耗时会达到N秒，效率大幅降低；如果某个订阅者的处理发生阻塞（比如s.events <- e一直无法发送），后续所有订阅者都会被卡住。

2. return的行为完全不同 #

• 原代码：return仅退出当前goroutine，不会影响其他goroutine的执行，也不会中断外层的for循环。
• 改写后：return会直接退出包含这个for循环的整个函数，循环立即终止，后续的订阅者根本不会被处理。

3. 循环变量捕获的设计意义 #

原代码把id和s作为参数传给goroutine，是为了规避Go语言for循环的变量复用陷阱：
Go的for循环中，id和s是同一个变量在每次迭代中被重新赋值，如果goroutine直接引用循环变量（比如去掉参数写成go func(){ ... }()），所有goroutine可能会拿到最后一次循环的id和s值。通过参数传递，每个goroutine会拿到当前迭代的变量副本，保证数据正确性。
而改写后的代码因为是串行执行，每次循环的id和s就是当前迭代的值，不会出现这个问题，但这只是串行场景下的巧合，原代码的参数传递是并发场景下的标准正确写法。

原代码片段 #

for id, s := range subscribers {
    go func(id string, s *helloSaidSubscriber) {
        select {
        case <-s.stop:
            unsubscribe <- id
            return
        default:
        }

        select {
        case <-s.stop:
            unsubscribe <- id
        case s.events <- e:
        case <-time.After(time.Second):
        }
    }(id, s)
}

改写后代码片段 #

for id, s := range subscribers {
    select {
    case <-s.stop:
        unsubscribe <- id
        return
    default:
    }

    select {
    case <-s.stop:
        unsubscribe <- id
    case s.events <- e:
    case <-time.After(time.Second):
    }
}

内容的提问来源于stack exchange，提问作者Joey Yi Zhao