@lesismal #22 我在 15 层的回复也解释过是设置为下一个要唤醒的 goroutine 。同时我认为你在 12 楼的解释将其认为是 printf 造成的调度我不认可，你也没有给出论证。我还是认为 chan 本身的特性所导致的，这个特性就是 chan 的等待队列可直接传值的操作。

@lesismal #20 如果考虑到其他调度的话是超出讨论范围了，我只是思考了为什么会有连续两个输出而不是交替输出的问题。我的代码中也屏蔽了其他任何可能调度的影响。

其实在真正的使用中是要避免依赖这种 runtime 的执行顺序，Go 文档中也不会提及内部的实现是有接收器 /发送器队列的。

@lesismal #16
以 recv 举例，for 因为阻塞被断开了：
第一次执行 0.5，阻塞。
回来后继续执行 0.5 （输出），然后执行完整的 1 个 for （输出），然后再次执行 0.5，阻塞。

虽然 call recv 函数的次数是 2，但因为阻塞，for 中的整体逻辑被分割了。

@lesismal #16 你可以看下我的输出日志，连续两个的 print 中，第一个永远是上一次 for 的继续执行，而不是这一次 for 的两次执行中的打印，所以我说“但输出和访问 send 和 recv 函数的顺序是不一样的，因为存在阻塞”，因为两次中的后一次，要等待阻塞结束后来后才能输出。只是表现形式是连续两次。

这里只要 runtime.GOMAXPROCS 设置为 1，那么除了第一次和最后一次（如果存在的话）外，其他的输出绝对是连续两次的，这与 goroutine 的调度没有关系，因为只有一个 p 在运行。
也与抢占式调度没有关系，因为每次都是依靠 chan 进行手动调度。

@cmdOptionKana #7 如果要用玩游戏对比，应该是有新游戏的出现，需要高性能，提高了显卡的价格。这是我认为价值的基点，有市场，有需求，那些人买显卡是为了玩到新游戏。虽然我不是专业的经济学研究者，但这符合我的逻辑。

可是虚拟货币在我看来更像是郁金香泡沫，把比特币换成郁金香，显卡换成适合培育郁金香的土，也没有什么区别。

玩游戏买显卡是为了用，而不是为了买到后想着提高价格再卖出去。

对于我而言，我厌恶的是矿工们将算力用于无意义的行为上。这可能是由于我不了解虚拟货币共识的价值，不明白为什么基于共识而不是基于现实就能产生价值...

这主要是由于 channel 的内部实现机制，channel 的 send 或 recv 操作在发现有等待中的接收器（ chan.recvq ）或发送器（ chan.sendq ）时，会直接把值交给它，并向其设置为下一个要唤醒的 goroutine 。然后在循环中再次的操作，才会阻塞，阻塞时自己也会在相应的等待队列中。所以每次的 send 或 recv 操作，都会执行两次，输出的形式也是连着输出，但输出和访问 send 和 recv 函数的顺序是不一样的，因为存在阻塞。

这个是比较直观一些的代码，因为调度不一致，所以我用 runtime.Gosched() 方法保证一定是 recv 的 goroutine 先运行。
https://play.golang.org/p/wmU0fpTt5uf

这里是带有 Go Channel 源码部分的一些打印：

------------- call unbuffered channel recv ---------------- # 接收器先启动，调用 recv 时阻塞并将自己放入队列
------------- call unbuffered channel send ---------------- # 发送器启动，调用 send，并尝试获取
------------- unbuffered channel send ---------------- # 发现队列中有可用的接收器，尝试直接发送
------------- unbuffered channel sent ---------------- # 成功
written0 #继续向下执行，打印 witten
------------- call unbuffered channel send ---------------- # for 执行到第二次，调用 send，阻塞了
received # 发送器在发送时，直接修改了接收器的执行栈，所以接收器不需要从阻塞那里再次运行，而是得到值，并继续向下执行，也就是打印
------------- call unbuffered channel recv ---------------- # for 执行到第二次，调用 recv
------------- unbuffered channel receive ---------------- # 发现队列中有可用的发送器，所以直接取值
------------- unbuffered channel received ---------------- # 成功
received # 继续向下执行，打印 received
------------- call unbuffered channel recv ---------------- # 再次调用 recv，但此时队列已经空了，所以阻塞
written1 # 此处的打印是上面被阻塞的 send 的向下执行，同样发送器也不需要在阻塞处继续执行，而是向下执行，所以直接打印第二次循环的输出
------------- call unbuffered channel send ---------------- # 下面就不用详细讲了，都是一样的流程
------------- unbuffered channel send ----------------
------------- unbuffered channel sent ----------------
written2
------------- call unbuffered channel send ----------------
received
------------- call unbuffered channel recv ----------------
------------- unbuffered channel receive ----------------
------------- unbuffered channel received ----------------
received
------------- call unbuffered channel recv ----------------
written3
------------- call unbuffered channel send ----------------
------------- unbuffered channel send ----------------
------------- unbuffered channel sent ----------------
written4
received
------------- call unbuffered channel recv ----------------

如果想看源码来调试或了解，推荐看这里： https://golang.design/under-the-hood/zh-cn/part1basic/ch03lang/chan/

看过你的博客文章《译：做一家不开会，不设置 deadline，甚至没有全职员工的公司》，想请问下进展如何，这样真的有可行性吗

DDD 的副标题就是：软件核心复杂性应对之道。很多时候软件的复杂性不在于软件技术的使用，而是业务的复杂性，所以 DDD 就聚焦于业务逻辑，通过各种方法来为业务建模，来保证不会因为业务的巨大复杂性而陷入困境。
我一直认为我没学会 DDD 的原因之一就是还没遇到过于复杂的业务逻辑......

@aboat365 #79 是的，现在 JWT 使用场景更多了，但也不能说 JWT 替代了 session，哪怕是 OIDC 中也不是用 JWT 格式作为 accesstoken 。服务端在有相应的场景下，该存的状态还是没少，其实是等同于 session 机制，只不过是原来 session + cookie 被现在的流行的认证格式取代了。

想起了我几年前的提问帖子......《请教各位一个问题, 为什么 session 机制没有被 JWT 所取代?》

现在 JWT 有了更多的使用场景，其实已经有很大的发展了。

REST 不是规范，它是一种架构风格，是在许多种架构中组合推导出来的，它的优点就是这些架构所能带来的好处，最终形成的架构风格是能满足互联网规模的分布式超媒体系统的需求。
而 RESTful 风格的 API 设计具体能带来什么好处，还是要根据这些来理解的。

跑前热身是很重要的，而且听你描述应该是刚开始跑，建议放慢一点速度，肌肉就不会那么快的绷紧。最后姿势也很重要，小腿前侧肌肉最先出现反应，我猜测你是脚后跟先着地的概率大。
鞋的部分反而是次要的，只要是跑步鞋，在里程不高的情况下问题不大。

@horseInBlack #33 扎心了，我还劝别人呢，自己都还没有候补到 😂

可以看看这本书作者提供的书单，虽然这本书讲的是重构，但重构和设计是分不开的
https://github.com/phodal/migration