用=delete封禁隐式转换需手动删除所有单参数构造函数和类型转换操作符，包括模板特化及委托调用路径，并配合SFINAE或C++20约束，而非仅依赖explicit。
delete如何封禁隐式转换构造函数
只要类定义了接受单个参数的非explicit构造函数，编译器就可能用它做隐式转换——比如把int转成你的类对象。想彻底禁用这类行为，最直接的办法是把所有可能触发隐式转换的构造函数声明为= delete。
注意：不是“禁止隐式转换”，而是“让能引发隐式转换的构造函数不可用”。编译器不会为你自动推导哪些构造函数该删，得你手动列出来。
- 常见误判：以为只删
MyClass(int)就够了，但MyClass(double)、MyClass(const char*)、MyClass(std::string)同样危险，都得显式= delete - 模板构造函数更麻烦：如果写了
template<typename t> MyClass(T)</typename>，它可能匹配任意类型，必须用SFINAE或requires（C++20）约束，否则光靠= delete删不干净 - 别忘了委托构造函数：如果
MyClass(int)调用了MyClass(long)，而后者没被删，那删前者也没用
如何用delete封禁隐式类型转换操作符
类里定义了operator int()、operator bool()这类转换函数，也会导致隐式转换——比如用在if (obj) { ... }或int x = obj;中。要禁用，直接在声明后加= delete即可。
关键点在于：这些操作符默认是public且可被调用的，= delete不是限制访问权限，而是让调用在编译期失败。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
operator bool()尤其危险：它会让对象在条件语句中“自然”参与布尔上下文，删掉后必须显式写if (obj.is_valid())之类 - 不要只删
operator int()却留着operator double()，用户仍可通过double间接转成其他整型 - 如果类有多个转换操作符，全部检查一遍；遗漏任何一个，隐式转换路径就还存在
模板类中防止隐式转换的特殊处理
模板类的隐式转换风险更高，因为实例化时可能生成大量未预期的构造函数和转换操作符。单纯对主模板= delete不行，得针对具体实例化类型下手。
典型做法是结合std::enable_if或C++20的requires，让不希望支持的转换路径在SFINAE阶段就失效，而不是等到底层构造函数被调用时才= delete。
- 错误示范：
template<typename t> MyClass(T) = delete;</typename>—— 这会删掉所有T的构造，包括你本想保留的MyClass(MyClass&&) - 正确思路：用
std::is_convertible_v配合enable_if，只禁用原始类型到类的转换，不限制类内部移动/拷贝 - C++17起可用
explicit+constexpr if做编译期分支；C++20推荐用requires !std::is_arithmetic_v<t></t>等约束替代= delete
为什么delete不能替代explicit，以及容易漏掉的坑
explicit是预防隐式转换的第一道防线，= delete是兜底手段。两者定位不同：explicit允许显式转换（如MyClass(42)），= delete连显式调用都禁止。
真正容易出问题的是那些“看起来不像构造函数”的隐式转换入口：
- 用户自定义字面量运算符（
operator"" _mc）如果返回类类型，也可能被用于隐式上下文，需检查是否意外启用 - 继承关系中，基类的转换函数可能被派生类对象继承并调用，删派生类的不等于删基类的
- ADL（参数依赖查找）可能激活命名空间内定义的自由函数转换，这类不在类定义内，
= delete完全无效
最常被忽略的是：友元函数、全局operator+等重载函数若接受你的类和内置类型混合参数，可能间接触发隐式转换——这时候问题已不在类定义内部，得从调用点反查。
