用指针遍历数组与用下标在现代编译器-o2及以上优化时性能无差异，因两者均被优化为相同高效寄存器操作，实际速度取决于内存访问模式而非语法形式。
用指针遍历数组比用下标快吗？
在现代编译器（如 GCC 12+、Clang 14+）开启 -O2 或更高优化级别时，for (int i = 0; i 和 <code>for (int* p = a; p != a + n; ++p) *p 生成的汇编通常完全一致——编译器能自动将下标访问优化为指针算术。手动改写成指针形式**不会带来性能提升**，反而可能干扰向量化（如 std::vector 的迭代器范围循环更易被 auto-vectorize）。
真正影响性能的是内存访问模式和缓存局部性，不是语法表象。盲目“用指针代替下标”是过时的微优化误区。
哪些场景下指针确实能改善循环性能？
当需要避免重复计算地址、或绕过边界检查开销时，指针才有实际价值。典型例子：
- 遍历
std::vector但已知非空且索引有效，用&vec[0]获取原始指针，避免每次调用operator[]的潜在（虽通常内联）函数跳转 - 处理 C 风格二维数组（如
int mat[1000][1000]），用int* p = &mat[0][0]展平访问，配合 stride 计算，比mat[i][j]减少一次乘法和加法 - 在 tight loop 中频繁调用带引用参数的函数（如
process(*p)），传指针比传vec.at(i)省去越界检查
注意：std::vector::data() 比 &vec[0] 更安全（对空 vector 行为定义明确），应优先使用。
容易踩的坑：指针循环的常见错误
手动管理指针边界极易引入未定义行为，比下标循环更难调试：
- 忘记初始化指针（如
int* p;直接进入循环）→ 解引用野指针 - 终止条件写成
p 而非 <code>p != end→ 多走一次，越界读 - 对
std::vector使用&vec[0] + vec.size()时，若vec.empty()，&vec[0]本身非法（即使不解引用） - 在循环中修改容器（如
push_back）导致迭代器/指针失效，而下标访问此时仍可能“碰巧”有效（但仍是 UB）
编译器对指针别名（aliasing）的假设也更保守，可能抑制某些优化（如 restrict 可缓解，但 C++ 中需用 __restrict 或依赖编译器扩展）。
什么时候该放弃指针，回归下标或迭代器？
除非你正在写高性能数值库、内核驱动或嵌入式实时代码，并且通过 perf / VTune 确认某段循环是瓶颈，且指针版本实测更快（并排除了测量噪声），否则：
- 对
std::vector、std::array，直接用基于范围的for (auto& x : vec)—— 编译器足够聪明，且语义清晰 - 需要索引时，用
for (size_t i = 0; i ，现代 CPU 分支预测对简单递增循环极友好 - 跨平台或需 STL 算法兼容时（如
std::transform），必须用迭代器，而非裸指针
真正的性能瓶颈往往在算法复杂度、缓存行填充、分支误预测或内存带宽上，而不是 a[i] 和 *(a+i) 的区别。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
