tmp结构重复了FieldDefinition，这是次要的，我可以忍受。
您不需要这样做。您可以在FieldDefinition上创建另一个类型，新类型将不具有UnmarshalJSON方法，例如：

func (f *FieldDefinition) UnmarshalJSON(b []byte) error {
    type newType FieldDefinition

    var target newType
    target.Aspects = make(map[string]string) // ensures map always non-nil
    err := json.Unmarshal(b, &target)
    if err != nil {
        return err
    }

    // TODO: handle map merge if f.Aspects is already populated
    *f = (FieldDefinition)(target)

    return nil
}

关于FieldDefinition.UnmarshalJSON暴露在嵌入它的结构体中的另一个问题，不幸的是，如果从标准库中使用encoding/json是一个要求，那么没有一个好的方法来解决这个问题。如果将它作为一个命名字段，而不是嵌入一个选项，那么这将不再是一个问题。
但是我不认为您需要定制的UnmarshalJSON来确保map在开始时总是非空的。
如果AspectsMap对它的使用者来说是只读的，那么go对nilMap的处理应该已经很好地适用于这个用例了，因为从nilMap中阅读一个键并不会出现异常--它只会表现得好像这个键不存在一样：

package main

import "fmt"

func main() {
    var m map[string]string = nil
    value, exists := m["foo"]
    fmt.Println("value", value)
    fmt.Println("exists", exists)
    // prints
    // value 
    // exists false
}

此外，如果使用者需要消除是否设置了AspectsMap的歧义，他们现在可以检查该struct字段是否为nil。
所以这是假设AspectsMap是只读的。
如果消费者在JSON解码后还要更新AspectsMap，那么您可以1）期望消费者负责检查nil并在需要时示例化Map，或者2）提供一个helper方法，例如FieldDefinition.SetAspectField(string, string)，它可以为消费者处理Map的示例化。
编辑：提到如果AspectMap已经非空，则在FieldDefinition.UnmarshalJSON中处理Map合并