std::vector重分配时迭代器失效，因其底层连续内存被重新申请、拷贝并释放，原迭代器变为悬垂；reserve()可预防，下标访问更安全；weak_ptr配合shared_ptr解决循环引用与悬垂访问。
std::vector 重分配时迭代器为什么会失效
因为 std::vector 的底层是连续内存块，当插入导致容量不足时，会申请新内存、拷贝元素、释放旧内存。所有指向原内存的迭代器、指针、引用立即变为悬垂状态。
常见错误现象：
auto it = vec.begin() + 2; vec.push_back(x); // 可能触发 reallocation *it = 42; // 未定义行为：访问已释放内存
- 使用
reserve()预留足够空间可避免多数场景下的重分配 -
vec.data()返回的指针在push_back后同样失效，不能当作“更稳定”的替代 - 若必须持有所需位置的逻辑索引，改用下标
size_t idx而非迭代器
shared_ptr 和 weak_ptr 配合解决循环引用与悬垂访问
std::shared_ptr 自动管理对象生命周期，但两个对象互相持有 shared_ptr 会导致引用计数永不归零；而裸指针或 shared_ptr 直接解引用可能访问已析构对象。
正确做法是：一方用 shared_ptr，另一方用 weak_ptr 持有，并在访问前调用 lock()：
class Node {
public:
std::shared_ptr<node> next;
std::weak_ptr<node> prev; // 避免循环引用
};
void traverse(std::shared_ptr<node> p) {
while (p) {
auto next = p->next;
auto locked_prev = p->prev.lock(); // 安全尝试获取强引用
if (locked_prev) {
// prev 仍存活，可安全使用 locked_prev
}
p = next;
}
}</node></node></node>
-
weak_ptr::lock()返回shared_ptr，若原对象已销毁则返回空shared_ptr - 不要对
weak_ptr直接解引用（*wp或wp->）——编译不通过，这是保护机制 - 仅在需要“观察但不延长生命周期”时用
weak_ptr，比如缓存、观察者、父-子关系中的子→父引用
容器内存储指针 vs 存储对象：何时该用 unique_ptr
在 std::vector 或 std::map 中存裸指针（如 vector）极易引发悬垂：指针所指对象提前析构，容器却毫不知情。
生成Blender Python (bpy)脚本，该脚本使用node_groups API和GeometryNodeTree接口程序化地创建几何节点修改器树，用于参数化3D资产生成。
推荐用 std::unique_ptr 显式转移所有权：
std::vector<:unique_ptr>> items;
items.push_back(std::make_unique<foo>(1));
items.push_back(std::make_unique<foo>(2));
// 迭代安全：移动语义保证指针不悬垂，且 vector 不复制对象本体
for (const auto& ptr : items) {
if (ptr) ptr->do_something(); // ptr 为空只发生在显式 reset 后
}</foo></foo></:unique_ptr>
-
unique_ptr禁止拷贝，强制移动语义，杜绝意外共享 - 容器析构时自动调用每个
unique_ptr的析构函数，确保资源释放 - 若需共享所有权，用
shared_ptr；若只是临时观察，用weak_ptr或原始引用（前提是被引用对象生命周期明确长于观察者）
erase-remove 惯用法为何能避免迭代器失效
直接写 for (auto it = c.begin(); it != c.end(); ++it) 并在循环中调用 c.erase(it) 是危险的：erase 使 it 失效，而 ++it 会解引用已失效迭代器。
erase-remove 惯用法把逻辑删除和物理删除分离：
vec.erase(
std::remove_if(vec.begin(), vec.end(), [](const auto& x) { return x.is_dead(); }),
vec.end()
);
-
std::remove_if不改变容器大小，只重排元素，返回新逻辑终点迭代器 -
erase接收该迭代器区间，一次性清除尾部冗余元素，期间无中间迭代器失效问题 - 对
std::list或std::forward_list，可用成员函数remove_if()（它自己处理迭代器有效性）
自定义容器类如何安全暴露迭代器
如果你实现一个类似 MyVector 的容器，对外提供 begin()/end()，必须确保：用户持有的迭代器在容器发生任何修改后是否仍有效，要明确定义并严格遵守。
- 若内部使用连续内存（如
std::vector），应模仿其失效规则：所有非 const 成员函数（除operator[]、at()）都可能使所有迭代器失效 - 若用链表结构，可承诺仅
erase使被删节点迭代器失效，其余操作保持其他迭代器有效 - 在文档或注释中明确写出每种操作对迭代器有效性的影响，比“尽量不失效”更有实际价值
- 考虑添加
[[nodiscard]]到begin()/end()，提醒调用者注意返回值生命周期依赖容器本身
真正棘手的不是某一行代码写错，而是多个组件生命周期边界模糊——比如一个 shared_ptr 从线程 A 创建，在线程 B 中被 weak_ptr::lock() 失败，但没检查返回值就直接用了；或者 vector 在 lambda 捕获中被隐式复制，导致后续修改不影响原始容器。这些地方没有编译错误，但运行时行为不可控。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
