explicit能阻止单参数构造函数引发的隐式转换，如String s = "hello"、func("world")、容器初始化、比较操作等场景中的自动类型转换，避免布尔陷阱等运行时错误。
explicit能阻止哪些隐式转换
在C++中，explicit只作用于单参数构造函数（或多个参数但其余都有默认值的构造函数），防止编译器悄悄执行「类型自动转换」。比如：String s = "hello" 或 func("world") 传入一个期望String的函数时，若构造函数没加explicit，编译器会自动生成临时String对象——这常是意外行为的源头。
常见误触发场景包括：
- 函数重载歧义：两个重载函数分别接受
int和MyClass，传入5可能意外调用MyClass(int)构造再转过去 - 容器初始化：如
std::vector<String> v(10, "abc")，若String(const char*)不explicit，会先构造10个String再拷贝，而非预期的“重复10次字符串” - 比较操作：写
if (s == "test")，若String有explicit String(const char*)，则必须显式写if (s == String("test"))，避免隐式构造干扰operator==语义
什么时候必须加explicit
只要构造函数的语义不是「等价于类型转换」，就该加explicit。典型信号：
- 参数是原始类型（
int、const char*、double等），且类不是该类型的「别名式封装」（比如class SafeInt { explicit SafeInt(int x); }） - 构造函数涉及资源申请、验证逻辑或非平凡开销（如解析字符串、检查范围），你不希望它在赋值、参数传递中被悄悄调用
- 类设计为「值语义但需明确意图」，例如
Duration类接受int seconds，写Duration d = 5;容易让人误以为单位是毫秒或帧数
反例：像std::string的string(const char*)在C++11前不是explicit，导致大量隐式转换问题；C++11后仍保持兼容未改，但新类型（如std::optional、std::variant）的构造函数基本都加了explicit。
立即学习“C++免费学习笔记（深入）”；
explicit对移动构造函数和转换运算符的影响
explicit也能用于转换运算符（C++11起），控制是否允许隐式类型转换出本类对象：
class String {
public:
explicit operator const char*() const { return data_; } // 必须写 static_cast<const char*>(s) 才能用
};但它**不能**用于移动构造函数或移动赋值运算符——这些函数本身不参与隐式转换链，explicit加了也无效（编译器会忽略或报错）。真正要防的是「从其他类型构造本类」，不是「本类内部怎么搬数据」。
另外注意：C++20起支持explicit(true)/explicit(false)条件化修饰，但实际项目中极少需要，多数情况直接用explicit就够了。
不加explicit的真实翻车案例
最经典的是「布尔陷阱」：
class File {
public:
File(const char* path); // 没explicit！
File(int fd); // 也没explicit！
};然后有人写了File f = nullptr;或File f = 0;，结果调用了File(int)，把文件描述符0（stdin）当文件打开了——程序后续读写完全错乱。
另一个常见坑是容器算法误用：
void process(const std::vector<String>& v);
process({1, 2, 3}); // 若String(int)不explicit，这里会构造三个String对象，而非编译错误提醒你写错了这类错误往往运行时才暴露，调试成本远高于加一个explicit关键字。
真正麻烦的不是语法记不住，而是团队里有人觉得「加explicit太啰嗦」「用户用起来不方便」，结果在关键路径上埋下静默转换的雷——尤其当类作为SDK接口对外提供时，隐式转换一旦放开，就再也收不回来了。
