我在做一个跨语言的算子引擎，同一套语义分别用 Go、Java、C++ 实现。有一处用到了读写锁——一个请求局部的数据结构，多个算子并发读它的字段，偶尔有写。三个实现都用各自语言「标准」的读写锁：Go 的 sync.RWMutex、Java 的 ReentrantReadWriteLock、C++ 的 std::shared_mutex。
某次做性能剖析时，我注意到一件有点意思的事：C++ 这边，读写锁的单次拿放在 profile 里是个能看见的开销；而 Go 和 Java 那边，同样形态的拿放几乎不出现在火焰图里。同样一把读写锁，凭什么 C++ 要贵这么多？
这篇文章记录我顺着这个疑问挖下去的整个过程：先用反汇编搞清楚 glibc 的 pthread_rwlock 到底慢在哪、Go 为什么便宜，然后把 Go 的算法移植到 C++（中间失败了一次），最后发现这个原理上完全正确的优化，在真实负载上根本测不出收益。这最后一点，可能是整件事里最值得说的。
某次 VSCode 升级之后，我从 macOS 连远端开发机的 Remote-SSH 突然进入了死循环：客户端每隔几秒发起一次新的 SSH 连接，每次都能通过 pubkey 认证、能在远端拉起 vscode-server，但十几秒后就 timed out，紧接着 attempt N+1。前后连了几十次都接不上。
机器上没有任何代码改动，远端服务可达，公钥认证也没坏。问题出在客户端的某个不起眼的角落，被一堆看起来很正常的日志掩盖着。这篇文章记录从现象到根因的整个排查过程，最后定位到一条113 字节长的路径上。
我日常的开发环境是 VSCode Remote SSH 连到一台 Linux 开发机，然后在 VSCode 的集成终端里开 tmux。Claude Code 在 VSCode 终端里直接运行时，能正常连接 IDE——可以读到我选中的代码、跳转文件。但一旦进入 tmux，状态栏就显示「Visual Studio Code disconnected」。
这篇文章记录了从现象到根因的完整排查过程。涉及 Claude Code 的 IDE 发现机制源码、tmux 环境变量继承的坑，以及最终的修复方案。
一台 4 核 15G 的多用户开发机，某天下午突然卡死了。不是那种「卡一下就好了」的卡，而是整台机器几乎失去响应、持续了将近四个小时的那种卡。SSH 能连上但每个命令都要等很久才有回应，top 刷不动，日志也写不进去。
事后我用 atop（这台机器上每 30 秒打一次点）做了完整的事后分析，从系统级指标一路追到具体进程，最终定位到一条看起来人畜无害的构建命令。然后用 Linux cgroup 给机器加上了系统级的内存防护。
最近注意到一个叫 mattpocock/skills 的仓库登上了 GitHub Trending 榜首——一天新增五千多 Star，总数突破三万。作者 Matt Pocock 是个 TypeScript 教育者，过去一年半一直在教人怎么用 AI 智能体做开发。他最近有两场演讲被放出来，讲的是他这一年半观察下来总结出的一套 AI 编程方法论。我看完之后觉得挺有意思，所以写这篇来梳理一下他的思路——不只是仓库里那些 skill 文件本身，而是它们背后的诊断逻辑和设计哲学。