go 程序在 main 函数返回后立即终止，若未显式等待后台 goroutine 完成，可能导致通道数据未被消费、文件写入中断等“静默失败”。本文详解其根本原因及可靠解决方案。
go 程序在 main 函数返回后立即终止，若未显式等待后台 goroutine 完成，可能导致通道数据未被消费、文件写入中断等“静默失败”。本文详解其根本原因及可靠解决方案。
你遇到的现象——单个设备无法写入文件，而两个设备却可以——并非通道行为“诡异”，而是典型的 程序提前退出导致 goroutine 被强制终止。main 函数执行完 close(deviceChan) 后即返回，整个进程随之结束，此时仍在运行的 WriteDeviceToFile goroutine 会被立即终止，无论它是否已完成循环或写入操作。
问题复现与根本原因
在你的代码中：
WriteDeviceToFile
-
defer f.Close()放在OpenFile后立即调用是安全的：即使后续panic，defer仍会执行（但注意 panic 会跳过defer后续语句）。 -
避免
f.WriteString(string(bytes))：json.Marshal返回[]byte，直接用f.Write()更高效且无编码风险；若需换行，单独WriteString("\n")。 -
添加
os.O_CREATE标志：确保目录存在时文件可创建（配合os.MkdirAll更健壮）。 -
错误处理不可省略：原代码忽略
os.OpenFile错误，应校验并 panic 或返回 error。 - 替代方案（进阶）：使用
context.Context控制超时，或通过 channel 发送完成信号（如done := make(chan struct{})），但WaitGroup对本场景最简洁。
总结
所谓“weird channel behavior”，实为 Go 并发模型的基本约束：goroutine 的生命周期不独立于 main。解决之道不在通道本身，而在正确协调主协程与工作协程的生命周期。始终记住：
? go f() 启动异步任务 ≠ 任务自动持久化；
? close(ch) 仅表示“不再发送”，不保证接收方已处理完毕；
? main 结束 = 程序死亡 —— 必须显式同步（WaitGroup / channel / sync.Once 等）才能保障逻辑完整性。
