始终

某银行 APP 在越狱设备上启动后，大约五百七十毫秒便会退出。围绕这次退出，我们进行了二十几轮分析与干预。最终没有得到可用的绕过方案，不过这些实验揭示了一件更值得记录的事：检测环境、保护检测代码和阻止异常启动，是怎样共同起作用的。

天下苦 AI 味久矣。这话如今说出来，大概不会有人反对。打开任何一个信息流，都能看见同一副腔调：三段式排比、莫名其妙的加粗、把一切结论都包装成「这意味着」，结尾还要来一句「希望对你有帮助」。

「偷懒」是人类进步的源动力。我确实想写点东西，但从前写一篇要坐三四个小时，现在让模型起草，十分钟就能出一版。问题在于那一版实在不忍心发出去。它不太像人话，发出去是污染大家的 timeline，也白白增加读者的理解负担。

思来想去，决定给 AI 去去味儿。

我在做一个跨语言的算子引擎，同一套语义分别用 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 环境变量继承的坑，以及最终的修复方案。