如何在Heroku部署的Flask应用中正常使用SQLite3实现动态数据更新？

问题根因拆解 #

你目前遇到的现象本质是两个平台特性叠加导致的，并非脚本本身的逻辑错误：

• Heroku 上所有 dyno 的文件系统都是相互隔离的临时磁盘空间，Web 进程和独立运行的 worker 进程属于不同的 dyno 实例，哪怕代码完全一致，两者读写的本地 SQLite 文件也是完全独立的，worker 写入本地磁盘的数据库修改，Web 进程根本访问不到。
• 你目前能展示本地推送时的数据库内容，是因为把 SQLite 文件直接打包进了代码仓库，所有运行时对数据库的修改都只存在于当前 dyno 的临时磁盘上，只要 dyno 因为24小时强制重置、实例调度、重新部署重启，所有运行时的修改就会全部丢失，自动回到仓库打包时的初始数据库状态。

适配你现有需求的落地方案 #

因为你明确说明只需要近24小时的更新数据，不需要长期持久化存储，完全不需要额外接入外部数据库，根据你现有代码的结构选对应方案即可：

• 如果愿意调整 worker 的运行方式（最小改动）
  取消独立部署的 worker 进程，改成在 Flask Web 应用内部集成轻量的进程内定时任务，让数据更新逻辑和 Web 服务运行在同一个 dyno、同一个文件系统环境里。这种架构下，定时任务对本地 SQLite 文件的所有修改，Web 进程可以直接读取，完全解决跨实例文件隔离的问题。
  调整定时任务的执行频率，保证在 dyno 24小时的强制重置周期内，至少完成1-2轮全量数据更新，刚好匹配你只需要24小时内数据的需求，不需要额外的存储成本。
• 如果必须保留独立 worker 进程的部署结构
  放弃把 SQLite 文件存在本地磁盘的逻辑：worker 每次完成数据更新后，把整份 SQLite 文件转成二进制内容，存到平台自带的、所有实例都能访问的临时共享存储区域；Web 进程启动时、以及每次请求访问数据库前，优先从这个共享存储区域拉取最新的 SQLite 内容加载到内存中完成读写，完全绕开不同 dyno 本地磁盘隔离的限制。这种方式下共享存储的临时生命周期本身就和24小时重置的节奏匹配，不需要额外做数据清理逻辑。

常见踩坑提醒 #

• 不要尝试在 worker 进程里通过 Git 命令把更新后的 SQLite 文件推送回代码仓库：Heroku 的 dyno 运行环境没有配置有效的 Git 推送身份凭证，频繁触发代码推送还会导致应用反复重新部署，形成无效循环。
• 不要为了存 SQLite 文件挂载永久持久磁盘：既然你的需求仅覆盖24小时内的临时更新数据，永久磁盘的维护成本和开销完全没有必要，反而会让数据生命周期超出你的预期。
• 注意 SQLite 的写锁冲突问题：如果定时更新任务和 Web 请求同时对同一个 SQLite 文件执行写操作，很容易触发长时间锁表导致网站超时，建议更新逻辑执行时优先用共享读锁，事务提交后立刻释放锁，避免占用过长的文件句柄。

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