最早碰并发我是怵的。线程一多就上锁，锁多了又死锁，调起来真头大。后来摸了Go，一个go关键字把函数往协程里一丢就跑，栈初始才几KB，开它几千上万个也不带喘，这轻量有点离谱。
更对胃口的是它的路子：别死磕共享内存加锁，改用channel通信。官方那句原话讲得通透，用通信来共享，而不是用共享来通信。数据在channel里流转，谁要谁取，竞态（race condition，好几个协程抢同一块数据出的乱子）从源头上就少一大半。
标准库也够硬，net包自带的调度省心，几行就能搭个并发小服务。咱这种半路出家的，照文档也能跑通，写完是真舒坦。技术嘛，顺手就舍不得放下了。
前排。吧我纯外行居然看进去了，你那个"别抢同一块数据、排好队过channel"的讲法莫名好懂哈哈。所以搞这个真会一碰就上头？照文档就能跑通的话还挺诱人，上手门槛高不高的呀
开几千个协程都不带喘，这轻量感太迷人了。会好的数据在channel里流转着走，想想都觉得省心。
channel那套我挺服的 之前搞游戏抢数据抢到崩 换成传数据思路之后清净多了
看到"用通信来共享，而不是用共享来通信"这句，我一下子就记牢了，讲得是真通透。前阵子跟着byteive他们瞎凑热闹也摸过两下Go，最开始也是死磕锁，调着调着就晕，后来试着走channel的路子，嘿，确实没那么容易自己跟自己打架了。这种"顺手就舍不得放下"的感觉太懂了，好用的东西就是这样，一旦合上脾气就总惦记。
channel那个思路真妙，竞态从源头就少掉，比死磕锁松快太多。遇到顺手的东西舍不得放，太正常啦
channel这套’用通信来共享’我是真服，比满屏加锁清爽太多。不过几千协程一起跑，真出毛病时定位怕不是另一重人间疾苦。
等等，你引那句"用通信来共享而不是用共享来通信"——我怎么听说的版本不太一样。
前阵子听个在Google待过的朋友碎碎念，说Go当年拍板channel这套，内部吵得相当凶。一拨人觉得这不就是CSP那套老理论换个皮，还有人嫌它吞吐不如裸锁猛。Rob Pike他们硬扛下来，我私下猜不全是为了优雅，跟想让Go好招人脱不了干系。不是语法少、概念浅，半路出家的照文档能跑通，这不正好对上你说的那种舒坦。对了
啊
但这层复杂度是藏进runtime了，平时写爽，真翻车debug就是黑箱。我认识一哥们当初也被几千个协程不带喘圈粉，结果channel死锁在生产环境，查了一整周。所以我看轻量有点离谱这话，总想偷偷补半句：爽是真的爽，坑也是真的换了个地方蹲着。
几千上万个协程不喘气就跑起来，这大概就是Go最勾人的地方——谁还没被线程加锁折磨到想摔键盘。不过你那句"竞态从源头少一大半"我得泼点冷水：channel真不是免死金牌。我当初也是被这口号哄开心，结果select写岔了，goroutine全卡死，调一晚上才发现是有人只往里塞不收。说真的，channel用岔了漏出去的协程比锁还难查。Go顺手归顺手，"别死磕共享内存"这话轻巧，真写业务该上锁的地方一个都跑不掉。你那小服务压过测没，别光本地跑通就飘了 (￣▽￣)
我怎么听说的版本不太一样。你们知道吗，channel那句"用通信来共享"喊得越响，圈里私下吐槽的人就越多。我听一个搞后端的朋友讲，Go团队自己后来其实有点往回找补的意思，文档和talk里都慢慢透出"临界区小就直接上锁，别硬套channel"的味道。Rob Pike那原话当然漂亮，可真到几万个goroutine互相等channel，死锁调起来比线程锁还邪乎。我听说有些老项目悄悄把channel换回Mutex，就图个好debug。你们有没有觉得这口号和实战之间总差着口气？
我也是一碰就上头那类人 打游戏最明显 一开就天亮 根本舍不得关
几千协程不带喘这点太离谱了，我电脑开五个网页都哼哼
那句"用通信来共享 不是用共享来通信"我先码住了 听着像句偈子 别抢 谁来取 莫名对味儿
你们有没有人跟我一样，刚被go关键字惊艳完，转头就在channel上栽了跟头？楼主说的通信代替共享我举双手赞成，思路是真干净。但说真的，channel用岔了死锁起来一点不比加锁温柔，我见过select里忘写default的，主协程干等到天亮跟等前任回消息似的。开几千协程不喘是真爽，可那一窝goroutine到底跑没跑完，你都未必说得清。
顺着你那条『channel 让竞态从源头少一大半』的说法，我倒觉得得拆细一点。channel 改变的是 bug 出现的形态，不等于把竞态按掉大半那么多，『少一大半』这个数本身也没见谁量化过，是直觉还是跑过 benchmark？
具体例子：你把一片 slice 通过 channel 传给另一个 goroutine，传过去的是 slice header，底层数组还是同一份。接收方在遍历、发送方（或别处）在 append 改写，底层数组一冲突，照样是 data race，go run -race 一跑就报红。其实再比如 close 一个 channel 两次会直接 panic，多个 goroutine 抢着关同一个 channel 时，你还是得靠 sync.Once 或者约定唯一的关闭者，绕了一圈又回到同步原语上。
其实
社区里那句『channels orchestrate, mutexes serialize』更实在些。带缓冲的计数器、几个 goroutine 共享一个 struct 字段这类场景，直接上 sync.Mutex 往往比用 channel 来回传指针清晰，也少一层 goroutine 泄漏的坑。Go Proverbs 里那句『don’t communicate by sharing memory, share memory by communicating』本意是劝你别一上来就靠锁堆共享状态，不是说锁从此退休。
真要兜住竞态，靠的其实还是 -race 这种动态检测，而不是『我用了 channel』这个姿势。从某种角度看，channel 更大的价值是让并发结构更好读：谁发谁收一眼能看清，而不是安全性的银弹。
你那句『开几千上万个不喘』我顺手压过，二十来万常驻 goroutine 在普通机器上也没见它喘，但前提是它们大多在等 channel 或 timer，不是真在烧 CPU；真都要卡系统调用上，得看 GMP 里 P 的数量和 sysmon 的抢占。stack 初始 2KB 这点你说得准，现代 Go 走连续栈动态扩，早期分段栈那段历史就不展开了。
你现在是纯 channel 派，还是看场景混用？
我年轻的时候也迷信过那句"用通信来共享"，觉得锁都能扔了。后来才晓得，业务一复杂，channel照样能绕成死结。路子是好的，可脑子乱了啥都白搭。
上头是真的，连我这种三脚猫都心动了哈哈，回头照着文档糊一个玩玩
读到’几千上万个也不带喘’的时候我忍不住笑了，这个形容真可爱。我平时不怎么写Go，但听你讲完那个channel的思路，莫名觉得挺安心的，数据规规矩矩排着队流动，谁要谁取，比一堆人围着抢同一块东西要体面多了。你说的’顺手就舍不得放下’我挺能体会的，找到趁手的东西那种踏实感，真的会上瘾。草，看得我都想去翻翻文档试两行了。