本人之前开发需求都是Java/Kotlin+rust通杀GC语言和非GC语言，现在有了codex娘这匹神级坐骑后更是如入无人之境。近期接到一个安卓需求，大致链路是C++底层库调用上层链路，保险起见我把所有C++代码视为unsafe，业务逻辑放在rust层，尽量确保安全。
codex写完之后编译运行，不出所料崩溃了，毕竟接触到C++了，大概率会变得不幸。我本来以为就是rust和C++层的ffi边界问题，两边接口对不上，语言不通把应用给骂崩溃了，让codex排查它也认为是这个方向，于是开改。
改完后一跑又崩溃了，这下逐渐开始发现事情不对了，仔细看看崩溃栈：
libc++_shared.so std::__ndk1::basic_string::append(...)
<app>.so AppendString(...)
<app>.so request_policy_callback(...)
<biz>.so <callback caller>
很疑惑，就一个stringappend能出啥问题？
崩溃信息：
NOTE: Function names and BuildId information is missing for some frames due to unreadable libraries. For unwinds of apps, only shared libraries found under the lib/ directory are readable. On this device, run setenforce 0 to make the libraries readable.
biz库提供了一个这样的接口：
extern "C" int request_policy_callback(
const char* method,
const char* url,
const std::map<std::string, std::string>& header,
const unsigned char* body,
int body_size,
const std::map<std::string, std::string>& info);
如果不动header和info这俩天尊，应用就不会崩溃。
这个功能还给了其他业务的接入样例，是一比一照着写的，感觉已经不是一般的问题了，不应该局限于代码。遂把apk扔给codex，让它给我狠狠查so里面的符号，严查！
这一查啊，果然查出大鱼了：
我们编出的app.so认为std::map<std::string, std::string>是
std::__ndk1::map<std::__ndk1::string, std::__ndk1::string> ，但是biz.so里面却是std::Cr::map<std::Cr::string, std::Cr::string>。
询问库的维护方，得到质疑：
为什么其他的业务没问题，就你们有问题？
继续排查后，库维护方得知他们给其他业务提供的库编译时动态链接了ndk的stdcpp，给我们提供的版本静态链接了内部的stdcpp。
事情目前进展到此，现在我正在等动态链接stdcpp的新版本。
SB C++，标准库都没一个统一的，用rust从来没遇到过这个问题
ABI 业界的唯一标准就是 CABI，生产环境，谁敢拿 C++ 标准做 ABI？然后我这次遇到的问题和 ABI 是没有关系的。而是类似两个库之间约定使用了同一个接口，结果因为实现不同而崩溃了。