Go time.Time.In 将同一时刻转换为指定时区的实现方式

Go 中把 UTC 时间显示成用户所在时区，核心调用是 t.In(loc)。它返回一个带有新 Location 的 Time 副本，代表的实际时间点不变，只改变墙上时钟的解释方式；随后再调用 Format 输出给用户。不要把它和“解析没有时区的文本”混在一起。

官方文档地址：https://pkg.go.dev/time#Time.In

time.Time.In 改变的是 Location，不是时间点

time.Time 同时携带墙上时间、时区信息和可能存在的单调时钟读数。In 不会把时间戳简单加上八小时，而是用目标 Location 重新解释同一瞬间。例如 UTC 的 12:00 转到上海是 20:00，转到纽约可能是 07:00；三个值的瞬间仍然相同。

这也是为什么比较两个时区的时间时通常使用 t.Equal(u)，而不是直接用 ==。后者还会比较 Location 和单调时钟读数，显示形式不同不代表时间点不同。

加载目标时区后完成显示转换

真实地区应使用 IANA 时区名称，让夏令时等历史规则由 Location 处理；只有业务明确要求固定偏移时才构造 FixedZone。

package main

import (
    "fmt"
    "time"
)

func main() {
    // 用 UTC 构造一个可复现的实际时间点。
    source := time.Date(2026, 11, 12, 12, 0, 0, 0, time.UTC)

    // 地区时区包含随日期变化的偏移规则，加载失败必须向上返回。
    loc, err := time.LoadLocation("Asia/Shanghai")
    if err != nil {
        fmt.Println("load location:", err)
        return
    }

    // In 只替换展示用 Location，不改 source 所代表的瞬间。
    display := source.In(loc)
    fmt.Println("UTC:", source.Format(time.RFC3339))
    fmt.Println("local:", display.Format(time.RFC3339))
    fmt.Println("same instant:", source.Equal(display))
}

示例输出的小时数会从 12 变为 20，但 same instant 仍为 true。容器或精简系统可能没有完整时区数据库，LoadLocation 的错误不能被忽略；需要时可在构建中引入 time/tzdata，再按部署策略决定是否启用。

In 与 ParseInLocation 的输入职责不同

已经得到一个明确时间点时，用 In 做展示转换；手里只有“2026-11-12 20:00:00”这类没有偏移的文本时，必须先决定它属于哪个地点，再用 ParseInLocation 解析。解析和显示是两个方向，不能用 In 把一段字符串“解释成”某地时间。

生产代码里的四个边界

第一，传入 nil Location 会触发 panic，目标地点来自配置时要先检查加载错误。第二，FixedZone 只表达固定偏移，不等于某个真实城市的完整历史规则。第三，数据库和接口通常保存 UTC 或带偏移的 RFC3339，渲染页面时再 In；不要把展示文本重新保存成新的事实。第四，序列化时间会保留偏移但不保留 Location 名称，若业务依赖地区名，应单独保存地区标识。

常见问题

调用 In 后 Unix 时间戳会变化吗？

不会。Unix、UnixMilli 等结果取决于实际时间点，与 Location 无关。

为什么 Format 后只变了小时？

Format 按转换后的 Location 渲染墙上时间；日期、偏移和夏令时边界也可能随目标地点一起变化。

固定 UTC+8 能否代替 Asia/Shanghai？

只在业务明确只关心固定偏移时可以。需要地区规则、历史时间或跨地区排程时，应使用 IANA Location。