应使用 mystruct* arr + size_t n 形式；二者编译等价，但 arr[] 易误导为可推导长度，实际需显式传长度以防越界，且利于后续对接 std::span 或迭代器。
传参时用 struct* 还是 struct[]？本质没区别，但写法影响可读性
函数参数里写 MyStruct arr[] 和 MyStruct* arr 编译后完全等价，都是传指针。但前者容易让人误以为能自动推导数组长度——实际不能。
真正需要遍历时，必须额外传入长度，否则无法安全终止循环。
常见错误：在函数内对 arr[i] 循环却不检查边界，导致越界读取或崩溃。尤其当调用方传的是栈上小数组、而函数按“大数组”逻辑遍历时，问题更隐蔽。
建议统一用 MyStruct* arr + size_t n 形式，语义清晰，也方便后续改用 std::span（C++20）或迭代器接口。
遍历时该用 for (size_t i = 0; i 还是 <code>for (auto& s : span)？
原始 for 循环最通用，兼容所有 C++ 标准，且编译器优化充分。只要 n 是编译期常量或能被识别为不变量，现代编译器（如 GCC/Clang -O2）基本能生成和手动展开相当的汇编。
使用 std::span 更安全、更现代，但需 C++20 支持；若项目还卡在 C++11/14，别硬套——临时封装一个轻量 ArrayView 比强依赖新标准更务实。
不推荐用 while (ptr != end_ptr) 手动指针移动，除非你在写底层内存操作；普通业务逻辑中，它增加出错概率（比如忘记 ++ptr），且可读性差。
示例对比：
// 推荐：明确、安全、易调试
void process(MyStruct* arr, size_t n) {
for (size_t i = 0; i // C++20 可选：更泛型，但需确认构建环境支持
void process(std::span<mystruct> span) {
for (auto& s : span) {
use(s);
}
}</mystruct>
结构体太大时，遍历前要不要先做 memcpy 或重排内存？
如果结构体含大量未用字段（比如 128 字节结构体只读其中 2 个 int），遍历本身不慢，但缓存不友好——CPU 要反复加载整块无用数据，可能让吞吐下降 3–5 倍。
这时不应在遍历循环里做 memcpy，而应在数据准备阶段就考虑布局优化：
- 把热字段（频繁访问的）放在结构体开头
- 避免跨 cache line 存储关键字段（一般 64 字节一行，注意对齐）
- 真有极端场景（如每帧处理数万对象且只读 2 字段），可预提取成独立数组：
std::vector<int> xs, ys;</int>——即 AoS → SoA 转换
临时 memcpy 到局部 buffer 再遍历，通常得不偿失：多一次内存拷贝 + 更高 cache 压力，反而更慢。
为什么加 [[likely]] 或手动展开循环几乎没用？
对结构体数组遍历这种规则内存访问，分支预测和流水线已非常高效。给 for 条件加 [[likely]] 不会提升性能，因为循环分支本身就是高度可预测的。
手动展开（如每次处理 4 个元素）仅在极少数情况有用：编译器未能向量化、且你确认访存带宽是瓶颈。但多数时候，它让代码变臃肿、难维护，还可能阻碍编译器自动向量化（比如因引入复杂索引计算）。
真正有效的优化点是：确保 arr 地址对齐（alignas(64)）、结构体大小是 64 的倍数（减少 cache line 分裂）、关闭不必要的调试检查（如 UBSan/GCC 的 -D_GLIBCXX_DEBUG）。
最容易被忽略的一点：确认你的“结构体数组”确实是连续内存。用 std::vector<mystruct></mystruct> 或原生数组没问题；但若用 std::vector<:unique_ptr>></:unique_ptr> 存指针，那遍历的就是指针数组，实际数据分散在堆上——这时候再怎么优化循环也没用，得重构数据布局。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
