不能。goroutine 启动后由调度器管理，调用顺序不等于执行或完成顺序；即使用 channel 串行启动，仍需显式同步，如用带缓冲 channel（容量为 1）传递完成信号以确保 A→B→C 顺序执行。
channel 配合 for-range 能否保证 goroutine 启动顺序？
不能。goroutine 启动后立即交由调度器管理，go func() {……}() 的调用顺序不等于执行顺序，也不等于完成顺序。即使用 channel 串行启动，也无法约束后续执行时序——除非你显式同步每个步骤。
用 sync.WaitGroup + channel 控制完成顺序
常见误区是只靠 WaitGroup 等待全部结束，但不关心谁先谁后。若需“按 A→B→C 顺序完成”，必须让前一个通知后一个。典型做法是用带缓冲的 channel 作为信号量：
doneA := make(chan struct{}, 1) doneB := make(chan struct{}, 1) go func() { // 执行 A doTaskA() doneA <- struct{}{}}()
go func() { <-donea>
go func() { <-doneb>
- 缓冲大小设为
1是关键，避免阻塞 sender；若用无缓冲 channel，sender 会卡在 ` - 这种链式依赖适合线性流程，超过 3–4 步建议改用状态机或
select+ timer 防死锁
多个 goroutine 写同一 slice 且要保序？用 sync.Mutex 不够
加锁只能防并发写 panic，不能保序。比如 5 个 goroutine 并发写 results[i] = x，即使加了互斥锁，i 的取值仍取决于调度时机，结果位置仍是乱的。
- 正确做法：预先分配好 slice，用固定索引写入（如传入
i参数），不依赖执行顺序 - 或者用
chan []T收集结果，由单个 goroutine 从 channel 读取并按接收顺序追加到 slice - 避免用
append()在并发中操作同一 slice——底层数组扩容可能引发 data race
为什么不用 runtime.Gosched() 强制让出？
它只是提示调度器“我可以换人了”，不提供任何顺序保证。实测中插入 runtime.Gosched() 后行为更不可预测，尤其在高负载下反而加剧竞争。真正需要顺序的地方，必须用显式通信（channel）或同步原语（sync.Once、sync.Cond）建模依赖关系。
立即学习 “go 语言免费学习笔记（深入）”；
最易被忽略的一点：顺序控制的本质不是“让 goroutine 按某序列跑”，而是“让某些操作的副作用（如写内存、发 HTTP 请求、更新 DB）按指定次序对外可见”。盯住副作用发生点，而不是 goroutine 启动点。
