数据会丢是因为main函数退出导致协程被强制终止，需用sync.WaitGroup同步；闭包捕获循环变量易出错，应传参避免；channel缓冲区需依场景设定，勿混淆len与cap；map并发写 panic，应选sync.Map、RWMutex或单goroutine写；select无default且所有channel不可操作时会永久阻塞。
用 goroutine 启动数据流处理时，为什么数据会丢？
因为没等所有 goroutine 完成就退出了主函数。Go 不会自动等待协程结束，main 函数一返回，整个程序就终止，正在跑的协程被强制中断。
- 必须显式同步：用
sync.WaitGroup记录启动了多少个处理单元，并在每个协程结束时调用wg.Done() - 别在循环里直接启
go func() { ... }()且不传参——闭包捕获的循环变量（如item）可能被后续迭代覆盖，导致所有协程处理同一个值 - 正确写法是把当前值作为参数传进协程：
go processItem(item)或go func(val T) { ... }(item)
channel 缓冲区设多大才合适？
缓冲区不是越大越好。设太大容易掩盖背压问题，内存涨得快；设太小又频繁阻塞，吞吐上不去。关键看生产者和消费者的节奏差。
- 纯异步解耦（比如日志采集）：用
make(chan T, 1024)这类固定中等缓冲，避免瞬时峰值直接 panic - 需要精确控速（比如限流处理请求）：用无缓冲
make(chan T)，靠消费者主动拉取实现天然节流 - 千万别用
make(chan T, 0)声明缓冲为 0 的 channel——这等价于无缓冲，但语义易误导；直接写make(chan T)更清晰 - 注意
len(ch)返回当前已存元素数，cap(ch)才是缓冲容量；别混淆两者去判断“是否快满了”
多个 goroutine 往同一个 map 写数据，为什么崩得毫无征兆？
Go 的 map 默认不是并发安全的。两个协程同时写（或一读一写），会触发运行时 panic，报错信息通常是 fatal error: concurrent map writes 或随机崩溃，不一定会立刻复现。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 简单场景：用
sync.Map替代原生map，适合读多写少，但注意它不支持range遍历，得用LoadAll或自己加锁 - 高频写/复杂逻辑：老实用
sync.RWMutex包一层原生map，读用RLock，写用Lock - 更彻底的方案：把写操作收口到单个 goroutine（比如用 channel 投递写请求），其他协程只读——避免锁竞争，也更容易做聚合、去重等逻辑
用 select 处理多个 channel 时，为什么有时永远卡住？
select 是非阻塞的，但如果所有 case 的 channel 都不可操作（比如全空且无缓冲、或全满），它就会一直阻塞，除非加 default。
立即学习“go语言免费学习笔记（深入）”；
- 想轮询不等待：加
default:分支，哪怕只写default: time.Sleep(time.Millisecond) - 想等超时：必须配
time.After，比如case ，不能靠外部计时器+布尔标志模拟 - 别在
select里重复读同一个 channel 多次——Go 不保证 case 执行顺序，两次可能读到不同值，也可能第二次就阻塞 - 关闭的 channel 在
select中始终可读（返回零值+false），所以用val, ok := 判断是否关闭比单独关 channel 更可靠
并发数据流真正的难点不在启动多少 goroutine，而在于什么时候让它们停、数据从哪来又到哪去、中间状态怎么不丢不错。这些边界条件，往往只在流量上来、机器负载升高、GC 频繁时才暴露。
