原始类型不参与类型推断是设计选择而非能力不足，因其无泛型参数、不携带可反向求解的结构信息，导致精度丢失、装箱开销和强制显式标注等降级损耗。
原始类型在现代编译器中不参与类型推断，不是因为能力不足，而是设计上被主动排除——它根本不在推断的候选范围内。这种“不推断”，直接导致编译器退回到更宽泛、更低效或不安全的默认处理路径，即所谓“降级损耗”。
原始类型天生不可推断
类型推断机制（如 C# 的 var、C++ 的 auto、Go 的 :=）作用对象是**表达式结果类型**，而原始类型（int、double、bool 等）本身是具体、确定、无泛型参数的底层类型。它们不携带可被“反向求解”的结构信息：
-
没有类型参数：不像
List<t></t>或Option<u></u>，原始类型无法通过上下文反推T或U -
不参与泛型约束传播：当函数签名含
<t : clone></t>，传入42并不能让编译器确认T = int并自动满足Clone；它只把42当作字面量，不触发约束求解 -
字面量有隐式类型，但不参与推导链：C++ 中
0是int，0.0是double，但这个类型是字面量自带的“静态标签”，不是由其他变量或返回值“推”出来的
降级损耗的三种典型表现
当本该用原始类型高效执行的场景，因推断缺失被迫绕路，就会出现可测量的损耗：
-
精度丢失：C++
std::accumulate(v.begin(), v.end(), 0)中，0是int，即使v是vector<double></double>，整个累加也按整型进行，小数部分被截断 -
装箱/拆箱开销：Java 中
Object obj = 42;后若需模式匹配，JDK 23 虽支持obj instanceof Integer i，但前提是先完成自动装箱；若原始值直接参与泛型接口（如Function<int string></int>），目前仍不合法，必须用Integer，带来堆分配与 GC 压力 -
强制显式标注，破坏简洁性与可维护性：C# 2.0 泛型方法
PrintItem("hello")必须写成PrintItem<string>("hello")</string>，因为字符串字面量"hello"不触发T推断——这不是语法糖缺失，而是类型系统未将原始类型字面量纳入推断输入源
为什么编译器不“补上”这一环？
这不是技术限制，而是语义权衡：
-
避免歧义：
1可是int、long、short、byte，甚至无符号类型；自动选一个会引入隐式行为 - 保持类型系统分层清晰：原始类型属于“值域层”，泛型/推断属于“构造层”。混在一起会模糊编译期检查边界（如 Java 类型擦除问题就源于过度混合）
-
向后兼容优先：C++ 中
0永远是int，这是近半个世纪的契约；改变它会破坏海量遗留代码
实际应对策略
不依赖推断，转而用显式、可控的方式锚定原始类型：
- 累加时写
0.0而非0，用static_cast<double>(0)</double>明确意图 - 泛型调用时，宁可多敲几个字符：
Process<int>(x)</int>比赌编译器猜对更可靠 - 定义工具函数辅助推断：如 Go 中
CreateSliceWithHint(0)利用参数值“带入”类型，本质是把原始类型从推断对象变成推断依据
