似乎有足够的变化，人们走出自己的方式，允许从所有约定转换到其他:http://www.cowtowncoder.com/blog/archives/cat_json.html

值得注意的是，上面提到的Jackson JSON解析器更倾向于bean_naming。

似乎有足够的变化，人们走出自己的方式，允许从所有约定转换到其他:http://www.cowtowncoder.com/blog/archives/cat_json.html

值得注意的是，上面提到的Jackson JSON解析器更倾向于bean_naming。

没有单一的标准，但我见过你提到的3种风格(“Pascal/Microsoft”，“Java”(camelCase)和“C”(下划线，snake_case))——以及至少一种，像长名称一样的串式大小写)。

这似乎主要取决于相关服务的开发人员的背景;那些有c/c++背景的人(或采用类似命名的语言，包括许多脚本语言，ruby等)通常选择下划线变体;和rest相似(Java vs . net)。例如，上面提到的Jackson库采用了Java bean命名约定(camelCase)

更新:我对“标准”的定义是一个单一的约定。因此，虽然有人可能会说“是的，有很多标准”，但对我来说，有多个命名约定，没有一个是“整体”标准。其中一个可以被认为是特定平台的标准，但考虑到JSON用于平台之间的互操作性，这可能有意义，也可能没有多大意义。

在本文档谷歌JSON风格指南(在谷歌构建JSON api的建议)中，

它建议:

属性名必须是驼峰大小写，ASCII字符串。 第一个字符必须是字母、下划线(_)或美元符号($)。

例子:

{
  "thisPropertyIsAnIdentifier": "identifier value"
}

我的团队在构建REST api时始终遵循这个约定。原因如下:

首先，JSON约定应该独立于编程语言，因为我们希望api保持一致，不管有些api是使用camelCase语言(如Java)实现的，有些api是使用snake_case语言(如Python)实现的。 此外，我们的大多数客户都是web应用程序，所以camelCase是首选 如果客户端更喜欢snake_case，它仍然可以轻松地在snake_case和camelCase之间转换数据(借助库)

但是我同意如果所有的应用程序都使用相同类型的语言(例如snake_case)，那么JSON约定也应该遵循。

正如其他人所说，没有标准，所以你应该自己选择一个。这样做的时候需要考虑以下几点:

如果您使用JavaScript来使用JSON，那么使用相同的命名约定将提供视觉一致性，并可能有一些机会更清晰地重用代码。 避免串式大小写的一个小原因是，连字符可能在视觉上与出现在值中的-字符冲突。 ｛ “银行存款余额:-10 ｝

我认为JSON没有官方的命名约定，但是您可以跟随一些行业领导者来了解它是如何工作的。

谷歌是世界上最大的IT公司之一，它有一个JSON风格指南:https://google.github.io/styleguide/jsoncstyleguide.xml

利用这一点，你可以在这里找到谷歌定义的其他风格指南:https://github.com/google/styleguide