嘿，这个问题问得挺到位的——刚好戳中了C++编译模型和链接时优化（LTO）的交叉点上。我来拆解一下：

首先给你一个明确的结论：在支持全程序LTO的主流编译器（GCC、Clang、MSVC）下，这种调用是可以正常完成编译期求值的，但严格来说，这确实属于编译器实现相关的行为，C++标准本身并没有明确规定LTO阶段算不算"编译时"的一部分。

1. 先理清楚C++标准对consteval的核心要求 #

C++标准要求consteval函数的所有调用必须在常量表达式上下文中完成编译期求值，否则程序直接非法。但标准里的"编译时"是个抽象概念，并没有绑定到传统的"单个翻译单元编译"阶段——它只要求最终程序在运行前完成求值，至于是在单个TU编译时、链接时，还是其他优化阶段完成，标准并没有做死限制。

2. LTO是怎么让这事儿成为可能的？ #

传统编译流程里，静态库的.a文件只是一堆编译好的目标文件（.o）的归档，每个.o都是独立翻译单元编译的产物，此时consteval函数的定义只在库的.o里，调用它的可执行程序TU在编译时拿不到函数体，肯定没法完成编译期求值，直接就报错了。

但开启LTO后，编译器会把每个TU的中间表示（IR，比如GCC的GIMPLE、Clang的LLVM IR）保留下来，等到链接阶段再把所有TU的IR合并成一个"全程序IR"，然后在这个阶段做跨TU的优化和求值。这时候，可执行程序里的constexpr result = square(5);就能看到静态库中square函数的完整定义，自然就能完成编译期求值了。

3. 主流编译器的支持情况 #

• GCC：从GCC 10左右开始，对LTO下的跨TUconsteval求值支持就很稳定了，只要你加了-flto（全程序LTO）参数，就能正常处理这种场景。
• Clang：Clang对LLVM IR的跨TU优化支持更早，只要开启-flto，基本都能正确处理consteval的跨TU求值。
• MSVC：从VS2022的某个版本开始，开启/LTCG（链接时代码生成，也就是MSVC的LTO）后，也支持这种场景，但要注意必须用较新的工具链版本。

4. 实际测试的注意事项 #

• 编译静态库的时候，必须也开启LTO相关参数！比如用GCC编译库的命令：

  g++ -c -flto -O2 util.cpp -o util.o && ar rcs libutil.a util.o
  

  编译可执行程序的命令：

  g++ -flto -O2 main.cpp -L. -lutil -o hello
  

  这样编译出来的程序，result是编译期就计算好的25，运行时直接打印结果。
• 如果没开LTO，编译可执行程序的时候会直接报错，说consteval函数square的定义不可见，没法在编译期求值。

最后补充一句：虽然主流编译器都支持，但这毕竟是标准未明确规定的实现行为。如果你的代码需要跨编译器兼容，最好还是尽量把consteval函数的定义放在头文件里（让调用TU在编译时就能拿到函数体），这样更稳妥。但如果是项目架构限制必须把consteval函数放在静态库，那只要确保全流程开启LTO，用主流编译器是完全没问题的。