非JSON包试图使用JSON包的标签似乎表明这里缺少一个抽象，用于以一种与格式无关的方式定义序列化格式中的属性与Go结构字段之间的关系。
虽然我预计它只会限制到具有类似于JSON的信息集的格式，但也许更好的做法是暴露一个新的与格式无关的结构标签方案，然后让encoding/json支持它，而不是实际上“官方宣布”JSON包的结构标签就是与格式无关的标签？ 🤔
为了让这个替代方案更具体一些供讨论，考虑：

struct Example {
    Foo string `marshal:"foo"`
}

在上面的例子中，marshal是我为与格式无关的结构标签类型设想的名称，它在其自己的专用包中有解析该格式的解析器，然后encoding/json依赖于它。我假设它还会像json结构标签一样支持omitempty。是否还应该支持其他奇怪的选项，如string,有待商榷；我没有研究过这种需求在其他序列化格式中有多常见。(例如，在现实世界中的YAML中，标量的确切类型通常只是隐含的，而不是明确的。)
(我也可以看到仅仅把“json”作为通用格式的名字是一种不幸但务实的做法，考虑到它开辟了一个现有的道路，但对于新手来说有点令人困惑。我在想其他人的看法。我认为接受这个提案的关键在于把“json”作为官方的与格式无关的名称，用于“类似JSON”的序列化格式——无论“类似JSON”是什么意思。)

我实际上起草了一些类似的东西，但决定先提交这个作为更容易实现的目标。

请明确，本提案是关于解析标签内的 "name,flag,flag,flag" 部分。我提议公开的函数中没有特定于 json: 标签名的内容。其他包可以使用它来解析 json 标签，但它们也可以使用它来解析它们目前使用自己的解析器实现来解析的 toml 和 yaml 标签。

tagOptions 和 parseTag 非常简单，与JSON无关。如果有几个不同的包实现了相同的事情，那么这就是在标准库中提供此功能的一个论据，但我不明白为什么 encoding/json 会是合适的地方。
我们已经有了 reflect.StructTag 和 Get 以及 Lookup 方法。如果有人想要思考这可能会是什么样子，我们可以稍微扩展一下。

如果我们要暴露这些，我可能还会建议将当前实现(重复strings.Cut)与使用正则表达式进行基准测试。正则表达式可能看起来更简单，速度更快。
我想我应该实际上创建那个其他提案，因为那似乎更接近这里的反馈所建议的内容。