std::views::iota(0) 仅是步长为1的无限整数计数器，非通用等差序列；需配合 transform 映射索引并显式截断（如 take）才能安全使用，否则死循环或编译失败。
std::views::iota(0) 不是无限等差序列视图，它只是步长为 1 的无限整数计数器；真要生成首项 a、公差 d 的无限等差序列，必须组合 std::views::transform，且必须显式截断才能安全消费。
为什么 std::views::iota(0) 编译通过却不能直接当等差序列用
它返回的是 std::ranges::iota_view<int std::unreachable_sentinel_t></int>，语义上只保证“从 0 开始，每次 ++”，不提供公差控制，也不支持浮点或自定义步长。裸写 for (auto x : std::views::iota(0)) 会死循环——因为 end() 是不可达哨兵，it != end() 永远为真。
- 常见错误现象：
error: no matching function for call to 'iota(int)'在 MSVC 或 Clang 上可能直接报错，因部分标准库实现（如 libcpp）压根没提供单参数重载 - 即使 GCC 13 “看似能用”，本质是隐式推导出
unreachable_sentinel_t，仍是双参数特化，不可移植 - 类型敏感：传
long long和int混合会模板推导失败，必须统一，如std::views::iota<long long>(0, 10)</long>
如何用 std::views::iota + std::views::transform 安全生成任意公差等差视图
这是唯一标准、零拷贝、跨平台的方案：先生成索引，再映射。关键在顺序和捕获方式。
- 必须先限定长度再映射：写成
std::views::iota(0) | std::views::take(n) | std::views::transform(...)，而不是std::views::iota(0, huge) | std::views::transform(...) | std::views::take(n)——后者会多算huge - n次 - 捕获用值，不用引用：
[a = 5, d = 2.5]安全；[&a, &d]风险极大，视图生命周期可能长于局部变量 - 浮点场景别传
double给iota：std::views::iota(0.1, 1.0)编译失败（double不满足semiregular），且operator++加的是 1.0，不是 0.1 - 正确浮点写法：
std::views::iota(0, 100) | std::views::transform([a = 0.3, d = 0.7](int i) { return a + i * d; })
无限等差序列必须配 std::views::take 或 std::views::take_while
没有终结适配器的无限视图无法安全遍历。两者行为差异大，选错容易出问题。
立即学习“C++免费学习笔记（深入）”；
-
std::views::take(n)最安全：参数是无符号类型，take(-1)直接编译失败，不会运行时崩溃 -
std::views::take_while要慎用：浮点条件如[](double x) { return x 易受舍入误差影响，建议改用整数索引条件，如 <code>[limit = 100](int i) { return i - 对无限源头调用
std::ranges::size()或std::ranges::distance()会直接编译失败，不是运行时报错 -
std::views::iota(0) | std::views::transform(...)返回的仍是input_range，不支持随机访问、operator[]或std::sort
替代方案：std::views::generate 更适合动态/浮点等差序列
当首项或公差在运行时确定、或需高精度浮点控制时，std::views::generate 比 iota + transform 更直接。
- 闭包必须用引用捕获状态：
[v = 0.3, step = 0.7]() mutable { auto r = v; v += step; return r; }—— 不加mutable或用值捕获，值不会变 - 生命周期陷阱：变量
v必须在视图构造前声明，且生命周期 ≥ 视图；不能在 for 循环内定义后立刻构造视图 - 若需多个独立序列，应封装成函数返回
autoview，避免共享状态 - 该 view 同样是
input_range，不支持size()或随机访问，但比iota + transform少一层适配器开销
最易被忽略的一点：所有这些视图都是惰性求值，std::views::iota(0) | std::views::transform(...) 构造时几乎不花时间，但每次迭代都要执行 lambda。如果频繁随机访问第 k 项，std::ranges::advance(it, k) 会调用 k 次 lambda，而不是直接算 a + k * d —— 这时候预分配 std::vector 反而更高效。
