go 程序中日志未写入文件，主因是主 goroutine 过早退出导致程序终止，且日志通道未关闭，致使消费者 goroutine 无限阻塞；同时存在文件打开模式错误与资源竞争隐患。
go 程序中日志未写入文件，主因是主 goroutine 过早退出导致程序终止，且日志通道未关闭，致使消费者 goroutine 无限阻塞；同时存在文件打开模式错误与资源竞争隐患。
上述代码看似逻辑清晰：主线程创建并关闭初始文件句柄、启动一个日志消费 goroutine 持续从 channel 读取消息并追加写入文件，再并发发送多条日志消息。但实际运行后 log.txt 始终为空。根本问题不在“同步”本身，而在于程序生命周期管理缺失与I/O 操作配置错误。
? 核心问题解析
主 goroutine 提前退出（致命）
main()函数在启动所有 worker goroutine 后立即结束，Go 运行时会强制终止整个进程——无论其他 goroutine 是否仍在执行。因此，日志消费协程甚至来不及处理第一条消息就被杀死。这是空文件的最直接原因。channel 未关闭，
for range或ok检查失效
消费端使用msg, ok := 判断通道是否关闭，但 <code>ok仅在通道被显式close(logCh)且已无缓冲数据时才为false。当前代码从未调用close(logCh)，导致for { ... }死循环阻塞在上（即使缓冲区为空），无法退出。-
文件打开模式错误（潜在崩溃风险）
os.OpenFile("./log.txt", os.O_APPEND, os.ModeAppend)中，第三个参数应为文件权限掩码（如0644），而非os.ModeAppend（它是标志位，非权限）。正确写法是：
Alibabacloud Sdk Client Initialization For Golang下载初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
f, err := os.OpenFile("./log.txt", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644) if err != nil { panic(err) // 或合理错误处理 }否则可能因权限参数非法导致
f == nil，后续f.WriteString()触发 panic（但因主 goroutine 已退出，panic 甚至不会被观察到）。立即学习“go语言免费学习笔记（深入）”；
重复打开/关闭文件，低效且易出错
每次写日志都OpenFile → WriteString → Close，不仅性能差，还可能因系统文件描述符耗尽或竞态（如多 goroutine 同时写同一文件，虽本例中仅单 consumer，但设计不健壮）。
✅ 正确实现方案（推荐）
package main
import (
"fmt"
"os"
"sync"
"time"
)
func main() {
logCh := make(chan string, 50)
// 启动日志写入 goroutine，并传入 *os.File 避免重复打开
var wg sync.WaitGroup
wg.Add(1)
go func() {
defer wg.Done()
f, err := os.OpenFile("./log.txt", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
if err != nil {
panic("failed to open log file: " + err.Error())
}
defer f.Close() // 确保最终关闭
for msg := range logCh { // 使用 range 自动检测 channel 关闭
logTime := time.Now().Format(time.RFC3339)
_, _ = f.WriteString(logTime + " - " + msg) // 忽略写入错误仅作示例，生产环境需检查
}
}()
// 启动计算 goroutine 并发送日志
for i := 1; i < 10; i++ {
for j := 1; j < 10; j++ {
go func(i, j int) {
msg := fmt.Sprintf("%d + %d = %d\n", i, j, i+j)
logCh <- msg
fmt.Print(msg)
}(i, j)
}
}
// 所有发送完成，关闭 channel 通知消费者退出
close(logCh)
// 等待日志 goroutine 完成
wg.Wait()
}⚠️ 关键注意事项
-
永远不要忽略
err返回值：os.OpenFile和WriteString的错误必须显式处理，否则静默失败。 -
close(ch)是消费者退出的信号：只有发送方明确关闭 channel，range ch或ok检查才能正常终止循环。 -
使用
sync.WaitGroup精确等待：比time.Sleep更可靠，避免竞态或过长等待。 - 文件操作尽量复用句柄：高频写入场景下，反复打开/关闭开销大，且易触发系统限制。
-
考虑使用
log包或结构化日志库：如zap、zerolog，它们内置异步写入、滚动切割、错误恢复等能力，远超手写日志循环。
通过修正生命周期管理、channel 控制流与 I/O 配置，即可确保日志稳定、可靠地落盘。
