把学到的东西写下来，是最好的学习方式。
这里记录着我在技术路上的所见所思——有踩过的坑、有解决问题的喜悦、也有对技术趋势的思考。希望这些内容对你有所帮助。
按时间倒序排列，最新的在最前面 👇
做过一段时间交易的人大概都有过这样的经历：
你精心研究了一套趋势跟踪策略，回测数据漂亮得让人兴奋——年化收益 40%，最大回撤可控，夏普比率超过 2。然后你满怀信心地实盘运行，结果发现： 震荡市里它被反复止损割肉 ，好不容易等来一波趋势，前面的利润已经亏掉大半。
反过来，如果你用网格交易在震荡市里收割差价，看似稳定盈利，结果一根大阳线或者一根大阴线打过来——要么踏空起飞的行情，要么被深套动弹不得。
这就是单一策略的宿命： 每种策略都有它的舒适区，也都有它的死穴 。
那有没有可能，让不同策略各司其职，在它们各自擅长的领域里发挥作用？
某场 AWS Summit 的演讲里，有一张幻灯片我盯着看了很久。它没讲任何模型架构、没列任何 benchmark，却把"AI 为什么难以真正落地"这件事一句话戳穿了：瓶颈往往不在模型，在 Pipeline。
幻灯片的核心观点是：以模型为基础，结合业务特点，构建 Pipeline—— 把业务说明书从「给人看」适配成「给 AI 看」。
国统区那边经济一团糟，老百姓吃了上顿没下顿。苏区这边虽然也穷，但至少有条理、有奔头。
这就是读这篇最直接的冲击。不是苏区条件好——恰恰相反，苏区的成果是在国民党军事围剿加经济封锁的双重高压下打出来的。越是这种局面越要搞经济，因为经济搞不好，政权活不下去。
你刚写完一个技术方案，熬了几个晚上，自认为逻辑严密、考虑周全。结果汇报时，领导听了五分钟就打断：“你到底想说什么？” 或者更糟——领导没打断，但全程面无表情，最后说“再想想吧”。
汇报翻车，不一定是你方案不行，而是 你没让领导听懂、没让领导相信、没让领导记住。
本文从 内容设计 和 表达技巧 两个维度，系统性地拆解“如何做一场有效的汇报”。
并发 bug 是所有 bug 中最难复现、最难定位的一类。它们往往在代码 review 时看不出来、单测跑不出来，直到生产环境高并发场景才爆发。
本文按「反模式 → 正确模式」成对罗列，结合项目中真实处理过的案例来说明——每一条都是踩过坑或差点踩坑的教训。
给谁看：Go 开发者、做并发模块/客户端 SDK 的同学 看完能干嘛：拿到一份可直接套用的排查清单，写出 3 次重复调用都不会死锁的 Close/Stop 方法
给谁看 ：长安链小组研发同学 看完能干嘛 ：理解模块测试的本质，掌握 5 个可复用范式，照清单给自己的模块从零搭一套真正能"提前抓 bug"的模块测试
怎么读 （建议从头到尾顺序读）：
环形缓冲区是我最喜欢的数据结构之一——它只需要一行公式就能让固定内存永不溢出。本文从最简原理出发，逐步推导到 ChainMaker BirdsNest 模块中的真实工程应用。