C++自定义异常类在const成员函数中调用std::stringstream::str()编译报错原因

你推测的报错触发位置完全正确，针对你提出的“是否是std::ostringstream存在特殊限制，导致其str()方法无法被const成员函数访问”的疑问，核心结论如下：

报错完整触发链路 #

• what()是const修饰的成员函数，函数内部访问的类成员oss会被编译器视为const版本的std::stringstream对象
• 不存在针对ostringstream的特殊访问限制，本质上是std::stringstream::str()方法本身就没有提供const版本重载：该方法调用时需要同步刷新流的内部缓冲区，生成对应的字符串结果，这个过程会修改流的内部状态，从C++标准设计之初就将其定义为非const成员函数，仅允许非const的流对象调用
• 当const修饰的oss尝试调用非const版本的str()时，常规的成员函数匹配失败，编译器走了临时对象生成的错误路径：尝试拷贝当前const的oss，生成一个非const的临时stringstream对象，再调用这个临时对象的str()
• 所有IO流类（包括stringstream）为了避免流状态被意外复制破坏，将自身的拷贝构造函数设为私有，最终触发了你看到的C2248报错——报错里提到的“访问basic_ios私有构造、stringstream拷贝构造函数不可用”，本质是编译器匹配路径走偏的连锁报错，不是你代码里真的写了主动拷贝stringstream的逻辑。

为什么可编译的ExcepParam类没有问题 #

这个类存储的是std::string类型的成员ehs，std::string::c_str()是有正规const重载的，完全符合const成员函数的访问权限要求，因此不会触发匹配错误。

代码本身的隐藏风险 #

就算解决了const访问的编译问题，你当前写的return oss.str().c_str();本身存在未定义行为：oss.str()返回的是一个临时的std::string对象，这个临时对象在return语句执行结束后就会被析构，你返回的c_str()指针会直接变成悬垂指针，后续访问这个指针的行为完全不被C++标准保证。

可行的修复方案 #

• 如果坚持保留stringstream作为类成员，需要给oss加上mutable修饰，让const成员函数可以对它进行非const访问，同时必须修正悬垂指针问题，不能直接返回临时字符串的c_str()
• 更符合异常类设计惯例的写法，完全对齐可正常编译的ExcepParam类逻辑：在构造函数中完成字符串格式化，把最终的字符串存到类的std::string持久成员里，what()直接返回这个成员的c_str()，既不存在const访问冲突，也没有悬垂指针的风险。

内容的提问来源于stack exchange，提问作者cup