资源句柄应采用引用计数+句柄抽象设计，内部存储唯一id和版本号，通过管理器统一维护生命周期，访问前校验有效性，空闲槽位用freelist管理，禁止暴露裸指针，所有访问必须经管理器get()方法。
资源句柄怎么设计才不会裸指针悬挂？
裸指针管理资源时，一旦资源被卸载，所有持有该指针的地方立刻变成悬垂指针——崩溃往往发生在最意想不到的渲染帧里。核心解法是用引用计数 + 句柄抽象，让使用者只接触 ResourceHandle 这种轻量值类型，背后由管理器统一维护生命周期。
-
ResourceHandle内部存一个唯一 ID（如uint64_t）和版本号，不直接存指针；每次访问前校验 ID 和版本是否匹配当前资源槽位 - 资源实际存储在
std::vector<:unique_ptr>></:unique_ptr>中，空闲槽位用 freelist 管理，避免 vector 重分配导致句柄失效 - 禁止把
Resource*直接暴露给业务层；所有获取资源的操作必须走管理器的get()方法，它内部做有效性检查并返回std::shared_ptr或std::optional
加载逻辑如何避免重复读取和线程冲突？
同一路径的纹理被 load("brick.jpg") 调用十次，结果生成十个内存副本，显存炸了还查不出原因——这是没做路径级缓存和加载状态同步。
- 用
std::unordered_map<:String loadstate></:string>记录每个路径当前状态：Pending/Loading/Ready/Failed - 调用
load()时先查 map：若为Pending或Loading，直接返回已有ResourceHandle，不发起新加载 - 文件 I/O 必须在工作线程做，但资源创建（如
glTexImage2D）只能在主线程；用std::promise<:shared_ptr>></:shared_ptr>拆分阶段，避免 OpenGL 上下文跨线程调用
资源卸载时机该由谁决定？
手动调用 unload("ui_bg.png") 看似可控，实则极易遗漏或误删——比如 UI 切换时旧界面还没完全销毁，资源就被清掉了。
- 卸载决策必须基于引用计数，不是路径名；只有当
ResourceHandle的内部引用计数归零，且无 pending 加载请求时，才真正释放底层资源 - 提供
unload_unused()接口供帧末调用，扫描所有资源槽位，对计数为 0 的执行异步清理（避免卡主线程） - 调试时可开启
enable_leak_detection模式，记录每个资源最后被哪个ResourceHandle持有，方便定位“谁忘了 release”
不同资源类型怎么共用一套管理框架？
纹理、模型、着色器编译后结构差异大，硬塞进一个模板类容易变成类型擦除地狱，运行时开销大还难调试。
立即学习“C++免费学习笔记（深入）”；
- 用 CRTP（
ResourceManager<texture></texture>、ResourceManager<model></model>）分离类型，共享底层的句柄分配、加载队列、缓存策略等逻辑 - 每种资源类型实现统一接口：
load_from_file(const std::string&)、is_loaded() const、get_native_handle() const（返回GLuint或aiScene*等） - 避免在管理器里写
if (type == TEXTURE) {...} else if (type == MODEL) {...}—— 类型分支移到编译期，靠模板特化解决
最麻烦的从来不是怎么加载，而是怎么证明某块显存确实该被释放了。句柄版本号校验、加载状态机、引用计数与 freelist 的耦合细节，三者少一个，内存就漏得悄无声息。