Python json.dumps 序列化 set 后 in 判断静默失效？default=str 的隐藏陷阱
在用 json.dumps(data, default=str) 把一个含 Python set 的字典持久化、再回读用 in 判断成员时，结果静默出错——没有任何报错，但 in 判断全乱。
在开发 AI运营 时遇到此问题——基于大语言模型的智能分析，自动洞察市场趋势、用户行为、销售数据，提供精准运营策略。某次分析模板的决策重放（replay）功能里，需要把「缺失月份集合」序列化进快照、回放时再读出来判断某月是否缺失。结果重放后，本应判定为「缺失」的月份被误判为「不缺失」，而整个链路没有任何异常抛出。
TL;DR
default=str 不是万能兜底。它会把 set 交给 str()，在 JSON 里存成 "{1, 2}" 这样的字面量字符串而非数组；回读后类型已不可逆，对它做 in 判断会退化成子串匹配，静默返回错误结果。涉及 set 时，正确做法是序列化前转 list、读取时 set() 重建。
问题现象
下面这段代码完整复现了静默出错的过程：
import json
# 一个含 set 的字典——比如"需要补数据的缺失月份"
data = {"missing_months": {"3", "5", "12"}}
# 用 default=str 兜底序列化（常见的"别让它报错"写法）
serialized = json.dumps(data, default=str)
print(serialized)
# {"missing_months": "{'3', '5', '12'}"} ← 变成了字符串，不是数组！
# 回读
back = json.loads(serialized)
value = back["missing_months"]
print(type(value)) # <class 'str'> ← 已经不是 set 了
# 静默 bug：本想判断某月份是否在"缺失集合"里
print("1" in value) # True ← 1 根本不在 {3,5,12}，但 "1" 是 "12" 的子串！
print("3" in value) # True ← 碰巧对
print("9" in value) # False
"1" in value 返回 True，但原集合 {"3", "5", "12"} 根本不含 "1"。没有异常、没有警告，判断结果就这样悄悄错了。这种 bug 在依赖判断结果做分支（如「这个月缺数据吗？缺则补采」）的链路里尤其致命。
根因
分三层看：
第一层：set 本就不可 JSON 序列化。 JSON 只有 array（对应 list）和 object，没有集合类型。直接 json.dumps({"x": {1, 2}}) 会抛 TypeError: Object of type set is not JSON serializable。
第二层：default=str 把报错变成了静默污染。 json.dumps 的 default 参数在遇到无法序列化的对象时被调用，期望返回一个可序列化的值。str 作为 default 时，会把对象交给 str()——set 就被转成了它的 Python 字面量表示 {'3', '5', '12'}，作为字符串存进 JSON：
>>> json.dumps({"m": {"3", "5", "12"}}, default=str)
'{"m": "{\'3\', \'5\', \'12\'}"}'
报错消失了，代价是类型从 set 变成了 str，且这个过程不会给你任何提示。
第三层：in 对 str 和 set 语义不同。 这是静默 bug 的核心。对 set/list，x in s 是成员判断；对 str，x in s 退化成子串匹配。回读后的值是字符串 "{'3', '5', '12'}"，于是 "1" in "{'3', '5', '12'}" 判断的是字符 "1" 是否作为子串出现——而 "12" 里恰好有 "1"，所以返回 True。
这和 Airflow PostgresHook 多语句 SQL 静默丢结果 是同一类陷阱：最危险的 bug 不是抛异常，而是「静默地给错结果」，因为没有任何信号提醒你去查。
解决方案
核心原则：JSON 里只存标准类型，集合语义在读取端重建。
方案一：序列化前显式转 list（推荐）
最直接、最可控——明确知道哪里有 set，就地转成 list：
import json
# 序列化前：set → list（标准 JSON 数组）
data = {"missing_months": list({"3", "5", "12"})}
serialized = json.dumps(data)
print(serialized)
# {"missing_months": ["3", "5", "12"]} ← 正确的 JSON 数组
# 回读后重建 set
back = json.loads(serialized)
months = set(back["missing_months"])
print("1" in months) # False ✓
print("3" in months) # True ✓
序列化结果是一个干净的 JSON 数组，跨语言、可读、可还原。
方案二：自定义 default 函数（数据来源复杂时）
如果数据结构较深、不确定哪里混入了 set，用一个专门处理集合类型的 default 函数，既不丢失语义，又能兜底其他非标准类型：
import json
def safe_default(obj):
# 集合类型 → list，保留为标准 JSON 数组
if isinstance(obj, (set, frozenset)):
return sorted(obj) # 排序让输出稳定可预测
# 其他无法序列化的类型再退回 str，但要清楚这会丢类型
return str(obj)
data = {"missing_months": {"3", "5", "12"}, "created_at": some_datetime}
serialized = json.dumps(data, default=safe_default)
# {"missing_months": ["3", "5", "12"], "created_at": "..."}
back = json.loads(serialized)
months = set(back["missing_months"])
print("1" in months) # False ✓
相比无脑 default=str，这个函数把「需要保真的类型」（集合）单独处理，只有真正无法表示的类型才退回 str，把静默风险控制到最小。
注意事项
default=str是「静默」而非「安全」：它消除了报错，却把set/tuple/datetime/自定义对象全部压扁成字符串，类型信息不可逆。回读后所有依赖原类型的运算（in成员判断、算术、比较）都可能出错。- tuple 也有类似问题：
str((1, 2))是"(1, 2)"，同样会让回读后的in退化成子串匹配。处理集合类容器的思路一致：序列化成 list。 - 跨进程/跨语言是试金石：如果这份 JSON 会被 Node.js、Go 等读取，
default=str产出的"{1, 2}"在那边只是一个普通字符串，连 Python 字面量都不是，还原几乎不可能。坚持存标准 JSON 类型才能保证可移植。 - 优先在源头转换：与其事后用
default兜底，不如在构造数据结构时就用list存集合语义，从根上避免set进入序列化管线。
常见问题
Python set 怎么转 json？
set 不是 JSON 原生类型，直接 json.dumps 会抛 TypeError。正确做法是序列化前用 list(set) 转成列表，存成标准 JSON 数组；读取时再 set(back["key"]) 重建。这样既不报错，又能完整还原集合语义，跨语言也兼容。
json.dumps 报 Object of type set is not JSON serializable 怎么解决？
根因是 set 不可 JSON 序列化。最稳妥的解法是序列化前把 set 转成 list；也可以传一个 default 函数，在里面对 isinstance(obj, (set, frozenset)) 返回 list(obj)。要避免用 default=str 兜底——它虽不报错，却把 set 存成了字符串，回读后类型无法还原。
为什么 default=str 序列化 set 后 in 判断结果错了？
default=str 会把 set 交给 str()，变成字面量字符串 '{1, 2}' 存进 JSON。回读后值类型是 str 而非 set，x in s 就从「成员判断」退化成「子串匹配」——比如 "1" in "{'3','5','12'}" 因 "12" 含字符 "1" 而返回 True，但原集合并不含 "1"。解法是序列化 list、读取时 set() 重建。