只会狗刨

见识过好多并发调度框架，有DAG编排任务的、有分层编排的、也有仅简单封装go func() {}的......

对于业务系统，技术和代码都是以增加功能、解决问题、创造收益为目标。甲方应该应该是业务和PM，交货的是需求；技术需求也是类似的。围绕着需求，交付之道就是保障需求的各个阶段顺利进行：提出、开发、测试、上线

什么是扩展点？将代码或业务抽象成可自闭环的“模块”，比如在页面上的一个展示位置、比如业务逻辑中的一个处理function。一个模块就是一个坑位，但允许多种实现。简单来看，就是多态。

所谓的优化，不应该只是局限于让耗时P99、或CPU使用率、或SLI等指标变好。而是应该更广义地去看，即：现状存在什么问题、如何进行优化、如何保证不劣化、为什么无法优化。

某天，小伙伴和我分享面经，说问了面试官一个问题：业务迭代这么快，怎样避免代码堆成屎山而没办法维护。面试官说了挺多的.....

sync.Pool 是一个并发安全的缓存池，能够并发且安全地存储、获取元素/对象。常用于对象实例创建会占用较多资源的场景。

什么是 Mutex？为什么需要锁？如何实现锁？锁的效率如何？go sync.Mutex 的迭代经历你知道吗？sync.Mutex 有什么坑？请听下文：

nil 是什么东西？不是一个关键字，是一个变量，是一个预先声明的标识符。 go 中的实现 nil 的目标为：make the zero value useful。