void* 在C++里是一个特殊的存在：任何类型的指针都能隐式转换成它，它也能转换回原来的指针类型。这种看似万能的特性让它在早期C风格代码中被大量使用，比如实现泛型容器、线程函数参数传递、回调上下文等。但随着C++标准库的不断完善，继续依赖void* 的代码正暴露出越来越多的隐患。问题的核心在于：一旦数据被塞进 void*，编译器就对它失去了所有类型信息，一切正确性完全依赖程序员自己的记忆力。
void* 到底危险在哪里
先看一个最典型的错误场景。假设某个遗留接口要求通过 void* 传递用户数据，调用方传入了一个 int*，而接收方按照 double* 去还原：
#include <iostream>
// 接收回调数据，内部假定是 double
void ProcessData(void* userdata) {
double* p = static_cast<double*>(userdata); // 强行还原
std::cout << *p << std::endl; // 未定义行为！
}
int main() {
int value = 42;
ProcessData(&value); // 传的是 int*
return 0;
}这段代码能编译通过，没有任何警告（取决于编译器），运行时却可能输出完全离谱的值，甚至直接崩溃。原因是 int 只占4字节，而代码按 double 的8字节去读取，越界访问属于未定义行为。这就是 void* 的第一个坑：类型错误在编译期完全无法被发现。
第二个坑是所有权语义的丢失。void* 只是一个“裸指针”，它不表达谁拥有这块内存、是否需要释放、用什么方式释放。调用方和被调用方必须靠口头约定（或注释）来决定内存的归属，一旦约定不一致，要么内存泄漏，要么重复释放。第三个坑是可读性极差：看到函数签名里的 void* context，你完全无法推断出该传什么进去，只能翻文档或源码。
用模板和 std::any 替代泛型场景的 void*
很多 void* 的使用动机是“我想让这个容器或函数处理任意类型”。在C++98时代，除了 void* 几乎没有别的选择，而现代C++提供了更安全的工具。如果你要在编译期就知道类型，模板是首选；如果类型要到运行期才能确定，std::any 则是直接对应 void* 的替代品。
std::any 内部保存了类型信息（通过类型擦除技术实现），还原时用 std::any_cast，如果类型不匹配会抛出 std::bad_any_cast 异常，而不是静默地产生未定义行为：
#include <any>
#include <iostream>
#include <string>
void ProcessData(std::any userdata) {
if (auto p = std::any_cast<int>(&userdata)) {
std::cout << "int: " << *p << std::endl;
} else if (auto s = std::any_cast<std::string>(&userdata)) {
std::cout << "string: " << *s << std::endl;
} else {
std::cout << "未知类型" << std::endl;
}
}
int main() {
ProcessData(42); // 输出 int: 42
ProcessData(std::string("hello")); // 输出 string: hello
ProcessData(3.14); // 输出 未知类型
return 0;
}注意这里用的是 std::any_cast 的指针重载形式，类型不匹配时返回空指针而不是抛异常，方便逐个探测类型。std::any 会正确地拷贝、析构内部对象，所有权问题也一并解决了。需要留意的是，std::any 有一定的存储和调用开销，小对象通常存放在栈上的小缓冲区，大对象会转移到堆上，但对绝大多数业务代码来说这点开销完全可接受。
如果你能用上C++17，而“任意类型”其实是“有限几个已知类型之一”，那 std::variant 比 std::any 更合适。它更像一个类型安全的union，配合 std::visit 使用可以在编译期强制你处理所有分支，漏掉任何一个类型都会编译报错，安全性又提升了一个档次。
回调和线程场景的替代方案
另一个 void* 的重灾区是C风格回调，比如 pthread 的 void* (*)(void*) 线程入口函数。现代C++对此有两个成熟的替代品：处理“任意可调用对象”用 std::function，处理泛型逻辑用模板参数。
std::function 可以包装函数指针、lambda、仿函数等各种可调用实体，并且自带类型签名约束，调用方和被调用方对参数类型一目了然：
#include <functional>
#include <iostream>
#include <thread>
#include <string>
// C++11 之后的线程入口不再需要 void*，直接传值或引用
void Worker(std::string name, int repeat) {
for (int i = 0; i < repeat; ++i) {
std::cout << name << " working: " << i << std::endl;
}
}
// 注册回调：用 std::function 明确签名，而不是 void(*)(void*)
class Button {
public:
void OnClick(std::function<void(int)> handler) {
handler(1); // 模拟触发
}
};
int main() {
std::thread t(Worker, "render", 3); // 类型安全地传递任意参数
t.join();
Button btn;
btn.OnClick([](int code) {
std::cout << "clicked, code=" << code << std::endl;
});
return 0;
}std::thread 内部通过模板和类型擦除把参数完美转发给线程函数，彻底告别了 pthread 时代先打包成结构体、再塞进 void*、最后在线程里强行还原的老套路。std::function 的代价是可能有一次堆分配和一层间接调用，如果处在性能敏感的热路径上，可以改用模板参数传递可调用对象，让编译器直接内联。
哪些场合 void* 仍然合理存在
说了这么多 void* 的坏话，也要承认它并非一无是处。与C ABI交互时（比如回调必须符合C函数签名），void* 是绕不开的桥梁，此时正确做法是在边界处做一次类型安全的封装：进入C库前把具体指针打包，从C库回来后立即用 static_cast 还原，并尽量让还原代码集中在一处。另外，如果你只是需要“不透明指针”来隐藏实现细节（pimpl惯用法的底层原理），void* 在纯内存地址意义上也是合法的，但更推荐用前置声明的不完整类型来实现同样的效果。
还有一类情况是和操作系统API、第三方C库打交道，比如窗口系统的userdata字段。面对这类接口，可以在最外层封装一个RAII类，把 void* 的传递限制在类的私有实现里，对外只暴露类型安全的接口，这样风险就被牢牢控制在极小的范围内。
总结一下选择思路：编译期已知类型用模板，运行期任意类型用 std::any，有限类型集合用 std::variant，可调用对象用 std::function 或模板。这四件套基本覆盖了 void* 的全部合理用途。C++的类型系统每年都在进化，把类型信息保留得越久，编译器能帮你拦截的错误就越多。与其在凌晨调试一个诡异的内存越界，不如让错误在编译那一秒就停下来。