部署后/api/register-application/报TypeError: unhashable type: 'set'求助

核心原因定位 #

这个错误本质是代码中将不可哈希的set类型用在了需要哈希值的场景（比如作为字典的键、存入集合、缓存序列化等），本地和服务器的差异通常是环境依赖版本、配置或请求参数解析逻辑的细微区别触发了这个问题。

排查与解决步骤 #

1. 检查接口视图的参数处理逻辑 #

找到/api/register-application/对应的视图函数，重点排查以下代码：

• 是否有将请求参数转换为set的操作，且后续将该set用于哈希场景（比如作为字典键、存入缓存、传递给要求哈希类型的函数）
• 是否在定义字段白名单、过滤条件时，误将列表[]写成了集合{}（虽然集合遍历没问题，但如果后续将其作为哈希键的一部分会报错）
• 是否存在序列化器中将字段值转为set的自定义逻辑

解决示例：
如果代码中有：

tags = set(request.data.get('tags', []))
# 后续将tags作为字典键存入缓存
cache.set(f'tags_{tags}', some_value)

将set改为list即可：

tags = list(request.data.get('tags', []))

2. 对齐本地与服务器的依赖版本 #

本地正常但服务器报错，大概率是依赖版本不一致导致的行为差异：

• 导出本地依赖列表：pip freeze > local_requirements.txt
• 导出服务器依赖列表：pip freeze > server_requirements.txt
• 对比两个文件，找出版本不一致的包（重点关注Web框架、序列化库、ORM相关包，比如Django、DRF、SQLAlchemy等）
• 将服务器的依赖版本对齐到本地版本，或者修改代码适配服务器的依赖版本

3. 排查ORM查询与数据持久化逻辑 #

检查视图中涉及数据库操作的代码：

• 是否将set作为filter()的__in参数（虽然ORM通常支持可迭代对象，但后续如果对该set做哈希操作会报错）
• 是否有将set类型数据直接存入数据库字段的操作（比如模型字段定义为JSONField，但存入set会导致序列化失败）

解决示例：
如果代码中有：

app_ids = {1, 2, 3}
applications = Application.objects.filter(id__in=app_ids)
# 后续将app_ids作为字典键
app_map = {id: app for id, app in zip(app_ids, applications)}

将set转为list：

app_ids = [1, 2, 3]

4. 清除缓存与检查配置文件 #

• 服务器可能开启了缓存（比如Redis、Memcached或框架内置缓存），缓存中可能存储了之前错误的set类型数据，清除缓存并重启服务
• 检查项目配置文件，确保所有需要列表类型的配置项没有误写成集合（比如ALLOWED_HOSTS、CORS_ALLOWED_ORIGINS等），例如：
  错误写法：ALLOWED_HOSTS = {'your-domain.com'}
  正确写法：ALLOWED_HOSTS = ['your-domain.com']

内容的提问来源于stack exchange，提问作者Shuseel Maharjan