go 程序在 `main` 函数返回时立即终止，不会等待其他 goroutine 完成；添加 `time.sleep` 反而可能加剧竞态，导致子 goroutine 来不及执行打印逻辑即被强制结束。
在 Go 中，程序生命周期完全由 main 函数控制：一旦 main 函数执行完毕（无论是否显式 return），整个进程立即退出，所有正在运行的非主 goroutine（包括已启动但尚未调度或正在执行的）都会被强制终止，且不触发任何清理逻辑。
你观察到的现象——加了 time.Sleep(time.Second) 后 my_func 似乎“不执行”——并非因为 goroutine 被阻塞或未启动，而是典型的竞态 + 主函数过早退出问题：
- ✅ go my_func(c) 成功启动 goroutine；
- ✅ c <- 3 发送成功（因 c 是无缓冲 channel，该操作会阻塞直到 my_func 执行 <-c）；
- ❌ 但 my_func 中的 fmt.Println(<-c) 执行后，main 函数已无后续语句，随即退出 → 程序终止 → fmt.Println 的输出可能被丢弃（尤其在 Playground 等受限环境中），甚至根本来不及刷新 stdout 缓冲区。
⚠️ 注意：time.Sleep 在此处不仅无益，反而有害——它延迟了 c <- 3 的发送时机，却未提供任何同步保障。main 仍会在发送后立即结束，goroutine 的打印行为依然不可靠。
正确做法：使用通道同步（推荐）
通过额外的 done 通道确保 main 等待子 goroutine 完全处理完毕：
package main
import (
"fmt"
"time"
)
func my_func(c, done chan int) {
val := <-c
fmt.Println(val)
done <- 1 // 通知 main：已完成
}
func main() {
c := make(chan int)
done := make(chan int)
go my_func(c, done)
time.Sleep(time.Second) // 仅为模拟延迟，实际应避免随意 Sleep
c <- 3
<-done // 阻塞等待 my_func 完成打印
}✅ 输出确定为 3，且程序正常退出。
更健壮的替代方案：sync.WaitGroup
当需等待多个 goroutine 时，sync.WaitGroup 更清晰、更符合工程实践：
package main
import (
"fmt"
"sync"
"time"
)
func my_func(c chan int, wg *sync.WaitGroup) {
defer wg.Done()
fmt.Println(<-c)
}
func main() {
c := make(chan int)
var wg sync.WaitGroup
wg.Add(1)
go my_func(c, &wg)
time.Sleep(time.Second)
c <- 3
wg.Wait() // 等待所有 goroutine 完成
}关键原则总结
- ? 永远不要依赖 time.Sleep 实现 goroutine 同步：它不可靠、难维护、掩盖真正问题；
- ✅ 始终显式同步：用 channel（done 信号）、sync.WaitGroup 或 context 控制生命周期；
- ? 理解 Go 内存模型中的 “happens-before” 关系：例如，“向 channel 发送” happens before “从同一 channel 接收完成”，这是唯一可依赖的顺序保证；
- ? 调试提示：本地运行时若偶尔看到输出，是调度器偶然让 goroutine 抢占到时间片；但在 CI、容器或 Playground 中极易失败——这恰恰证明代码存在竞态，而非“有时能工作”。
遵循同步约定，你的并发 Go 代码才能真正可靠、可预测、可维护。
