Go 中 goroutine 启动即执行，无内置等待机制；需用 channel 或 sync.WaitGroup 显式同步，推荐 channel 实现带结果的异步任务。
goroutine 启动后立即执行，没有“异步等待”语义
Go 的 goroutine 本质是轻量级线程，go f() 一调用就调度执行，并不返回 Promise 或 Future。你不能像 JavaScript 那样写 await doAsync()；它没有内置的“等待完成”机制，必须自己协调。
常见错误是启动 goroutine 后直接继续执行后续逻辑，结果读到未初始化的数据或 panic：
func badExample() {
var result string
go func() {
result = "done" // 可能还没赋值，main 就已打印空字符串
}()
fmt.Println(result) // 很可能输出 ""
}- 用
sync.WaitGroup显式等待一组 goroutine 结束 - 用
channel接收结果（更推荐，天然支持超时、取消、错误传递） - 避免共享变量 + 无同步地读写 —— 这不是异步问题，是竞态问题
用 channel 实现带结果的异步任务
最自然的 Go 异步模式是“启动 goroutine → 写结果到 channel → 主协程从 channel 读”。这既解耦又可控。
例如启动一个耗时计算并获取返回值：
立即学习“go语言免费学习笔记（深入）”；
func computeAsync() <-chan int {
ch := make(chan int, 1) // 缓冲 1，避免 goroutine 阻塞
go func() {
defer close(ch)
time.Sleep(100 * time.Millisecond)
ch <- 42
}()
return ch
}
<p>// 使用：
result := <-computeAsync() // 阻塞直到有值，或 channel 关闭- 返回
类型，明确只读，防止误写 - 缓冲 channel（如
make(chan int, 1)）可避免 goroutine 因无人接收而永久阻塞 - 记得
close(ch)（尤其在可能出错时），否则range ch永远不会退出 - 若需超时控制，用
select+time.After
goroutine 泄漏：没被回收的长期存活协程
goroutine 不会自动销毁。一旦启动却无退出路径（比如死循环中没 break、channel 读写永远阻塞），它就会一直占内存和栈空间，最终拖垮服务。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
典型泄漏场景：
- 向已关闭的 channel 发送数据（panic，但若 recover 了且没退出，协程还在）
- 从无缓冲 channel 读取，但没人往里写（永久阻塞）
- HTTP handler 中启 goroutine 处理请求，但 handler 返回后 goroutine 仍运行（比如日志上报未加 context 控制）
修复关键点：
- 用
context.Context传递取消信号，goroutine 内部监听ctx.Done() - 所有 channel 操作前确认是否已关闭或是否应退出
- 测试时用
runtime.NumGoroutine()观察协程数是否随请求线性增长
不要用 goroutine 模拟 callback，优先用 channel + context 组合
有人试图这样写“回调”：
func doWithCallback(cb func(int)) {
go func() {
result := heavyWork()
cb(result) // 危险：cb 可能在任意 goroutine 执行，可能操作非线程安全资源
}()
}问题在于：cb 的执行上下文不可控，容易引发竞态或 panic（比如在 HTTP handler 已返回后修改 response writer）。
- 正确做法是把结果发到 channel，由调用方决定怎么处理（同步/异步/丢弃）
- 需要取消能力？传入
ctx context.Context，并在 goroutine 内检查ctx.Err() - 需要错误反馈？channel 类型设为
chan Result，其中Result包含Value和Err
goroutine 本身没有生命周期管理，真正难的是设计清晰的退出契约 —— 这比“怎么启”重要得多。
