隐式转换在单参数构造函数和类型转换运算符中自动发生，易引发逻辑错误；explicit关键字可强制显式调用，是防御性编程的必要措施。
隐式转换在构造函数里偷偷干活
C++允许类通过单参数构造函数自动转成该类型，比如 String s = "hello" 看似合理，但实际触发了 String(const char*) 构造函数的隐式调用。这种“自动升级”在函数传参、返回值、赋值时都可能悄无声息发生。
- 一旦你写了
MyClass(int x)这样的单参构造函数，编译器就认为int → MyClass是合法隐式路径 - 函数接收
MyClass参数时，传个42就能过编译，但你根本没意识到对象被新建了一次 - 返回
int却被接在MyClass变量上（MyClass m = get_id();），也可能意外触发构造
常见错误现象：std::vector<MyClass> v(10, 5) 本意是建 10 个默认对象，结果变成建 10 个由 int(5) 构造的临时对象——逻辑完全跑偏。
Conversion Operator 的隐式反向转换更难防
类定义 operator int() const 后，它就能自动“降级”成 int。表面看方便，实则埋雷：只要上下文需要 int，这个 operator 就可能被调用，连比较操作符都逃不掉。
-
if (obj == 0)可能触发obj.operator int()，而不是你预期的自定义operator== -
printf("%d", obj)会静默转成int，但若转换逻辑抛异常或有副作用，就出问题 - 更隐蔽的是模板推导：
template<typename T> void foo(T); foo(obj);中T可能被推成int，而非MyClass
使用场景越宽松（比如泛型接口、C 风格 API 交互），越容易被这种“自动降级”带偏。
立即学习“C++免费学习笔记（深入）”；
explicit 是唯一靠谱的刹车片
C++11 起，explicit 可以加在单参构造函数和 conversion operator 上，强制它们只能显式调用。这不是可选项，是防御性编程的底线。
- 构造函数加
explicit MyClass(int x)：禁止MyClass m = 42;，只允许MyClass m(42);或MyClass m = MyClass(42); - conversion operator 加
explicit operator int() const：禁止int x = obj;，只允许int x = static_cast<int>(obj);或int x = obj.operator int(); - 注意：老编译器（如 VS2013 前）不支持
explicitconversion operator，得靠命名函数替代（如to_int()）
性能影响几乎为零——explicit 不改变生成代码，只改编译期检查；兼容性上，加了它反而让意图更清晰，减少跨平台误用。
哪些地方最容易漏掉 explicit
不是所有单参构造函数都需要 explicit，但绝大多数都应该加。漏掉的地方往往就是线上 bug 的温床。
- 包装 POD 类型的类（如
SafeInt、StringView、Optional<T>）：它们天生适合隐式构造，也最常被滥用 - 模板类中依赖
T的单参构造（如Wrapper<T>(T val)）：泛型放大隐式转换风险 - conversion operator 写在类末尾、被当成“辅助功能”而忽略修饰：其实它比构造函数更危险，因为调用点更分散
一个简单判断法：如果去掉这个转换，用户还能用 static_cast 或构造函数明确写出等价逻辑，那就该加 explicit。否则，你就是在替别人做决定，而且决定错了还不好查。
