为何std::function_ref的F*构造函数非constexpr，其余构造函数却均为constexpr？

咱们得从std::function_ref各个构造函数的设计意图和C++constexpr的规则说起，拆解下来核心原因有这么几点：

• 先看那些带constexpr的构造函数：
  比如绑定到非类型模板参数的版本（template<auto f> constexpr function_ref(...)），这里的auto f本身就是编译期常量——要么是全局函数的地址、静态成员函数的地址，要么是编译期就能确定身份的可调用实体，完全符合constexpr对“编译期可求值”的要求，自然可以加上constexpr修饰。
  而function_ref(F&&)这类构造函数，它针对的是可调用对象的引用（左值或右值），如果是在constexpr上下文里调用，传入的对象必须是编译期可访问的（比如全局对象、静态对象，或者C++20及以后支持的编译期临时对象），这类场景下完全满足constexpr的求值规则，所以也能标constexpr。

• 再看template<class F> function_ref(F*)这个特殊的构造函数：
  它的设计初衷是能接受任意的可调用对象指针——这个指针可能指向运行时才创建的对象（比如栈上的局部仿函数实例、动态分配的可调用对象），这类指针的值在编译期根本无法确定。如果给这个构造函数加上constexpr，就会带来两个问题：

  1. 编译期上下文调用时，必须传入一个编译期常量指针（比如指向全局函数/静态对象的指针），但这和它“支持运行时动态指针”的设计初衷冲突，会让用户误以为它只能处理编译期指针；
  2. 虽然constexpr函数也能在运行时调用，但标准委员会认为给这个构造函数加constexpr没有实际意义——它的主要使用场景就是运行时的动态指针传递，编译期的指针场景完全可以用其他带constexpr的构造函数（比如非类型模板参数版本）来覆盖。

简单来说，就是这个F*构造函数的定位是“处理运行时动态的可调用指针”，而其他constexpr构造函数的定位是“处理编译期已知的可调用实体”，两者的设计目标不同，所以有没有constexpr修饰也就跟着区分开了。

内容来源于stack exchange