编译器在语义分析阶段基于C++标准硬编码的转换规则进行静态类型检查，不依赖运行时或模板元编程；类型检查发生在模板实例化后、代码生成前，依据标准转换序列判定合法性。
编译器如何在 C++ 中执行类型检查
Clang 和 GCC 等主流编译器在语义分析阶段（Semantic Analysis）对表达式做类型检查，不是靠运行时、也不是靠模板元编程“模拟”，而是直接走 AST 节点的 QualType（Clang）或 tree_node 类型系统（GCC）。你写的 int a = 3.14;，编译器会立刻在 AST 中标记该赋值节点存在 double → int 的截断转换，并触发 -Wfloat-conversion 警告（若开启 -Wconversion）。
关键点在于：类型检查发生在模板实例化之后、代码生成之前；它不依赖 std::is_convertible 这类运行时/编译期反射工具——那些只是对已有规则的查询接口，不是规则本身。
- 类型检查基于 C++ 标准第 7-8 章定义的“标准转换序列”（standard conversion sequence），包括左值转换、提升、算术转换、指针转换等
- 用户自定义转换（如单参数构造函数、
operator T()）只在重载决议（overload resolution）中参与候选，且受explicit限制 - 模板推导（如
auto或函数模板）不触发隐式转换：它先推导出最精确类型，再单独检查是否可转换
隐式转换规则怎么被编译器“推导”出来
编译器不“推导”隐式转换规则，它硬编码了整套转换图谱。比如 char → int 是标准提升（promotion），int → double 是标准浮点转换，而 std::string → const char* 不存在（除非有用户定义的 operator const char*() 且未声明为 explicit）。
真正动态发生的是“重载决议中的可行函数筛选”：当调用 func(42)，而 func 有多个重载（void func(int)、void func(double)、void func(std::string)），编译器会为每个候选构建一个“转换序列”，并按标准规定的严格序（exact match → promotion → standard conversion → user-defined conversion）打分。
立即学习“C++免费学习笔记（深入）”；
-
func(42)对func(int)是 exact match；对func(double)是 standard conversion（int→double）；对func(std::string)若有std::string(int)构造函数，则是 user-defined conversion —— 后者得分最低，且若该构造函数是explicit，直接剔除 - 禁止二义性：若两个候选都只需 standard conversion（如
func(long)和func(float)），编译器报错error: call to 'func' is ambiguous - 注意
std::initializer_list重载的特殊优先级：它在用户自定义转换之后、但某些标准转换之前介入，容易引发意外匹配
怎么观察编译器实际使用的转换路径
用 Clang 的 -Xclang -ast-dump 或 GCC 的 -fdump-tree-original 可看到 AST 或 GIMPLE 中标注的类型和转换节点，但更实用的是让编译器“说出来”：
- 加
-fverbose-asm（GCC）或-emit-llvm（Clang）后看 IR，bitcast、sitofp、fptosi等指令就是隐式转换落地的痕迹 - 用
-S -O0生成汇编，查找cvtsi2sd（int→double）、cvtdq2ps（SSE 整数转浮点）等指令 - 启用
-Wconversion+-Wsign-conversion，编译器会在可疑位置直接提示，例如：warning: implicit conversion changes signedness: 'int' to 'unsigned int' - 对模板场景，用
static_assert(std::is_convertible_v<t u>)</t>验证你的理解是否匹配编译器当前上下文的转换能力——但注意它只反映标准转换+用户定义转换，不包含上下文限定（如重载决议中的优先级）
常见误判与隐蔽陷阱
很多人以为 auto x = 1 + 2.0; 的类型是靠“推导隐式转换”得来的，其实不是：1 被提升为 double 是算术转换规则强制要求的，auto 只是记下最终结果类型 double。真正的坑藏在边界处：
- 字面量后缀影响极大：
1是int，1U是unsigned int，1LL是long long；混合运算时，int + unsigned int在 32 位平台可能整体提升为unsigned int，导致负数变大正数 -
std::vector<bool></bool>是特化，其operator[]返回代理对象而非bool&，所以auto&& x = v[0];绑定的是临时代理，而非原生布尔引用——这不是类型转换问题，但常被误认为“类型推导失败” - 函数指针到
std::function的转换是用户定义转换，且std::function构造函数是非explicit的，因此能隐式发生；但反过来（std::function到函数指针）不行，也没有隐式转换 - 聚合初始化（如
struct S { int a; double b; }; S s = {1, 2.0};）不触发任何用户定义转换，仅允许标准转换；若写成S s{1, "hello"}，则直接编译失败，不会尝试const char*到double的转换
最易被忽略的是：所有这些规则都作用于表达式求值前的静态语义阶段，和运行时零关系；一旦过不了这关，连目标文件都生成不了——所谓“调试隐式转换”，本质是读编译器报错信息 + 查标准条款 + 检查字面量类型，而不是跑程序看结果。
