最近我在做 worker 任务系统的时候，突然意识到一个很关键的问题：

以前写 Python，多 worker 的时候经常要小心日志串、文件切割乱、时间不好管理。
但是换成 Go 以后，一个进程里开多个 goroutine worker，反而可以比较自然地写到同一个日志文件里。

一开始我以为这是“Python 和 Go 写日志能力不一样”，后来想明白了，核心不是日志本身，而是：

Python 常见 worker 模型：多进程
Go 常见 worker 模型：单进程 + 多 goroutine

这背后其实是两个语言在并发模型上的巨大差异。

一、进程、线程、goroutine 先分清楚

先把几个概念捋一下。

进程：操作系统分配资源的单位
线程：CPU 调度执行的基本单位
goroutine：Go 语言自己的轻量级并发任务

一个进程可以有多个线程。

Go 的 goroutine 不是操作系统线程，但它会被 Go runtime 调度到底层 OS 线程上执行。
所以你写的是：

go worker()

但真正跑的时候，Go runtime 会把大量 goroutine 分配到多个线程上，再由操作系统把线程分配到多个 CPU 核心上。

大概可以理解成：

多个 goroutine
    ↓
Go runtime 调度
    ↓
多个 OS thread
    ↓
多个 CPU core

所以 Go 的单进程，并不等于只能用一个 CPU 核心。

二、Python 单进程通常更像“一个核心”

这里说的 Python，主要指最常见的 CPython。

Python 有一个非常重要的东西：GIL，全局解释器锁。

它的影响是：在一个 Python 进程里，就算你开了多个线程，CPU 密集型任务通常也很难真正同时跑在多个 CPU 核心上。

比如：

import threading

for i in range(4):
    threading.Thread(target=worker).start()

看起来是 4 个 worker，但如果 worker 做的是 CPU 密集型计算，通常并不能真正吃满 4 个核心。

所以 Python 里面常见的选择是：

想吃多核心 → 开多进程

比如：

gunicorn -w 4
celery 多 worker
uvicorn --workers 4
multiprocessing

这时候就变成：

Python worker 1 = 一个进程
Python worker 2 = 一个进程
Python worker 3 = 一个进程
Python worker 4 = 一个进程

这样确实可以吃多个 CPU 核心，但副作用也来了。

三、Python 多进程的问题：隔离性强，但管理复杂

Python 多进程的好处是隔离性好。

一个 worker 崩了，不一定影响其他 worker。
一个进程卡死了，其他进程也可能还活着。

但是多进程有一个很明显的问题：每个进程都有自己的内存空间、文件句柄、logger、缓冲区。

这就会导致很多麻烦。

比如四个 Python 进程同时写一个日志文件：

worker1 写 app.log
worker2 写 app.log
worker3 写 app.log
worker4 写 app.log

可能会遇到：

日志内容交错
日志切割冲突
多个进程同时 rename 文件
一个进程还在写旧文件，另一个进程已经切到新文件
时间边界不好处理

尤其是按天切日志的时候更麻烦：

2026-04-28.log
2026-04-29.log

到了零点，四个 worker 都可能判断“该切日志了”。
于是就会出现争抢、错乱、重复切割、文件句柄不一致等问题。

所以 Python 多进程里，经常会有两种做法：

方案一：每个 worker 写自己的日志文件

例如：

worker_1.log
worker_2.log
worker_3.log
worker_4.log

或者：

方案二：所有 worker 把日志发到一个队列，由专门的 logging listener 统一写

也就是：

多个 worker 产生日志
        ↓
日志队列
        ↓
单独日志进程统一落盘

这其实就是为了避免多个进程同时抢一个文件。

四、Go 单进程为什么舒服？

Go 的常见并发模型不是多进程，而是：

一个进程
里面开很多 goroutine

比如：

for i := 0; i < 4; i++ {
    go worker(i)
}

这不是四个进程，而是一个 Go 进程里的四个 goroutine。

它们共享：

同一个进程空间
同一个 logger
同一个配置
同一个数据库连接池
同一个 Redis 连接池
同一个任务状态管理

所以日志管理就简单很多。

Go 标准库里的 logger 通常是带锁的。多个 goroutine 写同一个 logger 时，会串行化写入，不会像多个独立进程那样各写各的。

可以理解成：

goroutine 1 要写日志 → 加锁 → 写完 → 解锁
goroutine 2 要写日志 → 等待 → 加锁 → 写完 → 解锁

所以 Go 单进程多 goroutine 写同一个日志文件，天然比 Python 多进程更好管。

五、Go 单进程也可以吃多个核心

这个点非常关键。

很多人容易误会：

单进程 = 一个 CPU 核心

这个理解不准确。

对 Go 来说，一个进程里面可以有很多 goroutine。
Go runtime 会把 goroutine 调度到底层多个线程上，多个线程再跑到多个 CPU 核心上。

所以 Go 可以做到：

一个 Go 进程
    ├── goroutine 1 → thread 1 → core 1
    ├── goroutine 2 → thread 2 → core 2
    ├── goroutine 3 → thread 3 → core 3
    └── goroutine 4 → thread 4 → core 4

也就是说：

Go 单进程 ≠ 单核心
Go 单进程可以天然使用多个 CPU 核心

这个能力由 GOMAXPROCS 控制。

现在 Go 默认会根据机器 CPU 核心数设置，一般不用手动改。

这也是 Go 写 worker 系统很爽的地方：
你只需要写 goroutine，不需要自己管理线程池，不需要手动搞多进程。

六、Python 和 Go 的核心区别

可以简单对比一下。

Python 常见模型

单进程 + 多线程：
适合 I/O 密集型任务
CPU 密集型受 GIL 限制明显

多进程：
可以吃多核心
隔离性好
但日志、状态、内存、通信更复杂

Go 常见模型

单进程 + 多 goroutine：
可以吃多核心
日志好统一
状态好管理
开发体验更直接
但进程挂了，里面所有 goroutine 都会受影响

所以区别不是：

Python 差，Go 好

更准确是：

Python 更常依赖多进程来吃多核心
Go 更常用单进程多 goroutine 来吃多核心

七、多进程和单进程的真正取舍

这件事本质上是一个取舍：

隔离性 vs 管理复杂度

多进程 / 多容器的优点：

隔离性更强
一个 worker 崩了，不一定拖死全局
可以更方便地做横向扩展
适合高可用部署

缺点：

日志文件不好共享
内存状态不能直接共享
进程间通信更麻烦
配置、连接池、缓存都有多份
任务状态同步更复杂

单进程 + 多 goroutine 的优点：

日志统一
状态统一
配置统一
连接池统一
开发体验舒服
任务调度简单
一个进程内就能吃多个 CPU 核心

缺点：

进程级故障影响面更大
一个 panic 没处理好，可能整个服务挂掉
单进程内存爆了，全体 worker 都受影响
滚动更新和高可用要额外设计

所以不是说 Go 就可以永远无脑单进程，而是：

单机服务 / 中小规模任务 / 队列 worker
Go 单进程 + 多 goroutine 非常合适

等到规模上来了，再考虑多容器、多副本。

八、现在做 Go worker，比较推荐的结构

对于一个任务系统，我觉得很适合这样设计：

一个 Go 服务进程
    |
    |-- HTTP API 接收任务
    |
    |-- Redis Stream / DB / channel 保存任务
    |
    |-- N 个 goroutine worker 消费任务
    |
    |-- 统一 logger
    |
    |-- 统一 task status

每条日志里带上关键字段：

task_id
worker_id
request_id
status
duration
error

比如：

2026-04-28 12:00:01 worker=1 task=abc123 status=started
2026-04-28 12:00:05 worker=1 task=abc123 status=done duration=4s
2026-04-28 12:00:06 worker=2 task=def456 status=failed error="timeout"

这样一个日志文件也不会乱。
真正查问题的时候，按 task_id 或 worker_id grep 就行。

九、Go 单进程也要做保险

Go 单进程多 goroutine 虽然舒服，但不能完全裸奔。

至少要有这些保护：

panic recover
任务超时控制
Docker restart
关键任务状态落 Redis / DB
日志带 task_id
控制最大并发数

尤其是 worker 里最好包一层 recover：

func safeWorker(workerID int) {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("worker=%d panic=%v", workerID, r)
        }
    }()

    worker(workerID)
}

启动 worker：

for i := 0; i < 4; i++ {
    go safeWorker(i)
}

更成熟一点，可以让 worker 崩了以后自动重启：

func runWorkerForever(workerID int) {
    for {
        func() {
            defer func() {
                if r := recover(); r != nil {
                    log.Printf("worker=%d panic=%v, restarting", workerID, r)
                    time.Sleep(2 * time.Second)
                }
            }()

            worker(workerID)
        }()
    }
}

这样可以避免某个任务异常直接把整个 worker 干没。

十、什么时候 Go 也该多进程 / 多容器？

如果遇到这些情况，就该考虑从单进程升级了：

单机 CPU 不够
单进程内存压力太大
需要高可用
需要滚动更新不中断
一个进程挂掉影响太大
不同任务需要资源隔离

这时候可以变成：

多个容器副本
每个容器内部还是多个 goroutine worker

也就是：

app-1：一个 Go 进程 + N 个 goroutine
app-2：一个 Go 进程 + N 个 goroutine
app-3：一个 Go 进程 + N 个 goroutine

不过到了多容器阶段，就不要让多个容器抢同一个日志文件了。

更推荐：

每个容器写 stdout
Docker / journald / Loki / ELK 统一收集

也就是说成熟形态不是：

多个容器共同写 app.log

而是：

app-1 stdout
app-2 stdout
app-3 stdout
        ↓
统一日志系统

总结

Python 和 Go 在 worker 模型上的差异，可以这么记：

Python：
想稳定吃满多核心，常用多进程。
多进程隔离性好，但日志、状态、通信更复杂。

Go：
一个进程里开多个 goroutine，就可以利用多个 CPU 核心。
单进程多 goroutine 日志好管、状态好管、开发体验更舒服。

所以对中小规模任务系统来说，Go 的单进程多 goroutine 模型非常香。

但也要记住边界：

Go 单进程不是只能吃一个核心
Go goroutine 可以被调度到多个核心上执行

Go 单进程管理简单
但进程挂了，里面所有 worker 都会受影响

前期可以单进程多 goroutine
后期规模上来，再多容器多副本

我的当前结论是：

单机阶段：
Go 单进程 + 多 goroutine worker + Redis/DB 保存任务状态 + 统一日志

规模阶段：
多个 Go 容器副本 + 每个副本内部多 goroutine + stdout 统一日志采集

这样既能享受 Go 的简单并发模型，又不会在后期扩展时被单进程架构卡死。