explicit用于禁止单参数构造函数的隐式转换，防止意外类型转换；C++11后也支持explicit转换运算符，如explicit operator bool()；但非所有单参数构造函数都应加explicit，需权衡语义与兼容性。
explicit 修饰单参数构造函数时的作用
当一个类的构造函数只接受一个参数（或多个参数但除第一个外都有默认值），编译器会默认允许用该参数类型隐式转换为类类型。这容易引发意外行为，比如函数重载歧义、临时对象悄无声息地创建。explicit 就是用来禁止这种隐式转换的——它只影响“从参数类型 → 类类型”的单步隐式转换，不影响显式构造或拷贝初始化中的直接初始化。
常见错误现象：void process(MyString s); 被调用时传入 "hello"，结果意外触发 MyString(const char*) 构造，而你本意是想报错或强制写成 process(MyString("hello"))。
- 只有单参数构造函数（含带默认值后退化为单参数的）才需要考虑加
explicit -
explicit不影响MyString s = "hello";这种拷贝初始化（C++17 起此写法仍被允许，但底层仍调用 explicit 构造函数 + 拷贝省略，语义上不视为隐式转换） - 真正禁止的是类似
process("hello")或MyString s = "world";中的隐式转换步骤
explicit 在 C++11 后支持转换运算符
C++11 允许给 operator T() 加 explicit，用于控制类对象向其他类型的隐式转换。比如 explicit operator bool() const 是标准库中防止整型提升误用的惯用法（如避免 if (obj & 1) 这类错误）。
使用场景：自定义布尔判断、安全类型转换（如防止 MyOptional 隐式取值）。
立即学习“C++免费学习笔记（深入）”；
- 没有
explicit的转换函数可能让对象在算术表达式中被悄悄转成int或double，导致难以追踪的 bug -
explicit operator bool()后，if (x)和!x仍合法，但x + 1、static_cast会编译失败(x) - 注意：C++23 引入了
explicit(false)语法来反向取消 explicit，但目前主流编译器支持有限，不建议依赖
哪些情况不该加 explicit？
不是所有单参数构造函数都适合加 explicit。加错反而破坏接口直觉性和 STL 兼容性。
典型反例：std::vector 表示“构造含 10 个默认元素的 vector”，如果它被声明为 explicit，那么 std::vector 会失效，更严重的是像 std::make_shared 这类工厂函数也会因无法隐式推导而失败。
- 当构造函数语义明确表示“资源数量”或“容器容量”（如
std::string(n, ch)、std::thread(f, args...)）时，通常不加explicit - 当类设计为“可替代基础类型”的 wrapper（如
std::optional、std::expected），其单参数构造函数一般保留非 explicit，以便和原生类型保持一致用法 - 若已有大量用户代码依赖隐式构造，后期加
explicit属于破坏性变更，需谨慎评估兼容成本
Clang/GCC 提示隐式转换风险的方法
即使没加 explicit，编译器也能帮你发现潜在问题。启用 -Wconversion（GCC/Clang）可警告窄化转换；-Wimplicit-conversion（Clang 特有）能指出构造函数引发的隐式转换；而 -Weffc++ 会提示“单参数构造函数应声明为 explicit”这类风格建议。
实际建议：
- 新写的单参数构造函数，**默认加上
explicit**，除非你能清晰说出“为什么这里必须允许隐式转换” - 用
clang++ -Wimplicit-conversion -Wno-c++98-compat快速扫描历史代码中漏掉的 case - 注意
explicit对模板推导无影响：比如template不会因为void foo(T); foo("abc"); MyString有explicit MyString(const char*)就去尝试匹配，它根本不会参与重载决议
最容易被忽略的是：explicit 只封住一条路，但如果你提供了多个隐式转换路径（比如同时有 explicit operator bool() 和非 explicit 的 operator int()），那后者仍可能被选中——安全不是加一个关键字就自动达成的。
