对象支持 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 
class ControlledResource: slots = ['data', 'weakref'] def init(self, data): self.data = data
只通过此函数分发弱引用，便于审计/限流/日志
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 机制，而是让对象本身不值得被长期弱引用——比如它的状态随时可能失效，或每次访问都需校验有效性。