计算属性名不能替代ORM中的外键和relationship声明；必须显式定义模型关系、用预设字典控制关联加载，避免动态拼接属性名导致的silent failure。
计算属性名本身不是数据库映射的直接工具，它属于 Python 类的动态属性机制（如 __getattr__ 或 property + 字符串拼接），不能替代 ORM 中真正起作用的 外键约束 和 relationship 声明。要在 SQLAlchemy 等 ORM 中实现“动态映射多表关联”，关键不在于运行时拼属性名，而在于结构化地组织模型关系，并按需构建查询逻辑。
明确关系类型再建模，别靠属性名“猜”关联
一对多、多对一、多对多这三类关系有固定建模范式。例如用户-订单是一对多，必须在 Order 模型中定义 user_id = Column(Integer, ForeignKey('users.id'))，再用 relationship('User', back_populates='orders') 建立双向引用。硬编码字段名和关系名是必须的，计算属性名无法自动补全外键约束或触发 JOIN 行为。
- 不要写
getattr(user, f'{rel}_list')期望它返回订单 —— 这不会触发数据库查询 - 应提前定义好
user.orders，并在查询时用joinedload(User.orders)显式加载 - 若需“按字符串名获取关联”，可用
getattr(user, rel_name)，但前提是该关系已在模型中正确定义
用字典或配置驱动关联加载，而非动态生成属性
当业务需要根据参数决定加载哪些关联时（比如 API 接口支持 ?include=profile,tags），推荐用预设字典映射关系名到加载选项，而不是用 eval() 或 setattr() 动态加属性：
- 定义
INCLUDE_MAP = {'profile': joinedload(User.profile), 'tags': selectinload(Article.tags)} - 解析请求参数后，循环调用
query.options(*[INCLUDE_MAP[n] for n in includes if n in INCLUDE_MAP]) - 这样既安全又可调试，避免因字符串拼错导致 silent failure
中间表多对多场景：用 secondary + association proxy 控制访问粒度
文章与标签的多对多关系，典型做法是声明中间表 article_tag，再通过 secondary=article_tag 定义 Article.tags。若还需在关联中携带额外字段（如创建时间、权重），就得升级为关联对象模式（association object），此时可通过 association_proxy 暴露简化接口：
-
Article.tag_names可代理到[at.tag.name for at in article.tag_associations] - 这个
tag_names是计算属性，但它背后依赖的是已定义好的完整关系链，不是凭空构造 - 所有底层 JOIN、filter、order 都仍基于真实模型字段，不可被字符串替换
避免在模型层滥用 __getattr__ 模拟关系
有人试图在基类里写：
def __getattr__(self, name):
if name.endswith('_list'):
rel_name = name[:-5]
return getattr(self, rel_name) # 错误示范这看似“动态”，实则破坏了 ORM 的加载控制和类型提示，且无法配合 lazy='joined' 或 selectinload 正常工作。正确做法是：关系名写死、加载策略按需配置、序列化阶段再做字段映射（如用 Pydantic 的 computed_field 或自定义 .dict() 方法）。
