不会提前释放，但默认行为会绕过对象池复用逻辑；正确做法是自定义shared_ptr的deleter，使其调用return_to_pool而非delete，并确保池生命周期长于所有shared_ptr。
对象池里用 std::shared_ptr 会提前释放吗？
不会自动回收，反而容易“假回收”——std::shared_ptr 的引用计数归零时直接析构对象，完全绕过对象池的复用逻辑。对象池的核心是“不销毁、只重置”，而 shared_ptr 默认行为是“引用一空就 delete”。
- 典型错误：把池中对象用
std::make_shared<t>()</t>包装后返回，外部一离开作用域就触发析构 - 正确思路：让
shared_ptr的删除器（deleter）不调用delete，而是调用池的return_to_pool() - 注意：删除器必须捕获池的引用或指针，且该池生命周期必须长于所有持有
shared_ptr的对象
怎么写一个带池回收的 std::shared_ptr 工厂？
关键在自定义 deleter：它要能访问对象池实例，并把原始指针交还回去。不能用 lambda 捕获局部池变量（会悬垂），推荐传入池的 std::weak_ptr 或裸指针。
- 工厂函数返回
std::shared_ptr<t></t>，但构造时显式传入 deleter，例如：std::shared_ptr<t>(raw_ptr, [pool_ptr](T* p) { pool_ptr->return_to_pool(p); })</t> - 池类需提供线程安全的
return_to_pool(T*)，否则多线程下可能 double-return 或漏回收 - 避免在 deleter 里调用池的
acquire()或其他可能抛异常的操作——shared_ptr的析构不允许异常逃逸
std::unique_ptr 配合自定义 deleter 更轻量？
是的，unique_ptr 无引用计数开销，更适合对象池场景，只要确保所有权转移清晰即可。
- deleter 可以是函数对象或 lambda（捕获池指针更安全，因不涉及共享生命周期管理）
- 返回时用
std::unique_ptr<t decltype></t>显式指定类型，避免模板推导失败 - 缺点：无法被多个地方同时持有；如果业务需要“共享所有权再统一归还”，还是得回到
shared_ptr+ 安全 deleter - 常见坑：lambda 捕获了栈上池对象，而
unique_ptr生命周期超出该栈帧 → 崩溃
对象池自动回收的真正难点在哪？
不在智能指针怎么写，而在“谁来决定回收时机”和“池状态一致性”。智能指针只是触发点，不是决策者。
立即学习“C++免费学习笔记（深入）”；
- 对象内部状态是否干净？比如
T::reset()必须可靠，否则下次acquire()拿到的是脏数据 - 池本身是否支持并发 return/acquire？锁粒度太大伤性能，无锁实现又容易出 ABA 问题
- 如果对象持有外部资源（如文件描述符、GPU memory），
reset()必须显式释放，不能依赖析构——因为析构根本不会调用
写对 deleter 很容易，让整个生命周期里的 reset、return、acquire、线程安全全部对齐，才真正难。
