正确用法是将std::enable_if_t放在模板参数列表末尾作默认类型，而非返回类型；std::is_arithmetic_v匹配整型和浮点型但不含bool和枚举，需显式扩展；C++20推荐用concept替代。
std::is_arithmetic_v 怎么用才不会炸编译
直接在函数返回类型里写 std::enable_if_t<:is_arithmetic_v>, int></:is_arithmetic_v> 是错的——编译器遇到不满足条件的类型（比如 std::string）会报硬错误：no type named 'type' in std::enable_if<false int></false>，而不是静默跳过重载。
正确做法是把 std::enable_if_t 放进模板参数列表末尾，作为默认类型：
template<typename T, typename = std::enable_if_t<std::is_arithmetic_v<T>>>
T square(T x) { return x * x; }-
std::is_arithmetic_v<T>涵盖整型（int、long long）、浮点型（float、double），但不包括bool和枚举（除非显式特化） - 如果还想支持
bool，得改成std::is_arithmetic_v<T> || std::is_same_v<T, bool> - C++17 起推荐用
std::enable_if_t替代typename std::enable_if<...>::type，更简洁
std::is_floating_point_v 和 std::is_integral_v 更精准的场景
如果你实际只想接受浮点数或只接受整数，别用 std::is_arithmetic_v ——它太宽泛。比如你写一个专用于 IEEE 浮点运算的函数，传入 int 可能触发隐式转换，反而掩盖逻辑意图。
这时应分拆约束：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
template<typename T, typename = std::enable_if_t<std::is_floating_point_v<T>>>
T round_to_nearest_half(T x) { return std::round(x * 2.0) / 2.0; }
<p>template<typename T, typename = std::enable_if_t<std::is_integral_v<T>>>
T factorial(T n) {
return n <= 1 ? 1 : n * factorial(n - 1);
}-
std::is_floating_point_v<T>只匹配float、double、long double -
std::is_integral_v<T>匹配所有有符号/无符号整型，但不包括char的别名如uint8_t（它们本质是unsigned char，仍算整型） - 注意：
char、signed char、unsigned char都满足std::is_integral_v，但做算术时容易溢出，是否允许取决于你的业务语义
C++20 Concepts 写法更直观，但要注意兼容性
如果你项目已升到 C++20，直接用 concept 替代 std::enable_if，签名即文档：
template<std::arithmetic T>
T abs_diff(T a, T b) { return a > b ? a - b : b - a; }或者自定义概念：
template<typename T>
concept Numeric = std::is_arithmetic_v<T>;
<p>template<Numeric T>
T safe_divide(T a, T b) { return b != T{} ? a / b : T{}; }-
std::arithmetic是标准库自带 concept（C++20），等价于std::is_arithmetic_v<T> - 自定义
Numeric概念时，别漏掉std::is_arithmetic_v<T>的括号，写成std::is_arithmetic_v<T>才是布尔值；写成std::is_arithmetic<T>是类型，编译不过 - Concepts 不解决运行时行为问题——比如
safe_divide(5, 0)仍可能除零，它只管类型合法
为什么 static_assert 不适合做“限制”
有人图省事在函数体内加 static_assert(std::is_arithmetic_v<T>, "T must be arithmetic")，这确实能报错，但不是“限制可实例化范围”，而是“实例化后立刻失败”。
- 它无法参与重载决议：两个模板都带
static_assert，编译器还是会尝试实例化所有候选，失败后才报错，错误栈深、定位难 - 和
std::enable_if或 Concepts 相比，它不提供 SFINAE 行为，也不支持概念组合（比如Numeric && std::copyable） - 适合用在模板内部某段逻辑有强前提时（例如某个分支必须要求
T支持位运算），而非顶层类型筛选
真正要“让非数值类型根本不出现在候选集里”，只能靠模板参数层面的约束——要么 std::enable_if_t 放默认参数，要么 C++20 的 concept。
