explicit修饰的单参数构造函数禁止隐式转换，仅允许显式调用；适用于资源封装类等场景，避免意外绕过RaiI；c++11起也支持explicit转换运算符和多参构造函数（无实际效果）。
explicit 修饰的构造函数不能用于隐式转换
当一个类的构造函数只接受一个参数（或多个参数但除第一个外都有默认值），编译器默认允许它参与隐式类型转换。加上 explicit 后，这种自动转换就被禁止了，只能显式调用构造函数。
常见错误现象：MyClass obj = 42; 编译失败，或 func(MyClass(42)) 可行但 func(42) 报错（如果 func 参数是 MyClass）。
- 仅对单参数构造函数（含默认参数后等效为单参）有意义；多参且无默认值的构造函数本来就不参与隐式转换，加
explicit无效（C++11 起允许，但无实际效果） - 移动构造函数和拷贝构造函数也可以加
explicit，但极少使用——除非你明确不希望T t = std::move(other);这类写法 - 从 C++11 开始，
explicit也支持转换运算符，例如explicit operator bool() const;，防止if (obj) { ... }被误用于算术上下文
什么时候必须加 explicit？
只要这个单参构造函数的语义不是“类型等价转换”，就该加 explicit。典型场景是资源封装类、智能指针、范围类（如 Range）、状态类（如 ErrorCode）。
例如：std::unique_ptr 的构造函数是 explicit unique_ptr(pointer p) noexcept;，防止 func(unique_ptr 被意外简写成 func(new int); —— 后者会直接传裸指针，完全绕过 RAII。
立即学习“C++免费学习笔记（深入）”；
- 如果你的类构造函数接收原始句柄、指针、整数 ID、字符串字面量等，并用于初始化内部资源，几乎总是要加
explicit - 如果构造函数语义上就是“类型 A 可以自然看作类型 B”，比如
StringView(const char*)，是否加explicit需权衡：不加方便 API 使用，但可能引发歧义（比如重载决议选错函数） - google C++ Style Guide 和 LLVM Coding Standards 都要求：所有单参数构造函数必须声明为
explicit，除非有明确文档说明为何需要隐式转换
explicit 对重载解析的影响
隐式转换序列在重载解析中属于“用户定义转换”，优先级低于标准转换（如 int → long）和精确匹配。一旦构造函数被标记为 explicit，它就不再参与隐式转换序列，从而可能改变重载选择结果。
示例：若存在 void f(MyClass) 和 void f(int)，传入 42 时，即使 MyClass 有 explicit MyClass(int)，也会调用 f(int)；但如果构造函数不是 explicit，则可能因隐式转换导致调用 f(MyClass)，甚至引发二义性错误。
- 这在模板代码中尤其危险：SFINAE 或 concept 约束可能依赖某个类型能否隐式转为目标类，而
explicit会让这种转换失效 - 调试时若发现重载调用不符合预期，检查相关构造函数是否被
explicit意外屏蔽，是个常见排查点 - C++20 中
explicit(true)/explicit(false)语法可用于条件化控制，但实际项目中极少需要
容易忽略的兼容性细节
explicit 不影响显式构造调用，也不影响复制初始化语法中的显式转型（如 MyClass obj(42); 或 MyClass obj{42};），但它会影响 = 形式的复制初始化——前提是右侧表达式不是同类型或派生类。
例如：MyClass obj = 42; 在非 explicit 时合法，在 explicit 时非法；但 MyClass obj = MyClass(42); 始终合法。
- 聚合类型（aggregate）不能有
explicit构造函数，否则失去聚合性质，影响{...}初始化行为 - 继承体系中，基类的
explicit构造函数不会被派生类继承（C++11 起支持using Base::Base;继承，但继承来的构造函数仍保留原explicit属性） - 静态断言
std::is_convertible_v在构造函数为explicit时返回false，这是检测隐式转换能力的标准方式
真正麻烦的不是加不加 explicit，而是加完之后，原有隐式转换调用点全部报错——这些地方往往散落在测试用例、胶水代码或旧接口适配层里，不容易一次找全。