std::fill用于批量赋相同值，要求迭代器范围有效；std::iota生成等差序列，要求类型支持operator++；二者语义不同不可互换，且均依赖正确的迭代器边界。
用 std::fill 批量赋相同值，但要注意迭代器范围有效性
std::fill 最适合给数组（或容器）所有元素设成同一个值。它不关心类型是否可自增，只要支持赋值就行，比如 int、double、std::string 甚至自定义类（只要重载了 operator=）。
常见错误是传错迭代器边界：用 end() 没问题，但若手写指针偏移时漏减 1 或多加 1，就会越界写入——尤其对 C 风格数组，&arr[0] 和 &arr[N] 才是合法范围，&arr[N+1] 是未定义行为。
实操建议：
- 优先用容器的
begin()/end()，比如std::fill(vec.begin(), vec.end(), 42) - C 风格数组推荐配合
std::size：int arr[5]; std::fill(std::begin(arr), std::end(arr), 0) - 避免裸指针算术：不用
std::fill(arr, arr + 5, 0)—— 看似简洁，但5易和实际大小脱节
用 std::iota 生成等差序列，起始值和步长由赋值操作隐式决定
std::iota 不是“设初值再加步长”，而是对每个位置执行“当前值 = 起始值 + 索引”，本质是 value = value + 1 的连续赋值。这意味着它要求元素类型必须支持 operator++（后置或前置均可），且起始值能被该类型容纳。
立即学习“C++免费学习笔记（深入）”；
典型翻车场景：用 std::iota 初始化 std::vector<:string></:string> 会编译失败；对 unsigned char arr[10] 从 200 开始 iota，第 6 个元素就溢出回绕，但编译器不会报错。
实操建议：
- 只用于数值型（
int、long、size_t）或明确重载了operator++的类型 - 起始值务必预留足够空间：如需填
10个uint8_t，起始值不能 ≥ 246 - 想实现非 +1 步长（如 ×2、+3），不能直接用
iota，得改用std::generate+ lambda
fill 和 iota 性能差异极小，但语义不可互换
两者底层都是循环赋值，现代编译器优化后几乎没有性能差别。关键区别在语义：一个强调“统一状态”，一个强调“序号映射”。选错会导致逻辑错误，而非慢。
例如初始化索引数组：int idx[4] = {0,1,2,3} —— 必须用 iota，用 fill 只能得到 {0,0,0,0}；而清零操作用 iota 不仅多余，还可能因类型不支持而编译不过。
实操建议：
- 写代码时先问自己：“我要的是‘全一样’，还是‘按位置递推’？”
- 团队协作中，看到
iota就默认后续逻辑依赖元素值与下标的关系，别擅自替换成fill - 模板函数里慎用
iota，除非已用static_assert确保T支持自增
原生数组初始化时，fill 和 iota 都无法替代声明时的 {} 列表初始化
像 int arr[3] = {1,2,3}; 这种是编译期确定的初始化，fill 和 iota 都是运行期行为。有人误以为它们能“替代 memset 做快速清零”，其实对于 POD 类型，std::fill 编译器通常能优化成 memset，但 iota 永远是逐个赋值。
更隐蔽的问题是：全局/静态数组用 fill 或 iota 初始化，会把原本的零初始化拖到动态初始化阶段，可能引发静态初始化顺序问题。
实操建议：
- 能用
= {}在声明时搞定的，就别 runtime 再扫一遍 - 需要运行时计算初始值？优先考虑
std::vector+ 构造函数（如std::vector<int>(n, val)</int>或带 lambda 的std::generate_n） - 处理大数组且确定是数值类型时，确认编译器是否对
fill做了 memset 优化（看汇编或 benchmark），别凭感觉假设
真正容易被忽略的点：这两个函数都依赖迭代器范围正确性，而 C++ 没有内置数组长度检查——传错 end 迭代器，程序可能当场崩溃，也可能静默写坏其他变量，调试起来比逻辑错误更费时间。
