application/*+json是否为合法HTTP Accept头？Spring客户端默认发送合规吗？

Great question—this is a super common point of confusion when dealing with HTTP media ranges and structured suffixes like +json! Let's break this down step by step:

你的观察完全正确：RFC 7231的严格定义 #

首先，你对RFC 7231第5.3.2节的理解没毛病：标准的media-range格式只允许通配符*替换整个类型或子类型，比如：

• */*：匹配所有媒体类型
• application/*：匹配所有application开头的类型
• application/json：精确匹配单一类型

按照这个严格定义，application/*+json确实应该只匹配字面意义上包含*字符的MIME类型（几乎不存在），而不是带+json后缀的类型。而且RFC 6839（定义+suffix语法的规范）也确实没提到和HTTP通配符结合的用法。

但Spring这么做是故意的：生态约定优先 #

这里的关键是：Spring的实现是遵循了HTTP生态中广泛接受的实践约定，而非严格的RFC字面定义。

Spring的意图非常明确：application/*+json是用来匹配所有application/[任意子类型]+json的媒体类型，比如：

• application/vnd.api+json（JSON API规范）
• application/hal+json（HAL格式）
• application/problem+json（RFC 7807问题详情）

这种写法已经成为了很多HTTP客户端/服务端的默认行为——大家都默认把type/*+suffix解读为“匹配该类型下所有带指定结构化后缀的子类型”，因为这在实际开发中太有用了：你不用手动列出所有基于JSON的application级媒体类型，一个通配符就能覆盖所有场景。

这不是错误，是实用的扩展 #

虽然没有专门的RFC来标准化这种写法，但它属于被广泛认可的实践扩展。Spring的RestTemplate、WebClient以及底层的MediaType匹配逻辑，都会专门处理这种格式，把它当作有效的范围匹配。

换句话说：严格按RFC字面看，它不符合定义，但在实际的HTTP生态里，它是一个约定俗成的、实用的写法，Spring只是顺应了这个约定而已。

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