不会自动沿用。在外键已启用并且实际支持该pragma的SQLite连接上，defer_foreign_keys可把约束执行延迟到最外层事务提交；事务成功提交或回滚结束后，延迟设置会关闭，下一个事务需要按需求单独安排。不能把应用启动时开过一次当成长效设置，也不能把延迟当成忽略约束。提交若因延迟约束不满足而失败，事务可能仍然打开，不能只看执行过COMMIT就认定已经进入下个事务。
适用方面，本题针对广州天河区台式电脑上运行的 SQLite 应用，属于 Windows 桌面环境；至于具体是通过命令行工具还是应用内嵌接口执行，要看现场实际情况，不能想当然地按某一种语言接口推断。动手前先核对实际库版本、编译配置以及外键启用状态，只查看已有的去敏 schema、SQL 语句和运行日志；不改生产库、不重发写入、不制造崩溃来做验证。
观察：核原应用同一连接、同一事务中的外键启用状态、defer_foreign_keys状态及事务结束记录。另开连接查询到的值不能代替原连接的配置；只看到COMMIT被调用，也不能当成提交已成功。官方外键说明中，违反延迟约束可使COMMIT失败且事务保持打开，应按真实成功提交或回滚结束来分段核对。已结束的事务曾开过延迟，不足以证明下一个事务也开启。只读原记录，不为了验证提交、回滚或改开关。
风险主要有两类。一类是把一次性设置当成长期有效，后续事务没有重新开启延迟，遇到确实依赖延迟检查的临时乱序写入的流程时，检查点提前触发，事务失败。另一类是在事务中途关闭延迟开关，想借此绕过检查；这个动作会重置内部的跟踪状态，使已经积累的待检查记录失去一致性核对，反而带来违反约束的数据风险。延迟只是把检查挪到提交时，不是取消检查。
下一步，建议先整理去敏材料：SQLite 实际版本与编译配置、外键与延迟两项状态的查询结果、涉及事务边界的关键日志片段，以及报错原文。材料齐了，再判断是代码写法问题还是配置问题。电脑快修网是信息展示与第三方维修对接平台，400-877-9605 只作咨询，实际范围和安排需确认。