应使用 explicit 修饰单参数构造函数来禁止隐式转换，而非 delete；explicit 可禁用隐式转换但保留显式调用，而 delete 会彻底禁用所有调用。
用 explicit 修饰单参数构造函数，而不是直接 delete
想禁止隐式转换，第一反应不是删掉构造函数，而是加 explicit。C++ 标准规定：只有带单个参数（或其余参数都有默认值）的构造函数才可能触发隐式转换；而 explicit 能直接关掉这条路，又保留显式构造的能力。
比如：
struct Vec2 {
float x, y;
explicit Vec2(float v) : x(v), y(v) {} // ✅ 禁止 float → Vec2 隐式转换
};此时 Vec2 v = 3.14f; 编译失败，但 Vec2 v(3.14f); 或 Vec2 v{3.14f}; 仍合法。
常见错误是误以为 delete 构造函数能“精准拦截隐式转换”，其实它会把所有调用（包括显式构造）一并干掉，过度封锁。
立即学习“C++免费学习笔记（深入）”；
delete 构造函数的正确使用场景：彻底封禁某类初始化
delete 的作用是让某个函数“不可用”，适用于你**完全不希望该类型被某种方式构造出来**的情况，和隐式转换无关。
- 禁止拷贝：在 C++11 后，写
MyClass(const MyClass&) = delete;比私有化更清晰 - 禁止某类参数构造：比如不希望用户用
int或nullptr构造某个句柄类
示例：
struct Handle {
Handle(int) = delete; // ❌ 不允许 int 构造
Handle(void*) = delete; // ❌ 不允许 void* 构造
Handle(std::string) {} // ✅ 只留 string 构造
};这时 Handle h = "abc"; 合法，但 Handle h = 42; 或 Handle h = nullptr; 都编译失败——这不是防隐式转换，是防非法输入源。
隐式转换链长于一层时，explicit 仍有效
哪怕中间隔着一个用户定义转换，只要路径中任一构造函数是 explicit，整条隐式转换链就断掉。
例如：
struct A { explicit A(int) {} };
struct B { B(A) {} }; // 允许 A → B 隐式转换
B b = 42; // ❌ 编译失败：int → A 是 explicit，无法隐式触发，所以 int → A → B 整条链失效注意：如果 A 的构造函数没加 explicit，上面那行就能过。这说明 explicit 是“传染性”的阻断点，不是只挡自己那一层。
容易踩的坑：只给最末端构造函数加 explicit，却忽略上游可能存在的隐式构造，结果还是漏了转换。
需要同时禁用隐式转换 + 允许特定显式构造？组合用 explicit 和 delete
真实项目里常有这种需求：允许用户写 Vec2{1.0f, 2.0f}，但禁止 Vec2 v = 1.0f;，还顺便封掉 Vec2 v = nullptr; 这种明显错用。
做法是：
- 对意图支持的构造函数加
explicit - 对明显非法的重载用
= delete
struct Vec2 {
float x, y;
explicit Vec2(float a) : x(a), y(a) {} // ✅ 显式单参构造
Vec2(float x_, float y_) : x(x_), y(y_) {} // ✅ 非 explicit，支持花括号列表初始化
Vec2(const Vec2&) = default;
Vec2& operator=(const Vec2&) = default;
<pre class='brush:php;toolbar:false;'>Vec2(int) = delete; // ❌ 禁用 int 构造（防止误传字面量）
Vec2(std::nullptr_t) = delete; // ❌ 防 null 指针误用};
这样既守住隐式转换入口，又清理了边界错误来源。别指望一个 delete 解决所有问题——它管的是“能不能调”，explicit 管的是“能不能悄悄调”。
真正难处理的是模板构造函数或用户定义转换运算符（operator T()），它们不受 explicit 约束，得单独应对。那是另一层防御了。
