Go中goroutine启动后不阻塞主函数，主函数退出则所有goroutine强制终止；需用sync.WaitGroup等待或time.Sleep临时观察，且循环中传参避免闭包陷阱；channel使用不当易致泄漏或死锁。
goroutine 启动后不等待，主函数退出就结束
Go 的 goroutine 是轻量级线程，但启动后默认不阻塞主流程。如果主函数执行完直接退出，所有未完成的 goroutine 会被强制终止，看不到输出。
- 用
time.Sleep()临时观察效果（仅测试用，不可用于生产） - 更可靠的方式是用
sync.WaitGroup等待所有任务完成 - 避免在循环中直接启动
goroutine并传入循环变量——容易捕获到变量最终值，需显式传参或用局部变量捕获
package mainimport ( "fmt" "sync" "time" )
func main() { var wg sync.WaitGroup
for i := 0; i < 3; i++ { wg.Add(1) go func(id int) { defer wg.Done() fmt.Printf("goroutine %d running\n", id) time.Sleep(time.Second) }(i) // 注意：这里把 i 作为参数传入，避免闭包陷阱 } wg.Wait() // 主 goroutine 阻塞等待全部完成 fmt.Println("all done")}
goroutine 泄漏：忘记关闭 channel 或未消费完数据
当用
channel配合goroutine做生产者-消费者模型时，若发送端关闭了channel，但接收端没处理完或没检测关闭状态，可能造成接收goroutine永久阻塞；反之，若接收端已退出而发送端还在往无缓冲 channel 写，也会死锁。
- 使用
for range ch自动处理 channel 关闭 - 带缓冲的 channel 能缓解压力，但不能替代逻辑控制
- 超时控制推荐用
select+time.After()，避免无限等待
go func(ch chan int) {
for i := 0; i < 5; i++ {
select {
case ch <- i:
case <-time.After(time.Second):
fmt.Println("send timeout, skip")
}
}
close(ch)
}(ch)大量 goroutine 启动导致内存或调度压力
每个 goroutine 初始栈约 2KB，虽轻量，但百万级并发仍会耗尽内存；同时 Go 调度器不是为“越多越好”设计的，过度创建反而降低吞吐。
dmSOBC SHOP网店系统
下载
dmSOBC SHOP网店系统由北京时代胜腾信息技术有限公司（http://www.webzhan.com）历时6个月开发完成，本着简单实用的理念，商城在功能上摒弃了外在装饰的一些辅助功能，尽可能的精简各项模块开发，做到有用的才开发，网店V1.0.0版本开发完成后得到了很多用户的使用并获得了好评，公司立即对网店进行升级，其中包括修正客户提出的一些意见和建议，现对广大用户提供免费试用版本，如您在使用
立即学习“go语言免费学习笔记（深入）”；
- 用
runtime.GOMAXPROCS(n)控制并行数（通常保持默认即可） - 对 I/O 密集型任务，优先用 channel + worker pool 模式限制并发数，而非为每个请求启一个 goroutine
- 可通过
runtime.NumGoroutine()监控当前数量，排查泄漏
goroutine 中 panic 不会传播到主 goroutine
每个 goroutine 独立运行，其中的 panic 默认只终止自身，不会中断主流程，也容易被忽略。
- 用
recover()在 goroutine 内部捕获 panic（必须在 defer 中调用） - 不要依赖外部监控捕获 goroutine panic——它根本不会冒泡出去
- 日志中需明确标注 panic 来自哪个 goroutine，例如打上 ID 或上下文
go func(id int) {
defer func() {
if r := recover(); r != nil {
fmt.Printf("goroutine %d panicked: %v\n", id, r)
}
}()
panic("something went wrong")
}(1)实际写并发逻辑时，最常被忽略的是「等待机制」和「错误隔离」——前者导致程序提前退出、结果丢失，后者导致 panic 静默失败、问题难以复现。
