std::bad_alloc无法区分具体原因，因标准未要求其携带详细信息；需先检查分配量是否过大，再结合系统内存状态与日志分析碎片等问题。
std::bad_alloc 抛出时无法直接区分原因
标准 C++ 规范没要求 std::bad_alloc 携带具体原因，它只是笼统表示“分配失败”。无论是物理内存耗尽、虚拟地址空间用光（尤其在 32 位进程）、或单次请求远超可用内存（比如 new int[SIZE_MAX]），都抛同一个异常。你不能靠 what() 拿到“out of memory”或“allocation too large”这类提示——多数实现返回空字符串或固定文本。
先看分配量是否明显过大
这是最快排除的路径。检查抛异常前那行 new 或 std::vector::resize() 的参数值：
- 如果请求字节数 > 几百 MB（尤其在嵌入式/容器环境），大概率是逻辑错误：比如误用变量未初始化、循环计数溢出、或单位换算错（把 KB 当 B）
- 在 32 位程序中，单次分配 > ~2GB 几乎必然失败（受用户态地址空间限制），哪怕系统还有空闲内存
- 用
sizeof(T) * N手动算一下实际字节数，别只信N看起来“不大”
用系统工具交叉验证内存状态
运行时捕获不到上下文，得靠外部观测：
- Linux 下立即执行
free -h和cat /proc/meminfo | grep -E "MemAvailable|CommitLimit"：若MemAvailable极低（Committed_AS 接近CommitLimit，倾向真实内存不足 - Windows 用任务管理器“性能”页签看“提交大小”，或用
perfmon监控 “Process/Private Bytes” 和 “Memory/Available MBytes” - 关键点：如果同一台机器上其他进程也频繁 OOM，或
malloc在 C 风格代码里也失败，基本可锁定系统级资源枯竭
加分配日志 + 限制单次上限
预防胜于诊断。在关键分配点（如加载资源、构建大容器）前插入防御性检查：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
size_t bytes = sizeof(MyStruct) * count;
if (bytes > 100ULL * 1024 * 1024) { // 限制单次≤100MB
throw std::runtime_error("suspected huge allocation: " + std::to_string(bytes));
}
auto ptr = new(std::nothrow) char[bytes]; // 用 nothrow 避免异常，便于判断
if (!ptr) {
// 这里可以记录 bytes 值、调用栈（用 backtrace 或 __builtin_return_address）
}
这种日志在复现问题时能直接告诉你：是某个函数反复申请 2MB 最终累崩，还是某次突兀申请了 4GB。
真正难缠的是内存碎片——地址空间还有空洞，但找不到连续大块。这种情况既不是单纯“不足”，也不是“超大”，调试时容易误判。务必结合分配量日志和系统内存视图一起看。
