对象支持 weakref 的前提是具有可访问的 __weakref__ 插槽；若未定义或设为 None，则无法创建弱引用；所谓“支持但禁止”实为设计约束，需通过封装、代理或控制对象分发来实现。
为什么默认对象不支持 weakref
Python 中大多数自定义类实例默认支持 weakref，但有两个常见例外：__slots__ 类没定义 __weakref__ 插槽，或显式设置了 __weakref__ = None。更关键的是：**支持 weakref ≠ 允许被弱引用**——真正起决定作用的是对象是否具有可访问的 __weakref__ 插槽，且未被禁用。
如何让对象「可被 weakref 引用」但「禁止直接赋值 weakref」
这里存在一个常见误解：weakref 本身不是“直接引用”，它只是不阻止对象回收的间接句柄。你真正想控制的，是“谁可以创建 weakref”或“对象是否允许被外部 weakref 持有”。Python 没有内置机制禁止用户调用 weakref.ref(obj)，但你可以通过拦截构造逻辑实现效果：
- 重写
__new__，在对象创建时检查调用栈（不推荐，不可靠） - 更实际的做法：让对象在被
weakref.ref()包装后，其回调或调用行为失效 —— 但这治标不治本 - 真正可控的路径是：**不暴露原始对象，只提供封装后的代理或接口**
例如，用工厂函数返回一个包装器，内部持有真实对象，但对外只暴露不可弱引用的接口（如 functools.partial、types.SimpleNamespace 实例，或自定义无 __weakref__ 的类）。
怎样构造一个「支持 weakref」但「自身不暴露 __weakref__」的对象
目标其实是矛盾的：若对象没有 __weakref__ 插槽，weakref.ref(obj) 会直接抛出 TypeError: cannot create weak reference to 'X' object；若它有，则必然可被弱引用。所以“支持但禁止”只能靠设计约束：
- 使用
__slots__ = ['a', 'b']且**不包含'__weakref__'** → 对象不可被 weakref 引用 - 若需支持 weakref，必须显式加入
'__weakref__'：__slots__ = ['a', 'b', '__weakref__'] - 想“禁止直接引用”，实际应转为“禁止直接持有该对象”——即不把对象实例交给不可信代码，而是通过闭包、弱字典或事件总线间接交互
示例：强制弱引用唯一入口
import weakref
<p>class ControlledResource:
<strong>slots</strong> = ['data', '<strong>weakref</strong>']
def <strong>init</strong>(self, data):
self.data = data</p><h1>只通过此函数分发弱引用，便于审计/限流/日志</h1><p>def get_weak_ref(obj):
if not isinstance(obj, ControlledResource):
raise TypeError("Only ControlledResource allowed")
return weakref.ref(obj)
容易忽略的关键点：weakref 回调和生命周期耦合
即使你设法限制了 weakref 创建，只要对象有 __weakref__ 插槽，任何拿到该对象的地方都能调用 weakref.ref(obj, callback)。而回调函数会持有一个对 callback 的强引用，若 callback 又闭包捕获了该对象，就可能意外阻止回收。
- 回调中避免反向引用原对象或其容器
- 使用
weakref.finalize替代带 callback 的ref，更可控 - 注意 C 扩展对象（如某些 NumPy 数组、socket）可能不支持 weakref，即使没报错，行为也可能未定义
最稳妥的方式不是对抗 weakref 机制，而是让对象本身不值得被长期弱引用——比如它的状态随时可能失效，或每次访问都需校验有效性。
