外键字段用db.ForeignKey('表名.字段名')指向被引用表的主键字段，如db.ForeignKey('users.id')；relationship推荐用back_populates双边定义；外键必须放在“多”的一侧模型中；SQLite需手动开启PRAGMA foreign_keys=ON，MySQL需使用InnoDB引擎。
外键字段怎么写：用 db.ForeignKey 指向谁？
外键字段本身只是数据库层面的约束，必须明确指向「另一张表的主键字段」，不是模型类名，也不是实例。常见错误是写成 db.ForeignKey('User') 或 db.ForeignKey(User)，这会直接报错：sqlalchemy.exc.ArgumentError: Could not parse table name。
正确写法是字符串形式的「表名.字段名」，比如用户表主键默认是 id，那外键就该写：db.ForeignKey('users.id')（注意表名是小写、复数，除非你显式指定了 __tablename__）。
实操建议：
- 先确认被引用模型的
__tablename__和主键字段名，别想当然用类名 - 如果用了
__tablename__ = 'user_info'，外键就得写db.ForeignKey('user_info.id') - Flask-SQLAlchemy 2.x+ 默认自动转小写和下划线，但不自动加 s，别依赖“约定”，查
Model.__table__.name最稳
db.relationship 的 backref 和 back_populates 怎么选？
反向关系不是可有可无的装饰，它决定你能不能从关联模型“走回来”。用错会导致 AttributeError: 'User' object has no attribute 'posts' 这类错误，或者修改一端不联动另一端。
backref 是快捷写法，一行顶两行，但只在单边定义；back_populates 必须双边显式配对，更清晰也更可控——尤其多人协作或模型拆分时，推荐后者。
实操建议：
- 用
back_populates：两边都写relationship，且参数值互为字符串，比如back_populates='author'对应back_populates='posts' - 避免混用：一边用
backref，另一边又手动写relationship，容易覆盖或冲突 -
lazy参数影响查询行为，'select'（默认）会额外发 SQL，'joined'会 JOIN，大列表慎用'joined'防 N+1 变 1
一对多关系中，外键放哪边？为什么不能放“多”的那边？
外键必须放在“多”的那一侧模型里。比如一个用户有多篇文章，外键 user_id 得在 Post 模型里，而不是 User。这不是风格问题，是数据库原理：外键是用来保证“多”能准确归属到“一”，反过来逻辑不通。
典型翻车现场：User 模型里加了个 post_id = db.Column(db.Integer, db.ForeignKey('posts.id'))，结果查用户时总拿到 null，或者删用户失败——因为外键建反了，约束方向错了。
实操建议：
- 先问自己：“哪个表的记录会重复出现？”重复的那个，就是“多”，外键就放它里面
- 外键字段名建议带后缀，如
user_id、category_id，别叫id或ref_id，否则后期 debug 时根本看不出指向谁 - 如果真需要“一”里存“多”的某种聚合标识（比如最新一条 post id），那是业务字段，不是外键，别混淆
迁移时外键没生效？检查 db.Table 和引擎是否支持
SQLite 默认不强制外键约束，即使你写了 db.ForeignKey，删父记录也不会报错，子记录变成“孤儿”。MySQL 如果用 MyISAM 引擎，同样无视外键。这时候 db.relationship 在 Python 层还能用，但数据库层约束形同虚设。
现象是：明明加了外键，执行 db.drop_all() + db.create_all() 后，用 sqlite3 命令行查 PRAGMA foreign_key_list(posts); 返回空。
实操建议：
- SQLite：初始化 app 后立刻执行
db.engine.execute("PRAGMA foreign_keys=ON")（注意是 execute，不是 execute_sql） - MySQL：建库/表时指定
ENGINE=InnoDB，Flask-Migrate 生成的 migration 脚本里要检查mysql_engine='InnoDB' - 别信文档说的“默认开启”，不同版本、不同连接方式表现不一，运行时验证最靠谱
