ranges::sort 编译失败主因是未包含头文件或未写全限定名std::ranges::sort；需注意参数为迭代器范围、自定义类型需可比较，且C++20 ranges生命周期管理更严格。
ranges::sort 为什么编译不过？
常见错误是直接对 std::vector 调用 ranges::sort 却忘了加命名空间或没包含头文件。C++20 的 ranges 功能分散在多个头文件里，ranges::sort 在 <algorithm></algorithm> 中，但必须显式写 std::ranges::sort（不能只靠 using namespace std，因为 ranges 是嵌套命名空间）。
- 必须
#include <algorithm></algorithm>，仅<vector></vector>或<ranges></ranges>不够 - 不能写
ranges::sort(...)，得写std::ranges::sort(...) - 参数不是“容器”，而是迭代器范围：支持
std::ranges::sort(vec)（容器重载），也支持std::ranges::sort(vec.begin(), vec.end()) - 如果传入自定义类型，要确保有默认
operator，或显式传比较器：<code>std::ranges::sort(vec, std::greater{})
filter_view 和 transform_view 怎么链式调用不崩溃？
链式视图（view）组合时最容易踩的坑是生命周期——视图不拥有数据，只引用原始范围。一旦原始容器（比如局部 std::vector）析构，后续访问 filter_view 就是未定义行为。
- 正确做法：把源容器声明在视图作用域之外，或用
std::move+views::common强制物化（但会失去懒求值优势） -
views::filter和views::transform返回的是临时视图对象，直接连写没问题：vec | views::filter(...) | views::transform(...) - 注意
views::filter的谓词必须是纯函数（不能捕获局部变量并修改它），否则行为不可预测 - 调试时可加
| views::take(5)截断输出，避免无限循环或大量计算
为什么 ranges::find 返回的迭代器不能直接解引用？
因为 std::ranges::find 返回的是 std::ranges::dangling 类型（当输入是纯右值范围时），这是 C++20 防止悬垂迭代器的安全机制。比如对临时字符串字面量调用：ranges::find("hello"sv, 'e')，返回的不是 string_view::iterator，而是 dangling，解引用会编译失败。
- 只要输入是左值（如命名变量
auto s = "hello"sv;），ranges::find(s, ...)就返回正常迭代器 - 临时范围 +
views::common可转为可存储的迭代器，但代价是复制一份底层数据 - 更安全的做法：先确认是否找到（
!= end(range)），再操作；别假设一定能解引用 - 这个设计不是 bug，是故意让“用错生命周期”在编译期暴露
MSVC / GCC / Clang 对 ranges 的支持差异在哪？
不是所有编译器默认开全 C++20 ranges 特性。GCC 10+ 支持大部分，但需 -std=c++20；MSVC 19.30+（VS 2022 17.0）才开始稳定支持 views，且早期版本对 ADL 查找有偏差；Clang 14+ 较好，但需 libc++15+ 配合。
立即学习“C++免费学习笔记（深入）”；
- 检查是否启用：编译时加
-std=c++20（GCC/Clang）或/std:c++20（MSVC） - MSVC 下若报
no member named 'begin' in namespace 'std::ranges'，大概率是标准库版本太旧，升级 VS 或改用 vcpkg 提供的较新 STL -
views::iota在 GCC 11 前不支持非整数类型，views::zip是 C++23 才进标准，别在 C++20 项目里硬用 - 跨平台项目建议：用
__cpp_lib_ranges宏做特性检测，而不是盲目#ifdef __GNUC__
真正麻烦的从来不是怎么写那几行 view 管道，而是谁持有数据、谁决定生命周期、谁在什么时候销毁——这些在传统迭代器里靠经验，在 ranges 里被编译器盯得更紧了。
