使用.into()创建Option对比直接用Some()包装存在哪些弊端？

这种是Rust场景下的合法写法，但实际开发中并不推荐，主要弊端如下：

• 编译期推导成本高
  只有上下文能明确推导出目标类型为Option<T>时，.into()调用才会生效。如果没有明确的类型约束，编译器会直接报类型歧义错误，排查难度远高于直接写Some()。比如单独写let num = 10.into();编译器根本无法判断你要生成的是Option<i32>还是其他实现了From<i32> trait的类型，必须额外加类型标注，反而比直接写Some(10)更冗余。
• 可读性大幅降低
  Some()本身就是语义非常明确的标记，其他开发者扫一眼就能知道这里生成的是Option类型的有效值。而用.into()的话，必须向上查找上下文的类型约束才能确定最终类型，在长表达式、多层函数调用的场景下会大幅提升代码理解成本。
• 重构时易引入隐式隐患
  如果后续重构修改了上下文的目标类型，只要新类型也实现了对应值的From trait，.into()调用不会触发编译报错，只会悄咪咪生成你预期之外的类型值，引入难以排查的隐式Bug。如果是直接写Some()，只要目标类型不匹配会直接触发编译错误，提前暴露问题。
• 代码风格不统一
  .into()只能用来生成Some(T)实例，没法生成None，同一段处理Option的代码里会出现两种写法，风格割裂反而降低可维护性。

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