Julia函数特化是否依赖类型注解？为何文档表述看似矛盾？

两处官方表述不存在本质矛盾，认知偏差来自没有区分普通参数和Type类参数的默认特化逻辑差异，具体规则如下：

• 对于所有非Type类型的普通值参数，无论是否添加类型注解，Julia都会在函数首次被调用时，根据传入参数的实际具体类型自动生成对应的特化编译版本。文档中提到的fib函数就属于这个范畴：

  fib(n::Integer) = n ≤ 2 ? one(n) : fib(n-1) + fib(n-2)
  

  哪怕将签名改成无注解的fib(n)，第一次调用fib(1)（传入Int类型值）时，都会编译专门适配Int参数的优化版本，后续调用fib(7)、fib(15)等同类型入参的场景会直接复用这份编译产物，不会重复编译，这部分和函数章节的描述完全一致。
• 性能建议章节提到的「不触发特化」是仅针对Type类型参数的特殊默认规则：如果函数的入参本身是类型值（比如传入Int、Float64作为参数），无论是否给参数加t::Type的注解，Julia默认都不会针对传入的具体类型生成特化版本，而是走统一的动态分发逻辑，这就是示例代码注释标注不会特化的原因：

  # 不会触发特化的版本
  function f_type(t)  # 显式写为t::Type也不会改变默认不特化的行为
      x = ones(t, 10)
      return sum(map(sin, x))
  end
  

  这个设计是为了避免类型值传参场景下的方法版本爆炸，减少无意义的编译开销。如果确实需要对这类传入类型值的场景做特化优化，只需要把具体类型通过函数的类型参数绑定即可，改写后的版本会正常触发特化：

  # 会针对传入的不同类型正常特化的版本
  function f_type(::Type{T}) where T
      x = ones(T, 10)
      return sum(map(sin, x))
  end
  

此前的认知偏差是把Type类型参数的特殊规则错套用到了所有参数场景：fib的入参是整数值，不是类型本身，完全不受这个特殊规则影响，不存在「无论加不加注解都不生成Int特化版本」的情况。
如果需要验证特化行为，可以直接用Julia自带的@code_typed宏查看不同入参下的编译产物：普通参数传入不同具体类型时会生成多份独立的类型化IR，未做特化处理的Type参数场景，传入不同类型时只会返回同一份泛化IR。

内容的提问来源于stack exchange，提问作者user19273273