fork 与信号量在 go 中属不同层级：fork 是 os 级进程创建，需用 os/exec（首选）或慎用 syscall.fork；go 无原生信号量，常用 chan struct{} 模拟协程间计数访问控制。
fork 和信号量在 Go 中不是同一层级的概念，直接混用会引发根本性误解：Go 的 goroutine 是用户态轻量级线程，而 fork 是操作系统级进程创建系统调用，两者模型、内存视图、资源隔离程度完全不同。Go 标准库不提供 fork 封装（除 syscall.Fork 这类底层裸调用），也不鼓励用它——这和 Go 的并发哲学相悖。
所以，如果你目标是“掌握进程控制与并发资源管理”，得先分清场景：
什么时候真要用 fork？
仅当必须启动独立 OS 进程（如执行外部命令、需要完全内存隔离、规避 Go runtime 限制）时才考虑：os/exec.Command 是首选；syscall.Fork 极少用，且需手动处理 exec、wait、信号、文件描述符继承等细节，极易出错。
-
os/exec自动处理子进程生命周期、I/O 重定向、信号传递，99% 场景够用 - 直接调
syscall.Fork后若不立刻exec，子进程会复制整个 Go runtime 状态，可能引发 panic 或死锁 - 父子进程间无法通过共享变量通信，必须走 IPC（管道、socket、文件、信号量等）
Go 里“信号量”实际指什么？
Go 没有标准库 Semaphore 类型，但用 chan struct{} 模拟信号量是惯用法，本质是**协程间对逻辑资源的计数访问控制**，和 System V 或 POSIX 信号量（跨进程）无关。
- 初始化：
sem := make(chan struct{}, 3)—— 容量即最大并发数 - 获取：
sem —— 阻塞直到有空位 - 释放：
—— 必须配对，否则资源泄漏或死锁 - 别用
sync.Mutex+ 计数器模拟，它无法阻塞等待，得自己实现排队逻辑
为什么不能把 fork 和通道信号量混在一起用？
因为 fork 出的子进程不继承父进程的 Go channel，所有 chan 在子进程中失效（nil 或 panic）。试图用通道同步父子进程必然失败。
- 父子进程通信必须用 OS 级机制：管道（
Cmd.StdoutPipe）、Unix socket、文件、System V 信号量（需golang.org/x/sys/unix） - 若真要用信号量做父子同步，得用
unix.Semget/unix.Semop，而非 Go channel - Go 的
context.WithTimeout可配合os/exec实现超时控制，比手写信号量更安全
真正需要同时处理“多进程”和“并发限流”的系统，通常分层设计：上层用 Go channel 控制 goroutine 并发度，下层用 os/exec 启动独立进程，两者之间用 stdin/stdout 或临时文件交换数据——而不是强行把 fork 和信号量塞进同一个抽象里。
容易被忽略的一点：Go 的 runtime 对 fork 不友好。比如 CGO 开启时 fork 行为未定义；GC 正在运行时 fork 可能导致子进程卡死。除非你明确知道自己在做什么，否则绕开 fork。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
