C++容器默认传值不影响原对象，因拷贝构造生成独立副本；传引用或指针才影响原对象；cppcheck的invalidContainerLoop警告仅关注遍历时修改同一容器，与传参方式无关。
传值 vs 传引用：容器参数传递方式决定是否影响调用者
不会自动影响调用者——除非你明确用了引用或指针。C++ 默认按值传递，std::vector、std::unordered_map 这类容器传入函数时，会调用拷贝构造函数生成一份独立副本。你在函数里 push_back、clear、erase，改的只是这个副本。
常见错误现象：调试时发现函数内修改了容器，但主调代码里数据没变，就以为“函数没生效”，其实是传值导致的预期偏差。
- 传值（默认）：
void f(std::vector<int> v)</int>→ 修改v不影响原对象 - 传非 const 引用：
void f(std::vector<int>& v)</int>→ 修改直接作用于原对象 - 传 const 引用：
void f(const std::vector<int>& v)</int>→ 不能修改，编译报错 - 传指针：
void f(std::vector<int>* v)</int>→ 需显式解引用，效果同引用
cppcheck 报 invalidContainerLoop 和传参方式无关
这个警告只关心「同一个容器对象在遍历时被修改」，不看你用的是值还是引用传参。只要循环和修改操作落在同一对象生命周期内，就可能触发。
例如传引用进来后写范围 for 循环 + push_back，照样报错：
立即学习“C++免费学习笔记（深入）”；
void f(std::vector<int>& v) {
for (auto i : v) { // 隐式使用 v.begin()/v.end()
if (i < 5) v.push_back(i * 2); // ← cppcheck: Calling 'push_back' while iterating the container is invalid.
}
}原因不是传参，而是 for (auto i : v) 在底层展开为迭代器遍历，而 push_back 可能使迭代器失效——哪怕 v 是引用，它仍是同一个对象。
传值容器的移动成本：别忽视 noexcept
如果容器元素类型有自定义移动构造函数，且没加 noexcept，传值调用时编译器可能放弃移动、退回到深拷贝，性能骤降。
- 传值参数会触发移动（C++11 后优先）或拷贝；移动是否真被采用，取决于元素类型的移动构造是否
noexcept - 比如
std::vector<heavyobject></heavyobject>传值，若HeavyObject移动构造没标noexcept，整个 vector 就会拷贝而非移动 - 修复方式：给移动构造/赋值加上
noexcept，并确保所有成员移动也满足该约束
想安全修改又避免意外影响？优先用 const 引用 + 返回新容器
现代 C++ 更倾向“输入不可变、输出新值”的风格，既避免副作用，又利于编译器优化和并发安全。
例如过滤 vector：
std::vector<int> filter_less_than_5(const std::vector<int>& v) {
std::vector<int> result;
result.reserve(v.size()); // 预分配防多次 realloc
for (int x : v) {
if (x < 5) result.push_back(x);
}
return result; // C++17 guaranteed copy elision
}这种写法绕开了迭代器失效、传参歧义、异常安全等一堆坑。真正复杂逻辑里，比“传引用+就地修改”更易测试、更难出错。
容易被忽略的一点：即使你控制了传参方式，std::list::splice 或 std::unordered_map::extract 这类操作仍会改变容器结构，若其他地方持有迭代器或指针，依然可能失效——影响范围不止于调用者是否看到修改，还涉及整个对象图的有效性。
