最可靠的方式是用 type(obj) is set 或 type(obj) is frozenset 进行显式类型比对；isinstance(obj, set) 无法识别 frozenset 且易误判伪装类，hasattr(obj, ‘add’) 等接口检查更不可靠。
用 type() 直接比对最可靠
python 中 set 和 frozenset 是两个独立类型，不能靠 isinstance(obj, set) 同时覆盖两者（因为 frozenset 不是 set 的子类），也不能只检查是否可变——有些自定义类也可能实现 add() 方法。最准确的方式是显式比对类型：
-
type(obj) is set→ 真正的set -
type(obj) is frozenset→ 真正的frozenset - 避免用
isinstance(obj, set)：它对frozenset返回False，但对set返回True，看似可用，却掩盖了“非 set 却有 set 接口”的误判风险（比如某个类实现了add、remove但不是set）
hasattr(obj, 'add') 不能作为判断依据
很多教程建议用是否含 add 方法来区分，这是错的：
-
set有add，frozenset没有 → 表面看可行 - 但第三方类或用户自定义容器可能也定义了
add，却既不是set也不是frozenset - 更隐蔽的问题：
set的子类如果重写了__hash__变成不可变，它依然有add，但已不是原生set行为 - 所以仅靠方法存在性，无法确认“是不是真正的
set”
需要兼容性判断时，明确你要的是“可变性”还是“类型身份”
实际代码中常混淆这两个需求：
- 若你真正关心“能否修改”，应测
hasattr(obj, 'add') and not hasattr(obj, '__hash__')（注意：frozenset有__hash__，set没有） - 若你真正关心“是不是内置
set类型”，必须用type(obj) is set—— 这是唯一能排除子类、伪装类、协议实现的方案 - 用
isinstance(obj, collections.abc.MutableSet)可覆盖所有可变集合协议实现，但它会把自定义类也纳入，不满足“真正set”这个窄定义
在序列化或类型敏感场景下，type() 检查不可省略
比如 jsON 序列化器、ORM 字段校验、类型注解运行时检查，都依赖精确类型识别：
-
json.dumps({1, 2})报TypeError，因为set不可序列化；但frozenset({1, 2})同样报错，两者行为一致，但错误来源不同 - 若你想只允许原始
set（拒绝frozenset和任何子类），就必须写if type(data) is not set: raise TypeError(...) - 写成
if not isinstance(data, set)会导致frozenset被放过，而它显然不是你要的可变集合
真正难的不是怎么写判断，而是想清楚你到底在防御什么：是接口行为？可变性？还是类型血统。一旦目标模糊，type() 就成了最容易被绕过的漏洞点。