C++的auto关键字在使用过程中存在哪些风险？

虽然auto的编译期类型推导逻辑本身是确定的，编译器不会在推导规则上出错，但实际开发中不合理使用auto仍然会带来不少可维护性、逻辑正确性层面的问题：

• 非预期的类型推导结果
  很多时候你对表达式返回类型的预判和实际推导结果可能存在偏差，典型场景包括：

  调用std::vector<bool>::operator[]时，返回值实际是代理类std::_Bit_reference而非bool&，如果用auto接收返回值，你以为拿到的是元素引用可以修改原容器值，实际得到的是临时对象拷贝，修改操作不会生效。
  另外如果表达式返回的是const T&类型，直接用auto声明变量会默认丢弃const和引用修饰符，触发不必要的大对象拷贝，或是出现修改常量的编译错误。如果你需要保留引用需要显式写auto&或是const auto&，但很多开发者很容易漏写修饰符。

• 代码可读性下降
  对于业务逻辑相关的变量，显式声明类型可以直接给后续维护代码的人传递明确的语义信息，比如你看到uint64_t user_id = get_user_id()，不用看get_user_id的声明就知道变量是64位无符号的用户ID；但如果写成auto user_id = get_user_id()，你根本没法第一时间判断ID的位数、是否有符号，尤其在没有IDE跳转提示的场景下读代码，需要反复翻函数声明才能理清变量类型，大幅提升维护成本。
• 依赖接口变更时缺少预警
  如果你依赖的第三方库或是项目其他模块的接口返回类型发生了变更，显式声明变量类型的场景下编译器会直接报类型不匹配的错误，你可以第一时间评估接口变更对当前逻辑的影响；但用auto的话代码会直接编译通过，你完全感知不到接口的变化，很可能引入溢出、逻辑判断错误等隐性问题，直到线上出问题才会发现。
• 初始化语法的歧义问题
  不同C标准对auto的花括号初始化推导规则有差异：auto x{1}在C11中会被推导为std::initializer_list<int>，在C++17及之后的标准中才被修正为推导为int。如果你的代码需要跨多个标准版本编译，很容易因为这个规则差异出现意料之外的编译错误或是逻辑问题。

当然auto并不是完全不能用，在迭代器声明、lambda表达式接收等类型写起来冗长、或是本身没有固定写法的场景下用auto可以大幅提升代码简洁度，只要避开上述不合理的使用场景即可。

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