C++ 容器判空，真的只要一行代码就够了吗？

写 C++ 的时候，每天少不了跟容器打交道。vector、map、set... 每次进函数第一件事，是不是下意识看一眼 if (v.empty())？这动作太熟练了，熟到有时候连代码怎么写的都不记得。但真到了出 Bug 那天，往往就是这点“理所当然”害的。

很多人习惯写成 if (v.size() == 0)，从编译器优化角度看，现代编译器对这两者的处理基本没有差距。但在语义上，empty() 更像是在说“我看看这里有没有东西”，而 size() == 0 像是在“统计数量后比较”。就像买咖啡问“有空的杯子吗”和“杯子数量是不是零”，前者更符合直觉。特别是在自定义容器或者某些底层封装里，size() 的实现可能涉及复杂计算，这时候显式调用 empty() 既是契约也是保障。

还有一种容易被忽略的场景，就是 const 上下文。很多初学者在遍历过程中想顺便判断大小，结果写了个成员函数却忘了加 const 修饰，导致编译报错。这时候用 !container.empty() 配合 const 引用就能顺滑过去，毕竟它只是只读状态查询，不会意外修改对象内部数据。

真正让人头大的不是语法，而是并发下的判断。假设你在多线程环境写了一个队列消费器，主线程检查 if (!queue.empty()) 之后，还没来得及 pop，另一个线程已经把数据塞进去或者删光了。这种情况下，简单的判空根本没意义，因为操作不是原子的。这时候需要的不是改写法，而是加互斥锁，或者是无锁数据结构里的原子变量标记。别指望 empty() 能给你魔法般的线程安全，该加保护的地方，一个都不能少。

还有个细节，关于迭代器和容器的混合使用。有些老代码喜欢用 if (v.begin() != v.end()) 来判断，这在模板编程或通用算法里很常见，尤其是当容器本身不支持 empty() 接口时。不过对于标准库组件，直接用成员函数效率更高且可读性更强。如果为了追求极致性能去微操这个判断，大概率是浪费精力，CPU 猜错分支的概率比编译器优化掉这个函数调用的概率大得多。

归根结底，判空这事儿，本质是防御性编程的体现。代码写完别急着提交，问问自己：如果这里是空的，我的 next 操作会崩吗？如果是 vector，访问下标会不会越界？如果是 string，拷贝会不会截断？把这些隐患前置处理，比事后调试强太多。

说到这儿，下次敲键盘前多想一秒。工具是为意图服务的，什么时候用 empty()，什么时候必须结合其他逻辑，取决于业务场景。别把 API 文档背下来当成教条，盯着你的实际数据流走，比什么技巧都管用。代码稳一分，上线就少一次半夜被叫醒的机会。