std::identity{}必须带花括号，因其是无默认构造函数的空结构体，仅支持聚合初始化；用于满足ranges算法对投影参数的类型与值语义硬性要求，位置错误或用lambda替代均导致编译失败。
显式传 std::identity{} 不是为了“让代码跑起来”，而是为了在需要占位、泛型统一或 concept 约束严格的场景下，满足 std::ranges 算法对投影参数的类型与值语义的硬性要求；漏掉花括号、放错参数位置、或用 lambda 替代，都会直接导致编译失败。
为什么 std::identity{} 必须带花括号？
因为 std::identity 是空结构体类型，不提供默认构造函数，只支持聚合初始化。编译器靠 {} 才能构造出一个合法的、满足 indirectly_unary_invocable concept 的可调用对象。
-
std::identity→ 类型名，不是值，传给算法时类型不匹配，SFINAE 失败 -
std::identity()→ 尝试调用不存在的默认构造函数，报 “no matching constructor” -
std::identity{}→ 正确：聚合初始化空对象，零开销，constexpr 友好
std::identity{} 在 std::ranges::sort 中的参数位置不能错
它的作用是投影（proj），不是比较器（comp）。很多人把 std::identity{} 放在第二个参数位，结果触发模板推导崩溃——因为 std::identity{} 不满足 indirect_strict_weak_order 约束。
- 正确：
std::ranges::sort(v, std::ranges::less{}, std::identity{})—— 第三个参数是 proj - 也正确（省略 comp）：
std::ranges::sort(v, std::identity{})—— 编译器靠默认参数顺序推导，std::identity{}被识别为 proj - 错误：
std::ranges::sort(v, std::identity{})意图当 comp 用 → 推导失败，报错信息常含 “no match for call to …” 或 “constraints not satisfied”
什么时候非用 std::identity{} 不可？
不是“想用就用”，而是接口契约强制要求你提供一个投影实例——尤其当你封装泛型函数、配合视图链式调用，或和成员指针投影混用时。
立即学习“C++免费学习笔记（深入）”；
- 泛型排序函数模板中设默认投影：
template<typename r typename proj="std::identity"> void sort_by(R&& r, Proj proj = {})</typename>，调用时写sort_by(v, std::identity{})才能确保Proj被正确定义为具体类型，否则 concept 检查可能绕过 - 和
&Person::age共存时需显式占位：比如先按年龄排，临时切回整体默认序，就得写std::ranges::sort(people, {}, std::identity{})，而不是删掉第三个参数——删掉后某些算法（如std::ranges::transform）根本没默认 proj，直接编译不过 -
std::ranges::transform(src, dst.begin(), std::identity{})比std::ranges::copy更适合泛型逻辑：当你的函数模板同时支持 “有变换” 和 “无变换” 场景时，统一用transform+std::identity{}，避免分支逻辑和重载爆炸
std::identity{} 为什么不能用 lambda 替代？
表面行为一致，但底层约束和优化完全不同。lambda 是闭包类型，每次定义都生成新类型，破坏 SFINAE 友好性、阻碍内联、引发模板膨胀；而 std::identity 是标准库定义的单一类型，被实现深度特化。
- concept 检查失败：
requires { std::regular_invocable<:identity int> }</:identity>成立，但requires { std::regular_invocable<decltype x int> }</decltype>很可能不成立，除非你手写完整 constexpr lambda 并满足所有签名约束 - 头文件污染风险：在头文件中用 lambda 默认参数，会导致每个 TU 都实例化一份新类型，符号体积增大，链接变慢
- 返回值语义不同：
std::identity{}对左值返回T&，对右值返回T&&，完美转发；lambda 若未声明constexpr或未用auto&&捕获，容易意外拷贝或绑定到临时量
最易忽略的一点：它不是“语法糖”，而是 ranges 投影机制的基石类型。你写 std::ranges::sort(v) 时，底层确实用了 std::identity{}，只是编译器帮你隐式提供了；一旦你需要显式控制投影链、参与 concept 约束、或做泛型抽象，那个花括号就是绕不开的硬门槛。
