使用@st.cache装饰器结合SQLAlchemy遇无限循环问题求助

问题根源 #

核心问题在于Streamlit缓存机制无法正确处理SQLAlchemy的ORM对象（如Session、查询实例）——哪怕函数的输入输出是字符串和DataFrame，只要函数内部隐式依赖了这些不可哈希的有状态对象，就会触发缓存逻辑异常：要么出现哈希错误，要么陷入无限循环（缓存机制反复尝试哈希不可处理的对象）。旧版@st.cache的哈希逻辑对这类复杂对象支持不佳，也是重要诱因。

解决方案 #

1. 替换为Streamlit新版缓存装饰器

直接弃用旧的@st.cache，根据场景选择针对性的新版装饰器：

• 若函数返回数据（如pandas.DataFrame），使用@st.cache_data：它专门针对可序列化数据类型优化，自动避开复杂对象的哈希问题。
• 若需缓存数据库连接这类资源，用@st.cache_resource单独管理，不要让数据缓存函数持有连接实例。

示例代码：

import streamlit as st
import pandas as pd
from sqlalchemy import create_engine
from sqlalchemy.orm import Session

# 缓存数据库连接，仅初始化一次
@st.cache_resource
def get_db_session(db_url: str):
    engine = create_engine(db_url)
    return Session(engine)

# 缓存数据查询结果
@st.cache_data
def st_get_shop_ids(db_url: str) -> pd.DataFrame:
    session = get_db_session(db_url)
    query_result = session.query(Shop.id, Shop.name).all()
    return pd.DataFrame(query_result, columns=["shop_id", "shop_name"])

2. 彻底隔离SQLAlchemy操作与缓存逻辑

确保被缓存的函数只接收和返回可哈希/可序列化的简单类型（字符串、数字、DataFrame等），绝对不要让缓存函数内部直接创建或持有SQLAlchemy的Session、ORM模型实例。

比如把数据库查询逻辑单独封装，缓存函数只处理纯数据：

# 纯查询逻辑，不缓存
def fetch_shop_ids(session: Session) -> pd.DataFrame:
    result = session.query(Shop.id, Shop.name).all()
    return pd.DataFrame(result, columns=["shop_id", "shop_name"])

# 缓存数据处理逻辑，输入为字符串，输出为DataFrame
@st.cache_data
def st_get_shop_ids(db_url: str) -> pd.DataFrame:
    session = get_db_session(db_url)
    df = fetch_shop_ids(session)
    # 此处可添加数据过滤、转换等纯数据操作
    return df

3. 应急哈希处理（不推荐）

如果必须在缓存函数中使用SQLAlchemy对象，可以通过hash_funcs参数强制指定该对象的哈希方式，但这会导致缓存无法感知对象状态变化，可能返回过时数据，仅作为临时方案：

@st.cache_data(hash_funcs={Session: lambda _: "fixed_hash"})
def st_get_shop_ids(session: Session, param: str) -> pd.DataFrame:
    result = session.query(Shop.id).filter(Shop.status == param).all()
    return pd.DataFrame(result, columns=["shop_id"])

验证要点 #

• 确认缓存函数的所有输入都是简单可哈希类型，输出是标准数据结构（如DataFrame）。
• 检查函数内部是否持有SQLAlchemy的有状态对象（如Session），如果有，务必移到缓存装饰器之外管理。

内容的提问来源于stack exchange，提问作者Sanjin Juric Fot