直接用 std::vector 管理骨骼指针易崩溃，因 vector 扩容导致裸指针悬垂；应改用 std::vector 或 std::shared_ptr，父指针需循环检测，动画采样应通过索引查表，导出与运行时须按名称对齐索引。
为什么直接用 std::vector<bone></bone> 管理骨骼指针容易崩溃
因为骨骼数据常需频繁重排、插值、层级更新，裸指针在 std::vector 中发生扩容时会失效——vector 重新分配内存后，旧地址上的 Bone* 全变成悬垂指针。哪怕你用 reserve() 预留空间，只要后续调用 push_back() 超出容量，依然崩。
实操建议：
- 改用
std::vector<:unique_ptr>></:unique_ptr>：所有权明确，移动安全，且unique_ptr本身是轻量对象，vector移动/扩容不影响其指向的Bone实例内存 - 若需跨线程或共享访问（如动画混合线程 + 渲染线程），改用
std::vector<:shared_ptr>></:shared_ptr>，但注意引用计数开销 - 绝不要在
vector里存裸指针再手动new Bone—— 生命周期完全失控，调试时很难定位哪次delete搞错了顺序
Bone 类设计必须支持指针间接访问父骨骼
动画计算中，子骨骼的世界变换 = 父骨骼世界变换 × 本地变换。如果父指针失效或为空，整条链就错。
实操建议：
- 在
Bone中用Bone*存父指针，但初始化时只允许通过专用构造函数或setParent()设置，禁止外部直接赋值 - 在
setParent(Bone* p)内做空检查和循环引用检测（比如沿父链向上遍历，若碰到自己则报错） - 父指针不参与
unique_ptr管理——它只是观察者关系，生命周期由 vector 的 owner 管控；否则会引发循环持有导致内存泄漏 - 示例关键片段：
class Bone { public: void setParent(Bone* p) { if (p == this || isAncestorOf(p)) { /* 报错 */ } parent_ = p; } private: Bone* parent_ = nullptr; };
动画采样时如何避免指针跳变导致插值断裂
多动画混合（如行走+挥剑）需要对同一骨骼的多个 Bone* 同时采样。若某路动画数据中途释放了 Bone 实例，而另一路还拿着旧指针，transform 字段读出来就是垃圾值，插值结果突变。
实操建议：
- 所有动画片段（
AnimationClip）内部不持有Bone*，只存索引（size_t bone_index），运行时统一从主骨骼数组查表获取Bone& - 混合器（
AnimationBlender）按帧调用skeleton.bones()[i].localTransform()，确保每次访问都是最新、有效的实例 - 若必须缓存指针（如 GPU 绑定优化），用
std::weak_ptr<bone></bone>替代裸指针，并在使用前调用lock()检查有效性
导出器与运行时指针布局不一致引发的越界读取
FBX 或 glTF 导出器生成的骨骼顺序，和你在 C++ 运行时用 vector 构建的顺序不一致，会导致 bones[i] 访问到错误骨骼，尤其在皮肤蒙皮（skinning）阶段直接传给 GPU，显存写入错位。
实操建议：
- 导出器必须输出骨骼名称列表，并在加载时用
std::unordered_map<:string size_t></:string>建立名字→索引映射，而非依赖顺序 - 运行时构建
Bone实例后，立即按 name 排序或按 hierarchy 重建索引，确保bindPose[0]对应 root，且所有子节点索引连续可预测 - 在 debug build 中加断言：
assert(bone.name == expected_names[i]);，上线前可关掉，但开发期必须过这一关
真正麻烦的不是怎么存指针，而是谁负责释放、什么时候释放、释放后谁还能读——这些边界一旦模糊，动画抖动、穿模、崩溃全在 runtime 随机出现，复现成本极高。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
