XORM时间偏移源于时区链路未对齐，需统一MySQL服务端（设Asia/Shanghai）、连接串（加loc=Asia/Shanghai）、模型字段（用time.Time）及应用层（避免重复解析）。
XORM框架中时间字段写入或读取后显示与预期相差整数小时，本质是时区链路未对齐——从数据库服务端、连接参数、XORM模型定义到应用层解析，任意一环错位都会导致时间值偏移。
确认MySQL服务端实际生效时区
不要只看my.cnf配置文件里有没有default-time-zone，必须查运行时值：执行SELECT @@global.time_zone, @@session.time_zone;。
如果返回SYSTEM，说明MySQL正直接读取操作系统时区；此时若系统时区是UTC，而你的业务按东八区处理，写入2024-06-01 10:00:00，数据库内部会转成UTC存为2024-06-01 02:00:00，再读出来就永远差8小时。
验证系统当前时区：timedatectl | grep "Time zone"。若输出不是Asia/Shanghai，先执行sudo timedatectl set-timezone Asia/Shanghai，再重启MySQL使SYSTEM真正生效为+08:00。
检查XORM连接字符串是否携带时区参数
方法一：在DSN中显式声明loc=Asia/Shanghai
例如：root:pass@tcp(127.0.0.1:3306)/test?charset=utf8mb4&loc=Asia/Shanghai。这是XORM原生支持的参数，【必须加，否则XORM默认用本地Go进程时区解析time.Time】。
方法二：改用UTC+偏移量写法（仅当Asia/Shanghai不可用时备用）
loc=+08:00也可生效，但注意不能写成GMT%2B8或GMT+8，XORM不识别这类简写。
⚠️ 常见错误：只配了parseTime=True却漏掉loc——parseTime只控制是否把字符串转成time.Time，loc才决定这个time.Time对象的时区归属。
验证XORM模型字段类型与数据库列类型的匹配关系
第一步：查表结构，确认时间字段是TIMESTAMP还是DATETIME
执行SHOW CREATE TABLE your_table;，重点看字段定义。若为TIMESTAMP，MySQL会在写入时自动转UTC、读取时再转回会话时区——这和XORM的loc参数必须严格一致，否则双重转换导致偏差。
第二步：XORM模型中对应字段必须用time.Time类型，不能用string或int64手动拼接
正确示例：PublishTime time.Time `xorm:"publish_time datetime"`。错误示例：PublishTime string `xorm:"publish_time"`——后者绕过XORM时区处理，直接按字符串存，后续无法参与时区校准。
第三步：确保数据库迁移或建表时，DATETIME字段未被误设为TIMESTAMP
【关键前提：业务不依赖自动时区转换时，一律用DATETIME + loc=Asia/Shanghai组合】。因为DATETIME原样存储、原样返回，只要XORM连接指定了loc，就能保证读写全程在东八区语义下进行。
排查应用层是否重复解析时间
① 检查代码中是否对已由XORM解析好的time.Time字段再次调用.In(time.Local)或.In(time.UTC)
例如：article.PublishTime.In(time.Local).Format("2006-01-02 15:04:05")——若XORM已用loc=Asia/Shanghai加载出东八区时间，再套一层time.Local可能触发二次转换（取决于time.Local实际指向）。
② 查看Go进程启动环境变量，确认TZ未被意外覆盖
执行env | grep TZ，若输出TZ=UTC，则整个Go runtime默认时区就是UTC，会影响time.Now()等行为，间接干扰XORM字段初始化逻辑。
③ 在插入前打印原始值，在查询后立刻打印读取值，对比两者.Location().String()输出
如果插入前是Asia/Shanghai，查询后变成UTC或Local，说明XORM扫描过程丢失了时区信息——基本可锁定为DSN中loc参数未生效或拼写错误。
