吸水效果好一点的运动衣

它没识别出“插件”，把“插”单独当动词了

@mara1 #7 潘铭允 图是隐形守护者的剧照

环境变量 build 时指定不同环境

都快成周经贴了。

来说下我对 HTTP Status Code 的理解：
HTTP 是在 REST （ Representational State Transfer ） 的指导下设计出来的。进行状态转移的是各个组件，组件可能包括浏览器这样的客户端，网关、代理这样的中间层组件，HTTP 状态码就是给它们用的。HTTP 本身就是这些组件的统一接口。
如果你想返回的资源需要在这些中间件进行处理，那么你需要返回一个合适的状态码。
如果你不依赖这些组件，那么为什么不用 RPC 呢？

再说 response 中的 code：
它的本质上是接口响应的错误消息，它不能代替 HTTP 状态码，也不能用 HTTP 状态码去代替它。
无论返回的是 `{"code":1}` 还是 `{"message":"error message"}`，都没有区别，只不过客户端不倾向于使用字符串来做判断，更愿意使用不容易改变的数字符号。

var httpClient *http.Client

post 的数据在 body 里，通过 HTTP 协议的 Content-Type 指定编码格式，如果你不设置 form 的 enctype 属性，默认是 application/x-www-form-urlencoded 编码。如果你想要精确类型的编码，一种常见的选择是使用 application/json 。

《 Larmes de caramel 》 http://music.163.com/song?id=17617362&userid=58837418

来了来了，继续当分母

看到这个标题我第一反应就是 MIT6.824 ，虽然我也没有学完

pr 的三种合并方式对应的应该是 merge 、rebase 、rebase squash

分母+1

成本太高，DDD 只靠着一个架构师是做不成的，它需要全团队的人都会，还要有领域专家

要去争取

“业务部门会认为系统的正常工作很重要。软件开发人员常常也采取了这种态度。但这种态度是错误的。”
“请记住，你作为一名软件开发人员。软件的可维护性需要由你来保护，这是你角色的一部分，也是你职责中不可缺少的一部分。”
“请记住：如果忽视软件架构的价值，系统将会变得越来越难以维护，终会有一天。系统将会变得再也无法修改。如果系统变成这个样子，那么说明你没有尽到自己的责任。”

以上内容节选自《 Clean Architecture 》，我觉得挺有道理的

目录结构是跟着架构走的，还是得看实际需求，所以也谈不上哪种最优

在家工作效率高，就是沟通不方便

GraphQL +10086