直接系统调用有啥坑？踩过的人才知道有多疼！
说实话,第一次听到"直接系统调用"这个词的时候，我内心是有点犯怵的，你想啊，平时写代码调个函数、用个库多舒服，突然要自己去跟内核打交道，这不是没事找事吗？但架不住项目需求摆在那儿，性能瓶颈卡得死死的，常规API一层层封装下来开销太大，没办法，只能硬着头皮上，结果这一路踩下来的坑啊，真是让我哭笑不得，今天就来跟大家唠唠，直接系统调用有啥坑，免得后来人重蹈覆辙。
坑一：系统调用号这玩意儿，跨平台就是噩梦
我跟你讲,最开始我以为系统调用就是个简单的"传参—触发—返回"三部曲，能有多难？结果第一个坑就把我绊倒了，x86_64 上 write 是 1，到了 ARM64 上就变成了 64，这数字对不上你知道吧？我当时写死了一个调用号，本地跑得好好的，一上测试机直接给我返回 -ENOSYS，那叫一个懵，后来才反应过来，这调用号根本不是通用的，得按架构来。直接系统调用的第一课就是：别偷懒，老老实实按平台宏去判断，不然线上崩了你都不知道为啥。
坑二：errno 不给你自动设置了，全靠自己兜
平时用 glibc 封装好的函数多省心啊，出错了人家帮你把 errno 设好，你 perror 一下就完事，可你要是直接系统调用呢？返回值是负的错误码，你得自己判断、自己转换，我有一次忘了判断返回值，负数直接当长度用了，结果内存越界，程序当场表演了一个"优雅崩溃"，哎，那种感觉，就像你自信满满地出门，结果鞋带没系，啪叽摔一跤，所以说，直接系统调用有啥坑？errno 这一块绝对排得上号，千万别指望有人帮你擦屁股。
坑三：参数对齐和寄存器约定，写错一个全盘皆输
这个坑更隐蔽,系统调用传参是靠寄存器的，x86_64 上依次是 rdi、rsi、rdx、r10、r8、r9，注意啊，第四个是 r10 不是 rcx！我当初就是照着普通函数调用的习惯写了 rcx，调了半天数据死活不对，debug 到凌晨三点，眼睛都花了，后来翻手册才发现这个细节，那一刻真是又气又笑，你说这直接系统调用，细节多如牛毛，一个寄存器写错，行为就完全跑偏，简直比女朋友的心思还难猜。
坑四：性能没提上去，反而被上下文切换拖垮
本来想着绕过库函数能快一点,结果呢？我测了一下，频繁的小数据量系统调用，性能反而不升反降，为啥？因为每次陷入内核都是一次上下文切换，开销摆在那儿，你调用越频繁，这个成本越明显，这就好比你为了省一块钱公交费，结果走了十公里路，累得半死还耽误事，所以啊，聊直接系统调用有啥坑，性能这块必须提一嘴：它不是银弹，用之前先 profiling 一下，别拍脑袋优化。
坑五：可移植性和调试难度，双重暴击
最后说说最让人头疼的——可移植性，你针对某个内核版本、某个架构调好的代码，换个环境可能就水土不服，而且出问题的时候，调试器都不太好使，栈回溯经常断在半路，你得靠 strace 一点点扒，那种感觉，就像在黑屋子里找一根针，还是根会跑的针，所以我的建议是：除非真的有必要，否则优先用成熟库；真要用直接系统调用，一定封装好、加好日志、做好平台适配。
写在最后
说了这么多,不是劝大家别碰，而是想说：直接系统调用有啥坑，坑是真不少，但搞清楚原理之后，它也没那么可怕，关键是要敬畏底层，多查手册，多测试，别想当然，希望我这些血泪教训，能帮你少走点弯路，毕竟，踩坑这事儿，别人踩过就够了，你说是不是？
相关阅读推荐：系统调用与库函数的那点事儿