根据fastapi官方发布日志，0.132.0版本在2026年2月23日正式推送，这次更新把json请求的strict_content_type检查划入了破坏性变更范围。官方说明里标注，现在fastapi默认会校验json请求是否携带合法的content-type头，比如application/json，不符合要求的请求会直接被拦截。如果你的客户端实在没法发送符合规范的请求头，可以手动配置strict_content_type=false关闭这个校验逻辑。
来源：FastAPI 官方 Strict Content-Type 文档
官方Strict Content-Type文档进一步解释了这个默认改动的安全背景：很多本地或者内网应用默认信任内部网络访问，浏览器在请求不带特定Content-Type头的情况下，可能不会触发CORS预检机制。恶意网站就能构造看起来完全合规的请求，往本地部署的API接口发送恶意JSON内容。FastAPI 0.132.0把合法JSON Content-Type设为强制默认要求，就是为了降低这类场景下的CSRF攻击风险。
这个改动之所以属于破坏性变更，是因为不少旧客户端、脚本或者代理，之前发送JSON请求体的时候根本没有正确设置对应的请求头。升级版本之后，这些之前能正常解析的请求会直接被拒绝。API服务维护者最好别一上来就关闭严格检查，先逐个排查所有调用端能不能补上Content-Type: application/json头，只有在确实有明确兼容需求的场景下，再考虑配置strict_content_type=False。
来源：FastAPI 官方 Release Notes
尤其是部署在内网的企业内部工具、本地AI Agent这类应用，一定要注意这个默认规则收紧的变化。官方文档明确把风险场景锁定在localhost或者内网环境，不是只针对公网API做的限制。升级前的测试要覆盖全场景：浏览器端的fetch请求、移动端客户端、命令行脚本、旧版SDK、反向代理转发后的请求头，避免上线之后批量出现415报错、请求体解析失败的问题。
如果实在必须兼容旧客户端，建议只在明确的应用实例或者限定的迁移窗口期内关闭严格检查，还要同步记录下调整原因，别把临时兼容方案拖成长期默认配置。
信源说明：本文依据FastAPI 0.132.0官方发布日志和Strict Content-Type Checking官方文档撰写，是否关闭严格检查请以自身安全评估和客户端实际兼容情况为准。
