使用自定义类型实现JSON接口解决time.Time与遗留系统格式不兼容问题

在与遗留系统集成时，time.Time在JSON序列化时默认输出RFC3339格式，这常常与外部API期望的“2006-01-02 15:04:05”格式冲突。直接使用time.Time会导致序列化结果包含T、Z和时区信息，使集成失败。

解决这一问题的直接方式是定义一个基于time.Time的类型，并让它实现json.Marshaler和json.Unmarshaler接口。通过这种方式，json包在遇到该类型时会调用自定义方法，从而固定输出和输入格式，而无需修改业务结构体中的每个字段处理逻辑。

定义类型时使用type CustomTime time.Time，这创建了一个具有相同底层表示的新类型，能够附加方法。类型转换在错误检查之后进行，确保只有当解析成功时才执行转换和赋值操作。

MarshalJSON方法负责将时间转换为目标格式。首先将CustomTime转换回time.Time以调用Format方法，得到纯字符串，然后使用json.Marshal将该字符串包装为合法的JSON字符串值。这样输出的结果是带双引号的“2006-01-02 15:04:05”，符合多数遗留API的要求。方法签名必须返回([]byte, error)，即使Format很少失败，也需要显式返回nil作为错误值。

UnmarshalJSON方法处理输入JSON。首先将输入字节 slice 通过json.Unmarshal转换为Go字符串，这一过程会处理JSON字符串的引号和转义。如果这一步出错，必须立即返回错误，不能继续执行Parse操作。接着使用time.Parse以精确布局解析字符串，同样在出错时立即返回错误。只有当解析成功后，才执行*t = CustomTime(parsed)这样的类型转换和赋值。这一顺序保证错误被正确传播，避免在无效数据上进行后续操作。

这种错误处理和类型转换的顺序是核心：在任何可能失败的操作之后，必须先检查error返回值，再决定是否进行类型转换或状态修改。如果颠倒顺序，可能会在error非nil时仍修改接收者值，导致调用方难以区分成功与失败状态。

在结构体中使用该类型时，只需将对应字段声明为CustomTime。json包通过反射检查类型是否实现了对应接口，找到方法后自动调用。这一机制让现有代码改动量最小，只需在需要固定格式的字段上替换类型。

以下是完整可直接运行的最小示例，包含序列化和反序列化测试。所有error均被显式检查和返回或打印，代码仅依赖encoding/json和time标准库（main中增加fmt用于输出结果，这是测试所需的最小补充）。

package main

import (
	"encoding/json"
	"fmt"
	"time"
)

const timeLayout = "2006-01-02 15:04:05"

type CustomTime time.Time

func (t CustomTime) MarshalJSON() ([]byte, error) {
	formatted := time.Time(t).Format(timeLayout)
	return json.Marshal(formatted)
}

func (t *CustomTime) UnmarshalJSON(data []byte) error {
	var s string
	if err := json.Unmarshal(data, &s); err != nil {
		return err
	}
	parsed, err := time.Parse(timeLayout, s)
	if err != nil {
		return err
	}
	*t = CustomTime(parsed)
	return nil
}

type Event struct {
	ID   int        `json:"id"`
	Time CustomTime `json:"time"`
}

func main() {
	// 测试序列化
	evt := Event{
		ID:   1,
		Time: CustomTime(time.Date(2026, 7, 29, 15, 4, 5, 0, time.UTC)),
	}
	b, err := json.Marshal(evt)
	if err != nil {
		fmt.Println("Marshal error:", err)
		return
	}
	fmt.Println("Marshaled JSON:", string(b))

	// 测试反序列化
	jsonStr := `{"id":2,"time":"2026-07-29 10:20:30"}`
	var evt2 Event
	err = json.Unmarshal([]byte(jsonStr), &evt2)
	if err != nil {
		fmt.Println("Unmarshal error:", err)
		return
	}
	fmt.Println("Unmarshaled ID:", evt2.ID)
	fmt.Println("Unmarshaled Time:", time.Time(evt2.Time).Format(timeLayout))
}

运行上述程序，序列化部分会输出类似{"id":1,"time":"2026-07-29 15:04:05"}的JSON，反序列化部分会正确解析字符串并输出对应时间值。注意UnmarshalJSON使用指针接收者以修改调用方值，而MarshalJSON使用值接收者即可。

在实现过程中有几个注意事项。首先，布局字符串必须精确匹配“2006-01-02 15:04:05”，任何多余或缺失的字符都会导致Parse返回错误。其次，类型转换必须放在错误检查之后，这是保证错误传播正确性的关键。如果在UnmarshalJSON中先进行Parse再检查error，可能会在错误路径上仍执行*t = ...，使接收者处于半初始化状态。

另一个常见误区是直接在结构体字段上使用string类型来存储时间，虽然能绕过格式问题，但会丢失time.Time提供的所有方法（如Add、Before、Sub），且需要在业务代码中反复手动解析，增加重复劳动。使用CustomTime则保留了time.Time的语义，只在JSON边界处进行格式转换。

当外部API要求严格的非RFC3339格式且无法修改时，这一方法适用。它将格式控制集中在类型定义处，便于多个结构体复用同一逻辑。但如果项目中所有集成均已统一使用RFC3339，或者遗留系统正逐步迁移，则继续使用标准time.Time更简洁，避免引入额外类型。

边界情况需要考虑：空JSON字段、格式不匹配的字符串、以及时区信息缺失（当前布局不含时区，Parse返回的Time使用UTC作为默认位置）。在这些场景下，error会被原样返回给调用方，由上层决定是记录日志还是拒绝请求。

通过显式处理每个error返回值，并将类型转换置于成功路径之后，代码在面对 malformed JSON 时行为明确，不会产生意外的零值或错误静默。这一模式在处理任何需要自定义序列化的场景时都值得遵循，尤其当集成边界存在格式约束时。

整个方案依赖Go类型系统允许为已知底层类型附加方法的能力，以及json包对Marshaler/Unmarshaler接口的原生支持。实际使用中，可将CustomTime和两个方法提取到单独包中，在需要固定格式的所有遗留集成点复用同一定义。

（全文约1850字）