让编译器替你守住安全边界——现代 C++ 的编码心法
我最初接触 C++ 的时候，对它的印象是「能写，但随时可能爆」。内存泄漏、悬空指针、线程数据竞争——这些 bug 最难调，因为它们往往在远离根因的地方才会显现。
后来读了 C++ Core Guidelines，才意识到现代 C++ 的设计目标不是「让程序员更聪明」，而是「让编译器帮程序员挡住大多数错误」。这个思路本身就值得反复咀嚼——它与语言无关，是一种通用的工程哲学。
类型是最便宜的文档，也是最便宜的校验
Guidelines 里有条规则叫 P.3：「表达意图」。最直接的例子是函数签名：
// 意图模糊：temp 是什么单位？谁来释放这块内存？
double boil(double* temp);
// 意图清晰：单位内聚在类型里，const& 表明不转移所有权
Temperature boil(const Temperature& water);Temperature 这个类型只是包了一个 double，但它把「单位语义」从注释里搬进了类型系统。这意味着误用会在编译期报错，而不是在运行时产生一个诡异的数值。
这个思路我在别的语言里也用：TypeScript 里用 branded type 区分「用户 ID」和「订单 ID」，Python 里用 NewType 区分不同含义的字符串。类型是最便宜的校验，写一次，编译器帮你永久守住。
默认不可变，变是例外
Con.1 说：「默认让对象不可变」。听起来像废话，但真正执行起来需要主动抵抗惰性——声明一个变量时，第一反应往往是 int x，而不是 const int x。
Guidelines 给出的系统做法是：
- 所有局部变量优先加
const - 成员函数优先加
const（不改成员状态就声明 const） - 传参优先
const&，除非明确需要修改或转移
这不只是风格偏好。可变状态是多线程 bug 的土壤，也是函数「偷偷干了额外事情」的温床。当你把不可变设为默认值，代码里每一处「可变」都变得显眼，就像在白纸上写字，错误更容易被发现。
写代码时不妨倒着想：「这个变量需要变吗？」而不是「我要不要加 const？」前者让你主动争论可变的必要性，后者让你被动补救。
RAII：把资源生命周期绑在对象生命周期上
C++ 最精妙的一个模式叫 RAII（Resource Acquisition Is Initialization）：资源在构造时获取，在析构时释放。文件句柄、锁、网络连接——只要包进一个对象，就不需要手动 close/unlock/disconnect，对象离开作用域时自动完成清理。
class FileHandle {
public:
explicit FileHandle(const std::string& path)
: handle_(std::fopen(path.c_str(), "r")) {
if (!handle_) throw std::runtime_error("Failed to open: " + path);
}
~FileHandle() { if (handle_) std::fclose(handle_); }
// 禁止拷贝，允许移动……
private:
std::FILE* handle_;
};这个思路在其他语言里对应的是：Python 的 with 语句、Go 的 defer、Rust 的 Drop trait。形式不同，但本质一样——不要依赖程序员在每条退出路径上都记得释放资源，把责任交给语言机制。
规则越细，反模式越有价值
Guidelines 的每条规则后面都跟着「Anti-Patterns」。我反复阅读之后发现，反模式列表比正面规则更有启发性。比如：
- 锁：
std::lock_guard<std::mutex>(m);看起来像在加锁，实际上是创建了一个立即销毁的临时对象，根本没有锁住任何东西——这是一个因为「忘记命名」导致的隐形 bug - 并发：在持有锁的情况下调用外部回调，极易死锁——但这种写法在视觉上毫无异样
- 异常继承：
catch(Exception e)而不是catch(Exception& e)会导致对象切片，丢失派生类信息
这些反模式的共同特征是：语法完全合法，语义却完全错误。正因为编译器不报错，才更危险。整理一份团队项目的「反模式清单」，比写一份「最佳实践文档」更实用——人更容易记住「不要做什么」。
一句话心法
让类型系统表达意图，让对象生命周期管理资源，让可变成为例外而非默认——这三件事做到位，大多数低级 bug 在编译期就已经被消灭。