结构体作为函数参数时应根据大小和使用场景选择传递方式：对于大型结构体或需修改原数据的情况，应优先使用引用传递（尤其是const引用），以避免高昂的复制开销并保证效率；对于小型结构体或仅读取数据的场景，值传递更直观且性能良好，因小对象可被高效寄存或内联处理，同时能明确表达无副作用的语义，提升代码可读性和安全性。
结构体作为函数参数，本质上可以采取两种主要方式：值传递和引用传递。简单来说，值传递会复制一份结构体数据给函数，而引用传递则仅传递结构体在内存中的地址。选择哪种方式，直接关系到程序的性能、内存占用以及代码的可维护性。通常，对于小型结构体，值传递可能更直观且效率不差；而对于大型结构体或需要修改原数据的情况，引用传递（尤其是
const引用）则更为高效和安全。
解决方案
当我们将一个结构体作为函数参数传递时，编译器会根据我们的声明方式来决定是复制一份完整的结构体数据（值传递），还是只传递一个指向该结构体的内存地址（引用传递）。
值传递 (Pass by Value)
当函数参数声明为结构体类型本身时，例如
void func(MyStruct s)，这就是值传递。在这种情况下，函数在被调用时，会创建一个
MyStruct类型的新对象
s，并将传入的原始结构体中的所有成员变量的值复制到这个新对象中。
struct MyData {
int id;
char name[20];
double value;
// 可能还有更多成员，让它看起来“大”一些
int largeArray[1000];
};
void processByValue(MyData data) {
// 这里对data的任何修改，都不会影响到外部传入的原始MyData对象
data.id = 999;
// ...
}
// 调用示例：
// MyData originalData = {1, "Test", 123.45};
// processByValue(originalData);
// originalData.id 依然是 1值传递的优点是清晰：函数内部的操作不会影响到外部的原始数据，这在某些场景下可以避免意外的副作用。但其主要缺点是性能开销，特别是当结构体包含大量数据（比如大数组、多个字符串或复杂对象）时，每次函数调用都会进行一次完整的数据复制，这会消耗额外的CPU时间和内存带宽。
引用传递 (Pass by Reference)
当函数参数声明为结构体类型的引用时，例如
void func(MyStruct& s)，这就是引用传递。在这种情况下，函数不会复制结构体，而是直接操作原始结构体在内存中的位置。
struct MyData {
int id;
char name[20];
double value;
int largeArray[1000];
};
void processByReference(MyData& data) {
// 这里对data的修改，会直接影响到外部传入的原始MyData对象
data.id = 999;
// ...
}
void readOnlyByConstReference(const MyData& data) {
// 这里对data的访问是只读的，不能修改
// data.id = 999; // 编译错误！
int currentId = data.id;
// ...
}
// 调用示例：
// MyData originalData = {1, "Test", 123.45};
// processByReference(originalData);
// originalData.id 变为 999
// readOnlyByConstReference(originalData); // 仅读取，不修改引用传递的优点是效率高，因为它避免了数据复制。如果函数需要修改传入的结构体，引用传递是唯一的选择。如果函数只是需要读取结构体数据，但不需要修改，那么使用
const引用（
const MyStruct&）是最佳实践。
const引用既享受了引用传递的效率，又通过
const关键字保证了函数内部不会意外地修改原始数据，这提高了代码的健壮性。
结构体值传递的性能开销究竟有多大？
这其实是个老生常谈的问题，但我每次遇到大型结构体被值传递时，心里还是会咯噔一下。性能开销的大小，直接取决于结构体的大小。想象一下，一个包含几十个甚至上百个字段的结构体，或者像我上面示例中那样，内含一个大数组，每次函数调用都要完整复制一份，这不仅仅是内存的开销，更是CPU时间片的浪费。
数据从内存复制到CPU寄存器，再到栈帧，如果结构体过大，甚至可能导致缓存失效（cache miss）。CPU不得不频繁地从主内存读取数据，这比从L1/L2缓存读取慢了不止一个数量级。尤其是在循环中频繁调用，或者在性能敏感的系统（比如游戏引擎、高性能计算）里，这种开销会迅速累积，成为瓶颈。我个人在实践中发现，很多时候，性能瓶颈并不在于复杂的算法，而在于这种看似微不足道的“数据搬运”成本。曾经优化过一个图形渲染模块，发现有大量顶点数据结构体被值传递，改用引用后，帧率提升非常明显，那种感觉就像是终于把一块大石头从引擎上挪开了。
什么时候应该优先考虑结构体的引用传递？
在我看来，有几个场景是引用传递的绝佳舞台。最直接的，当然是当你需要在函数内部修改外部传入的结构体时。值传递会让你修改的只是一个副本，原数据纹丝不动，这显然不是你想要的。
再者，就是前面提到的，当结构体本身比较庞大时。这里的“庞大”没有一个绝对的字节数标准，但通常来说，如果结构体大小超过几个机器字长（比如32位或64位），或者包含多个复杂对象（如字符串、向量），那么引用传递的收益就会非常显著。它避免了不必要的内存分配和数据复制，直接操作原数据，效率自然就上来了。
此外，如果你只是想读取结构体的数据，但又不想承担值传递的复制开销，那么
const引用（
const MyStruct&）是你的不二之选。它既保证了效率，又通过
const关键字防止了函数内部对数据的意外修改，这是一种非常优雅且安全的做法。我经常把
const引用视为一种契约：我给你看我的数据，但你不能碰它，只能读。这让代码的意图更加明确，也降低了未来维护时引入bug的风险。
小结构体和内置类型的值传递总是最优解吗？
这问题其实挺有意思的，因为它不像大结构体那样非黑即白。对于像
int、
float、
bool这类内置类型，或者那些只包含几个基本数据类型字段的“小”结构体（比如一个表示2D坐标的
struct Point { int x; int y; };），值传递往往是更优的选择，甚至可以说是默认且推荐的做法。
为什么呢？因为这些小数据类型通常可以直接放在CPU的寄存器里处理，或者在缓存中占据非常小的空间。传递一个引用，虽然只传递地址，但这个地址本身也是一个指针大小的值，而且后续访问数据时，还需要一次解引用操作。现代编译器的优化能力非常强，对于小结构体的值传递，它们可能会直接将其展开（inlining），避免实际的函数调用开销，或者通过寄存器传递，效率极高。这种情况下，值传递的开销甚至可能比引用传递带来的额外解引用和潜在的缓存不友好性（虽然对于小结构体，这影响微乎其微）更小。
此外，值传递还有一个隐含的好处：它清晰地表明函数不会修改原始数据，这让代码的意图更加明确，降低了副作用的风险。我个人在写代码时，如果结构体不大，而且不需要修改原数据，我会毫不犹豫地选择值传递，因为它简单、直观，并且在大多数情况下性能表现出色，并且代码阅读起来也更直接，没有额外的符号（
&）需要解析，符合“能简单就简单”的原则。
