Swoole协程是协作式调度、单线程、无需加锁但易因CPU密集任务阻塞；Go协程是抢占式调度、多线程、需显式同步但天然支持多核，并发模型、资源管理、错误处理和栈开销差异显著。
PHP开发者想进高并发团队，面试官八成会问Swoole协程和Go Goroutine的区别——这不是考概念背诵，而是看你能不能在真实场景里判断该用哪个、为什么、以及踩过什么坑。
协程调度方式不同，直接决定你写代码时要不要操心锁
Swoole协程是协作式调度，只有遇到Co::sleep()、Co::mysql->query()、Co::httpGet()这类明确的IO阻塞调用时，才会自动让出CPU；Go的goroutine是抢占式调度，哪怕你在for循环里算斐波那契数列，运行时也会在几毫秒后强制切走。这意味着：
- PHP里用Swoole协程时，同一时刻只有一个协程在跑，共享变量不用加
mutex，但你也别指望它能并行榨干多核CPU - Go里
goroutine天然多线程并发，但只要多个协程读写同一个全局map，不加sync.RWMutex或改用sync.Map，必崩（fatal error: concurrent map writes） - PHP协程切换开销极小（纳秒级），但一旦写了
while(true) { $i++; }这种纯CPU循环，整个Worker就卡死，其他请求全等
HTTP服务启动模型差异，影响你部署时的进程树结构
Hyperf（基于Swoole）默认启一个Master进程 + 多个Worker进程，每个Worker内跑事件循环+协程池；Gin启动就是单个http.Server实例，靠Go runtime自动把goroutine分发到多个OS线程上。这带来几个实操区别：
- Hyperf需要你手动配置
worker_num（通常设为CPU核心数），而Gin完全不用管——go run main.go跑起来就自动利用所有核 - Hyperf的
onWorkerStart回调里可以初始化DB连接池，但每个Worker进程一份，内存占用翻倍；Gin里sql.Open()一次就够了，连接池由database/sql统一管理 - Hyperf升级需reload整个Worker进程（
kill -USR1），Gin更新二进制文件后直接systemctl restart myapi，无热更能力但更可控
错误处理风格不兼容，PHP开发者容易低估Go的panic传播成本
PHP里try/catch能兜住绝大多数异常，Swoole协程里也一样；但Go的panic默认只在当前goroutine内传播，一旦没用recover()捕获，整个协程就静默退出——而你根本不知道它啥时候退出的。
立即学习“PHP免费学习笔记（深入）”；
- Hyperf里
Co::httpGet("http://bad.host")失败会抛Co\Exception，catch住就行 - Gin路由里如果某个
goroutine里panic了（比如空指针解引用），HTTP连接不会断，但日志里只有一行panic: runtime error: invalid memory address，且后续请求可能因资源泄漏变慢 - Go项目必须在每层HTTP handler开头加
defer func() { if r := recover(); r != nil { log.Printf("panic: %v", r) } }()，否则线上查不到问题源头
协程栈大小和生命周期管理，PHP开发者最容易忽略的内存陷阱
Swoole协程默认栈大小是2MB，Go的goroutine初始栈才2KB——这意味着同样起10万个并发任务，PHP侧内存占用可能是Go的1000倍。
- Hyperf里用
go function() { ... }创建协程，不显式Co::sleep()或IO调用，它不会自动释放栈空间，协程结束前一直占着2MB - Go里
go func() { ... }()启动后，只要函数return，栈自动回收，但如果你忘了关channel或没close(http.Response.Body)，goroutine会永远卡在recv或read状态，变成泄漏 - Hyperf可配
coroutine.stack_size调小栈（如512KB），但太小会导致深层递归直接崩溃；Go没法调栈大小，但可以用runtime.Stack()定期采样排查泄漏
真正难的不是记住“Swoole单线程”“Go多线程”，而是当你面对一个实时消息推送服务时，得立刻判断：该用Swoole的Co::redis->publish()配WebSocket长连接，还是用Go的gorilla/websocket加select监听多个channel——前者改两行PHP就能上线，后者要重写整套错误恢复逻辑。
