flask 官方更新日志页面显示，3.1.1 版本在 2025 年 5 月 13 日正式发布，其中一项关键修复是调整了开启 secret_key_fallbacks 时的签名密钥选择顺序，对应的安全公告编号为 ghsa-4grg-w6v8-c28g。这个修复直接适配了 flask 3.1 系列新增的密钥轮换功能：应用可以预先配置一组旧密钥，过渡期内旧签名依然能通过校验，大幅降低更换 secret_key 时对在线用户的影响。

来源：Flask 官方配置文档

密钥轮换看似只是个不起眼的配置细节，实际会影响会话 Cookie、所有签名数据，甚至整个 Flask 扩展生态。Flask 3.1.0 先上线了 SECRET_KEY_FALLBACKS 功能，3.1.1 紧接着就修正了签名密钥的选择逻辑，足见这个能力和框架底层的签名逻辑绑定得很深。对于用 Cookie 存会话的应用来说，密钥轮换要同时满足两个要求：新生成的数据必须用新密钥签名，旧数据在预设的过渡期内仍能正常识别，一旦密钥选择顺序出错，安全和兼容性的平衡直接就被打破了。

官方在 3.1.1 的更新说明里还提到了两个改动：修复了 cli_runner.invoke 的类型提示问题，还有现在执行 flask --help 的时候会先加载应用和所有已装插件，保证所有可用命令都能完整展示。这些改动看起来零散，其实全是冲着提升日常开发维护体验来的：密钥轮换管的是生产环境安全，CLI 帮助优化的是运维和扩展查找效率，类型提示则能让测试和编辑器的代码提示更准确。

来源：Flask 官方测试文档

已经上线的项目升级到 3.1.1 之后，记得重点检查三项内容：第一，你有没有配置过 SECRET_KEY_FALLBACKS；第二，登录态和旧 Cookie 在预设的轮换窗口期内是不是符合预期正常工作；第三，你用到的相关扩展是不是适配了新的密钥轮换策略。官方更新日志里已经明确提示过，第三方扩展需要单独做适配，别想当然觉得所有扩展都能在密钥轮换场景下无感知正常运行。

这类改动完全可以跟着常规的安全维护窗口一起做，别等真的密钥泄露、必须紧急换密钥的时候才临时抱佛脚补流程。

信息说明：本文内容全部整理自 Flask 3.1.1 官方更新日志、配置文档和测试文档；安全公告细节、扩展兼容性说明请以 Flask 官方和对应扩展项目的公示内容为准。