凌晨三点线上报警，内存飙到98%，运维翻遍日志只找到一句std bad_alloc
这条消息在群里炸锅。
写C++的人最怕的不是功能写不出来，而是跑着跑着把服务器跑挂。
真凶往往藏在不起眼的三行代码里，RAII没到位，资源就像漏水的桶，装满只是时间问题。
很多人把RAII当成面试八股，背完就忘。
真到线上，一个new忘了delete，句柄没close，线程锁没unlock，就能把整台机器拖死。
最惨的是，异常半路跳出，执行流直接飞走，后面的清理逻辑永远跑不到。
RAII的底层逻辑其实一句话：把资源绑在对象生死上。
对象生，资源拿；对象死，资源还。
编译器帮你调用析构，比任何手写finally都稳。
异常来了也照还，程序崩了也照还，这才叫兜底。
内存只是冰山一角。
文件句柄、socket、锁、GPU显存、数据库连接，统统能用RAII包。
标准库里现成的unique_ptr、shared_ptr、lock_guard，拿过来就能用。
自己写也不复杂，构造函数里open，析构函数里close，两行代码换整夜安眠。
见过最离谱的坑，是把new出来的裸指针塞进全局容器，析构里忘erase，结果进程退出才释放，内存一路涨到OOM。
改法很简单，把裸指针换成shared_ptr，容器清掉，资源瞬间归零。
上线后内存曲线从锯齿变直线，运维再没半夜打电话。
有人担心智能指针性能差。
实测下来，unique_ptr和裸指针几乎没区别，shared_ptr多一次原子操作，在IO或业务逻辑面前可以忽略。
真到纳秒级场景，再考虑定制deleter或对象池。
99%的项目还没到拼指针性能的程度，先把资源泄漏堵死再说。
写RAII类时，记住三条军规：一，构造函数里只做资源获取，失败就抛异常，别留半成品对象；二，析构函数里只做资源释放，别加业务逻辑，防止抛新异常；三，拷贝语义想清楚，能禁就禁，必须共享就用shared_ptr，别让两个对象抢同一资源。
很多老项目改不动，是因为到处裸指针。
最省事的办法，先给每个裸指针包一层unique_ptr，编译器会立刻告诉你哪里拷贝了哪里释放了，顺着报错改，一周就能清完。
新代码直接上智能指针，旧代码逐步替换，风险可控。
RAII不是银弹，却是最便宜的保险。
写完类，资源跟着对象走，少写一次delete，少一次线上惊魂。
今晚就把代码扫一遍，看到new、open、lock没配对的，立刻包起来。
明天上线，内存曲线如果还是平的，记得回来点个赞。