编译期布尔运算不能直接用bool，因模板参数需常量表达式，而普通bool变量非字面量或constexpr；C++20前仅支持整型非类型模板参数，故须用std::integral_constant等类型包装，标准库提供std::conjunction等带短路优化的工具。
编译期布尔运算为什么不能直接用 bool？
因为模板参数必须是常量表达式，而普通 bool 变量（如 auto b = true;）不是字面量或 constexpr，无法作为非类型模板参数传入。真正能进模板参数列表的，只有整型字面量、枚举值、constexpr 变量等——所以实际用的是 std::integral_constant 或其简写 std::true_type/std::false_type，底层本质是 integral_constant<bool true></bool> 这样的类型。
如何用模板别名实现 and、or、not？
标准库其实已经提供了 std::conjunction、std::disjunction、std::negation（C++17 起），但理解它们怎么写，比直接调用更重要。核心思路是：用特化匹配真/假组合，返回对应类型的 value 成员。
例如手写 my_and：
template<bool... Bs>
struct my_and : std::false_type {};
template<>
struct my_and<> : std::true_type {};
template<bool B1, bool... Bs>
struct my_and<B1, Bs...> : std::integral_constant<bool, B1 && my_and<Bs...>::value> {};
使用时：my_and<true, false, true>::value → false；my_and<>::value → true（空包约定为真，符合逻辑与定义）。
立即学习“C++免费学习笔记（深入）”；
-
my_or同理，空包应为false，需单独偏特化 -
my_not<T>就是std::integral_constant<bool, !T::value>，不依赖参数包 - 注意：C++20 之前不支持
bool非类型模板参数（仅支持整型），所以必须用std::integral_constant类型做“包装”
为什么推荐直接用 std::conjunction 而不是自己写？
它不只是语义清晰，还做了关键优化：短路。比如 std::conjunction<A, B, C>::value 在 A::value == false 时，根本不会实例化 B 和 C——这对依赖 SFINAE 或可能触发硬错误的类型 trait 来说至关重要。
自己写的递归模板（如上面的 my_and）会无条件展开所有参数，一旦某个 Bs... 展开失败（比如含非法类型），整个编译就崩了。
-
std::conjunction<std::is_integral<int>, std::is_same<void, void>, std::enable_if_t<false>>::value是合法的（前两项真，第三项被短路跳过） - 同逻辑的手写模板大概率报错：试图实例化
std::enable_if_t<false> - 即使不涉及 SFINAE，短路也能减少模板实例化数量，加快编译
实战中容易忽略的类型 vs 值混淆
常见错误是把值当类型传，比如写 my_and<true>::value —— 这在 C++17+ 是合法的（允许 bool NTTP），但老标准不行；更稳妥且通用的做法，始终传类型：
using result = std::conjunction<
std::is_integral<int>,
std::is_floating_point<float>
>;
static_assert(result::value, "both are arithmetic types");
-
std::is_integral<int>是类型，不是值；它的::value才是bool - 混用会导致模板参数推导失败或匹配不到特化
- 所有标准 trait 返回的都是类型（继承自
integral_constant），不是裸bool
编译期布尔运算真正的复杂点不在语法，而在你是否清楚每个操作数是类型还是值，以及短路行为对模板实例化边界的隐含影响。
