for遍历C++数组时下标越界最常见，应统一使用size_t避免符号比较警告；std::for_each非语法糖但可读性差、调试难、无性能优势；原生数组生命周期管理易被忽略。
用 for 遍历 C++ 数组时，下标越界是最常见的崩溃原因
直接用 i 算长度看似稳妥，但只在**栈上定义的原生数组**里有效。一旦传进函数，<code>arr 会退化成指针，sizeof 就只剩 8（64 位）或 4（32 位），结果永远错。
- 函数参数写
int arr[]或int* arr—— 此时必须额外传长度，比如void process(int arr[], size_t len) - 用
std::array或std::vector替代原生数组，它们自带.size()，且类型安全 - 如果非要用原生数组且确定不传参，可用
constexpr size_t N = std::size(arr);（C++17 起），比手算sizeof更清晰
range-based for 循环在什么情况下不能用
它写起来简洁：for (auto& x : arr) { ... }，但有几个硬限制：
- 无法获取当前下标 —— 想同时打印“第几个元素”就得另设计数器或改用传统
for - 不能反向遍历 ——
for (auto& x : std::ranges::reverse_view(arr))是 C++20 才有，老项目别指望 - 对 C 风格字符串（
char s[] = "abc"）会把末尾'\0'也当元素遍历，除非你显式截断 - 若要修改容器本身（比如边遍历边
erase），range-based for会失效甚至 UB，必须用迭代器 +while或索引
循环变量类型选 size_t 还是 int？
数组长度是无符号的，size_t 是标准答案。但用 int i 在小数组上也能跑通，隐患藏得深：
- 当数组长度超过
INT_MAX（约 21 亿），int会溢出，循环条件突然变假，直接跳过整个循环 - 更隐蔽的是：如果循环里写
if (i >= 0)，size_t的i永远为真（无符号数不可能小于 0），而int的负值判断才有效 —— 类型混用容易翻车 - 和
std::vector::size()、std::string::length()等返回值类型保持一致，避免编译器警告（如 GCC 的-Wsign-compare）
用 std::for_each 替代手写循环值得吗
它不是语法糖，而是明确表达“对每个元素执行某操作”的意图，但代价是可读性可能下降：
立即学习“C++免费学习笔记（深入）”；
- 简单逻辑（如累加、打印）用
std::for_each反而啰嗦，不如 range-based for 直观 - 捕获局部变量时要注意：用
[&]引用捕获，若循环体较长或嵌套深，谁改了谁的值容易混乱；用[=]值捕获又可能拷贝大对象 - 调试困难：断点打在 lambda 里不如打在传统循环体里直观，尤其涉及多线程时堆栈更难追踪
- 性能无优势 —— 编译器对传统
for优化更成熟，std::for_each不会自动向量化
真正容易被忽略的是：原生数组的生命周期管理。哪怕循环写对了，如果数组是函数内局部变量，而你把它的地址存到了别处（比如全局指针），循环结束那一刻数据就失效了 —— 这类问题不会报错，只会随机崩或输出垃圾值。
