筛到10⁶卡死因goroutine泛滥致调度器崩溃；应分段处理、管道限流、传区间而非单数、用atomic.Bool或位图优化写入、ARM64/wasm需降并发度。
Go 里用 goroutine 实现 Sieve 算法，为什么筛到 10⁶ 就卡死？
因为没控制 goroutine 数量，筛到中间会起几万个协程，调度器扛不住，内存暴涨后被系统 kill。Go 的并发不是“越多越好”，而是“按需分段+管道限流”。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 把
[2, n]拆成固定大小的段（比如每段 10000），每个段一个goroutine负责标记合数 - 用
sync.WaitGroup等待所有段处理完，别用无缓冲 channel 做同步——容易死锁 - 避免让每个质数都起一个 goroutine 去筛（经典错误：为 2、3、5…各自开 goroutine），这会导致 O(n/2 + n/3 + …) 级别的 goroutine 泛滥
channel 传素数还是传区间？选错就拖慢 3 倍
传单个 int 素数看似直观，但高频小数据写 channel 开销远超计算本身；传区间（如 struct{ from, to int }）才能压住调度成本。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 主 goroutine 预生成质数表（用基础版 Sieve 筛出 ≤ √n 的质数），然后分发给工作 goroutine 处理各自区间
- 工作 goroutine 只读不写 channel，结果通过切片指针或预分配数组回填，避免 channel 串行化瓶颈
- 如果硬要用 channel 汇总结果，务必用带缓冲的：
ch := make(chan int, 1024)，否则一卡全卡
为什么 atomic.Bool 比 mutex 更适合标记合数数组？
因为筛法本质是大量并发写同一块布尔数组（isComposite[i]），而 atomic.StoreBool 比 mutex.Lock() 快 5–10 倍，且无锁竞争风险。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
[]uint32模拟位图（每 bit 表示一个数），配合atomic.OrUint32做原子置位，省内存又快 - 别用
[]bool—— Go 里它不是单字节对齐，atomic操作会 panic - 若必须用
[]bool，改用sync.Mutex保护整段（比如每 64 个数一个锁），别锁整个数组
交叉编译到 ARM64 或 wasm 时，goroutine 数量要调低
ARM64 设备内存小、调度器更敏感；wasm 甚至不支持真正的 OS 线程，goroutine 是纯用户态模拟，起太多直接爆栈。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
runtime.GOMAXPROCS(2)强制限制并发度，别依赖默认值 - 在
init()里检查runtime.GOARCH，ARM64/wasm 下自动把分段大小翻倍、goroutine 数减半 - wasm 目标下禁用所有
time.Sleep和阻塞式 channel 操作，它们不会真正休眠，只会空转耗尽配额
