下个反诈 app，可以直接举报短信

@yusheng88 #4 接口的响应数据是与业务紧密关联的，需要服务于调用者。
比如 DELETE 操作，一般情况下是可以响应 204 status，同时响应内容为空。可如果你的业务需要在删除后响应一个关联的资源内容，那么就应该响应 200 status，同时响应关联内容。

在我看来幂等性和响应内容是无关的。

从 HTTP 的设计上来看。它为 methods 设计两种特性，安全性和幂等性，同时安全的一定是幂等的。安全性表示用户可以随意调用该接口，而不用担心对资源的影响，幂等性表示用户无论调用多少次该结构，对其资源的影响是一定的。
GET：安全且幂等
POST：不安全且不幂等
PUT：不安全但幂等
DELETE：不安全但幂等

先撇开安全不谈，幂等性的设计好处是什么呢？这就是我们设计接口时 POST 和 PUT 的区别。当你将接口设置为 PUT 时，就表示告诉了调用者，这个接口是可以重试的。
用最常见的新增场景来表示，POST 和 PUT 都可以用来添加资源，但 POST 不能重试，每一次请求都有可能添加一个新资源； PUT 可以重试，它只会在服务器中增加一个用户所描述的资源，无论用户重复调用多少次。

给一个典型的例子，为什么 Github v3 API 的 Star 操作是 PUT 而不是 POST，应该就是有幂等性的考虑。
https://docs.github.com/en/rest/reference/activity#star-a-repository-for-the-authenticated-user

@JZWen #7 感兴趣的话可以看看这本书的前两章，作者直接给出了软件架构是什么、以及软件架构的重要性。微信读书里就有。

我理想中的软件架构师应该是整洁架构之道中所描述的那样：
能够设计出优秀的软件架构，增加开发者的生产力。能够为了软件的可维护性与需求方或其他任何没有能力评估软件架构能力的团队进行抗争。
保证我作为一个开发者，能够始终在一个可以让功能实现起来更容易、修改起来更简单、扩展起来更轻松的软件架构中工作。

@stimw #9 有没有什么鸡汤推荐一下，最好是看一句话就像打鸡血一样 😂

粗略看了一下，这是《 DevOps 实践指南》的读书笔记吧。有时间还是建议看原书，原书中有大量的理论来补充说明这些观点。

建议举报，国家反诈中心 app，直接选择那条短信就能举报

我最近膝盖也有些不舒服，水泥马路太硬了，各位还是要注意一下

如果还想看大夫，最好是去北京武警总医院挂李志强医生的号，北京的医院挂号有专门的网站，号不算太抢手，提前几天是能挂上的。

平时可以去《白白手拉手》这个论坛多看一看，也可以跟其他病友聊一聊。这个病是有一定概率治愈的，尤其是前期。https://www.bbsls.net/forum.php

我大概四五年前得过，然后用了半年治好了。

白癜风最主要的治疗手段是照 308 激光。有条件一定要照这个，这个机器很贵，大部分医院都没有。如果所在城市没有的话可能就要去省会城市的医院。

@lesismal #43 我明白你的意思，我现在已经不再认为我的示例代码中的顺序是一致的了，chan 也只是将接收器 /发送器标记为下一个要运行的 goroutine，但不能保证其一定是下一个运行的。哪怕是在我的示例代码中尽可能少的影响因素也是一样，因为还有抢占式调度。
我现在的结论也只是从 chan 的运行逻辑上解释两两输出的可能性，但 chan 不能必然导致两两输出。

其实结论已经不重要了，谢谢你帮我认识到我对于 go runtime 理解的不足。

@lesismal #39 抢占式调度我的理解之前确实有些问题，现在我也知道我的示例代码也会被抢占了。

我现在已经没有纠结对错了。只是我认为的是 chan 的队列机制导致的两两输出，然后你说 runtime 中可能会有其他可能对顺序造成影响，所以出现乱序。但我还是没明白为什么这就说明我的结论不能解释两两输出的现象了。

@lesismal #35 所以你也不是认为 print 影响的调度，而是说 print 前对 chan 操作并不能固定顺序，因为 runtime 有其他更多的可能性会对顺序造成影响。

我之前大部分的时间都是思考为什么两两输出，没有考虑到更多其他变量对顺序造成的影响。再加上我之前的表述可能也有问题。
所以我们的结论并不是矛盾的

@lesismal #33 我这里的代码确实有些问题，因为我要调试 chan 源码部分，所以尽量屏蔽了其他的调用，导致我没有发现乱序的存在，”绝对是连续两次“这个结论过于武断了。很抱歉。

不过去掉偶尔存在的乱序问题，连续两次的输出可以认为是 chan 等待队列机制的作用吗？