std::generator 未被纳入 C++23 标准，目前所有主流编译器均不支持；替代方案是基于 co_yield 手写 generator 类，但需谨慎处理协程生命周期、异常及迭代器语义。
std::generator 在 C++23 中还没正式落地
目前（截至 GCC 14 / Clang 18 / MSVC 19.39），std::generator 并未进入 ISO C++23 标准库。它曾作为 P2502R2 提案被讨论，但已被 撤回并搁置。标准委员会最终选择不将其纳入 C++23。所以你无法在任何主流编译器中直接使用 std::generator —— 它不存在于 <generator> 或其他头文件中，也不会通过 -std=c++23 启用。
实际可用的替代方案：co_yield + 自定义 generator 类
虽然标准没提供，但所有支持 C++20 协程的编译器（GCC 10+、Clang 13+、MSVC 19.28+）都允许你手写一个轻量 generator。核心是用 co_yield 配合一个简单的包装类，管理协程句柄和迭代逻辑。
常见错误现象：co_yield 出现在非协程函数里、忘记 resume() 导致只产出第一个值、协程销毁后继续调用 operator++ 引发未定义行为。
- 必须将协程函数返回类型设为自定义
generator<T>，且该类需实现begin()/end()和迭代器（通常用iterator嵌套类封装std::coroutine_handle） -
generator构造时不应立即执行协程体；应延迟到首次begin()调用才resume()到第一个co_yield - 每次
co_yield v后，协程挂起，v的副本被存入迭代器内部（注意移动语义与生命周期） - 示例骨架：
template<typename T> class generator { struct promise_type; std::coroutine_handle<promise_type> h_; public: struct iterator { /* ... */ }; generator(std::coroutine_handle<promise_type> h) : h_(h) {} iterator begin(); iterator end(); }; <p>// 使用方式： generator<int> fib() { int a = 0, b = 1; co_yield a; co_yield b; while (true) { auto next = a + b; co_yield next; a = b; b = next; } }为什么别自己实现 full-featured generator
真正健壮的 generator 要处理：异常传播、多次遍历支持（C++20 协程默认不可重入）、内存分配策略（
promise_type::get_return_object_on_allocation_failure）、与范围适配器（如views::filter）的互操作。这些细节极易出错。
C++ Code Review Master下载组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 多数场景下，用
std::vector+ 惰性初始化 lambda 更安全（例如：按需计算第 n 项而非缓存全部） - 若需组合式惰性操作，
ranges::views::iota、views::transform已足够表达大部分需求，且完全标准、无协程开销 - 第三方库如 tl::generator（已归档）或 libcxx 的实验性实现（未公开 API）都不建议用于生产
编译与调试协程 generator 的关键点
启用协程需要显式链接支持库（尤其 Clang），且调试体验差：GDB/LLDB 对挂起/恢复点的支持仍不稳定，断点可能跳过
co_yield行。- GCC：需
-fcoroutines -lstdc++_coro（libstdc++_coro 是独立静态库） - Clang：需
-stdlib=libc++ -lc++experimental（部分版本还需-fcoroutines-ts） - MSVC：默认启用，但需 `/await`，且 `generator` 类的析构必须显式调用
h_.destroy()，否则内存泄漏 - 常见错误信息：
error: use of undeclared identifier 'co_yield'→ 忘加协程标志；segmentation fault (core dumped)→ 协程 handle 已 destroy 后继续 resume
真正想用“标准 generator”，得等 C++26 或更晚——而那时接口设计可能已完全不同。现在最务实的做法，是明确区分：哪些逻辑必须惰性（如超长序列、IO 边界）、哪些其实可以预计算（如固定小集合），再决定是否值得引入协程复杂度。
- 多数场景下，用
