案例加分析，恰到好处

我的总结是个人收获，请注意：

1）如何自定义golang的Tag，如何写Tag的解析代码？看起来这个问题，系统已经支持了；

2）在io密集型服务中，gomaxprocs可以设置大一些，不一定采用默认值（核数）。这块到底设置多少，还没有看到具体的经验。

3）所有的技术架构都与组织架构有关。因为边界决定了资源的维护方式和责任。

4）如何调试hung住的进程？如果比较好复现，可以用go mod replace来进行包替换，调试底层代码；

5）闭包变量发生了逃逸，用gcflag=m检查。

6）参数传递指针还是非指针好呢？这块根据项目经验，我全部都是指针，但是要注意，在不该修改的时候不要修改。

7）cas算法，比较交换算法。

8）gin框架的context是什么类型？是值类型的context。

9）web接口不适合跑长期任务，因为会随时杀掉。那么如何识别呢？是否加一个全局变量来统计和计算，当前还有多少逻辑任务在处理。

10）饥饿的判断标准是1ms。

11）竞争锁的实现方式，加锁，再加一，判断数量，就知道是否有多个在竞争。直到0才返回，结束阻塞。

12）如何基于mutex基本锁，实现一套读写锁。

13） go test one.go -run get/one1

14）fmt.Errorf 我竟忘了用这个。还自己封装了一下。改一改。

15）单个函数的defer数量，如果再8个以下，deferBits的位数就是8。无法使用开放编码defer（另外是栈defer和堆defer）。关闭了调优也是无法使用开放编码defer的。

16）go tool compile -S ./panic/compile.go 编译文件；

17）panic 的函数，返回值是默认值；因为逻辑没有执行完。return本质上是两个步骤，赋值+返回。而defer是在中间执行的，有机会修改返回值。

18）多次panic只需要一次recover就可以恢复到运行状态。defer和panic本质上都是链表实现。

19）作者善于提问，善于分析，值得学习。

20）ticker一定要回收资源。否则一直在监听。

21）如何保证所有接口都释放完毕了，而不是固定等待时间呢？可以设置一个计数器。

22）为了避免panic，我们要么检查参数，要么检查返回值，这个if的判断是无法减少的。所以底层不返回error，还是panic掉，这块值得斟酌，因为ticker里面传递了小于0的duration是直接panic的。多做检查不是坏事。

23）golang有package的init方法，为什么没有finish方法？

24）gvm可以用来管理本地多个golang版本进行调试。

25）go list -m all 查看实际的依赖版本和顺序。

26）indirect 是间接引用，两个原因，第一个是底层包么有支持go.mod，第二个底层go.mod不完整，么有加全所有的require；

27）go mod why 解释包的依赖原因。

28）goprivate 等，direct是直接访问，逗号分隔多个proxy的意思。