Go 服务在本机连数据库正常换到服务器就报错很多时候不是 ORM 写错了而是连接串、时区、字符集、初始化脚本这几处没有对齐。GoFrame 项目也一样。先别急着改 DAO先把数据库连接本身查清楚。这篇只看一个具体问题MySQL 和 PostgreSQL 在 Go 后台项目里怎么做最小排查。示例命令都可以直接复制执行输出和你环境不一样没关系关键是确认配置是否一致。1. 先把 MySQL DSN 写完整Go 的 MySQL 驱动默认行为比较保守。后台系统常见的时间字段一般是datetime、timestamp如果 DSN 里没有打开parseTime扫到time.Time时就容易出问题。一个比较稳的 MySQL DSN 可以这样写user:passwordtcp(127.0.0.1:3306)/app_db?charsetutf8mb4parseTimetruelocLocal如果服务和数据库不在同一台机器建议先不要写localhost。在 Linux 上localhost可能走 socket也可能被解析成 IPv6排查时不如直接写清楚 IP 和端口。GoFrame 的配置可以放在manifest/config/config.yaml这一类配置文件里写法通常类似database: default: link: mysql:user:passwordtcp(127.0.0.1:3306)/app_db?charsetutf8mb4parseTimetruelocLocal debug: true这里有三个点最容易漏charsetutf8mb4避免 emoji、特殊符号或部分中文数据写入异常parseTimetrue让时间字段能正确转成time.TimelocLocal或明确的时区避免本地和服务器时间差几个小时。如果你不确定服务实际读到的是哪份配置先在启动日志里打印配置路径或者临时把数据库名改成一个不存在的值看报错是否变化。这个办法很笨但能快速排除“改了 A 文件程序读的是 B 文件”的情况。2. 用数据库命令确认字符集和时区不要只看配置文件。配置写对了数据库实例本身也可能不一致。连上 MySQL 后先查这几项SHOW VARIABLES LIKE character_set%; SHOW VARIABLES LIKE collation%; SELECT NOW(), global.time_zone, session.time_zone;期望看到的结果通常是库、连接、客户端都在utf8mb4附近排序规则用utf8mb4_0900_ai_ci或utf8mb4_general_ci这类值都可以关键是别混成latin1。如果已有库不是utf8mb4先看库级设置SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME app_db;新建库时可以直接写清楚CREATE DATABASE app_db DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_0900_ai_ci;线上库不要看到字符集不一致就立刻ALTER。先导出备份再确认表、字段、索引长度和历史数据。排查文章可以写命令生产环境要慢一点。3. 初始化脚本失败先分清“连接失败”和“SQL 失败”后台管理系统经常会带一份初始化 SQL。比如有的项目会同时提供mysql_install.sql和pgsql_install.sql方便 MySQL 和 PostgreSQL 两种环境初始化。看到这种文件结构时可以顺手检查数据库脚本是否按目标数据库拆开维护。连接失败和 SQL 失败的处理方式不一样。建议先手动执行最小连接命令mysql -h 127.0.0.1 -P 3306 -u user -p app_db -e SELECT NOW();如果这一步失败先查账号、密码、端口、防火墙、授权范围。常见授权问题可以用下面的 SQL 看SELECT user, host FROM mysql.user WHERE user user; SHOW GRANTS FOR user%;如果最小连接没问题再执行初始化脚本mysql -h 127.0.0.1 -P 3306 -u user -p app_db mysql_install.sql这一步才报错通常就是 SQL 方言、表已存在、字段类型或排序规则问题。把报错行号和对应 SQL 贴出来看比只说“初始化失败”要有效得多。4. PostgreSQL 重点看 search_path 和时区PostgreSQL 的坑不太一样。MySQL 里大家习惯把库名写在 DSN 里PostgreSQL 还要注意 schema。一个常见连接串是postgres://user:password127.0.0.1:5432/app_db?sslmodedisableTimeZoneAsia/Shanghai连上之后先查三件事SELECT NOW(); SELECT current_setting(TimeZone); SHOW search_path;如果初始化脚本建表在public但程序查询时用了别的 schema就会出现“表明明存在程序却说 relation does not exist”。排查时可以直接指定SET search_path TO public; SELECT * FROM public.sys_user LIMIT 1;如果项目配置里支持 schema建议显式写清楚。没有特殊隔离需求时先用public跑通再考虑多 schema。PostgreSQL 初始化脚本也不要和 MySQL 脚本混用。AUTO_INCREMENT、反引号、部分时间函数、布尔类型写法都可能不兼容。双数据库项目最稳的方式是两份脚本分别维护而不是靠一份 SQL 到处跑。5. Go 代码里做一次最小验证配置和数据库都看过之后可以写一个很小的启动检查。不要一上来跑完整业务链路先确认能 ping、能查时间、能读一张基础表。package main import ( context time github.com/gogf/gf/v2/frame/g ) func main() { ctx, cancel : context.WithTimeout(context.Background(), 3*time.Second) defer cancel() v, err : g.DB().GetValue(ctx, SELECT NOW()) if err ! nil { panic(err) } g.Log().Info(ctx, database time:, v.String()) }这个检查有两个好处一是能确认 GoFrame 读到的就是当前配置二是能把连接、认证、SQL 执行拆开看。连SELECT NOW()都过不了就没必要继续查业务表。如果你的项目使用多数据源也可以把default换成指定分组v, err : g.DB(default).GetValue(ctx, SELECT NOW())6. 一张排查表按顺序看现象优先检查常见原因本地正常服务器连接失败host、port、账号授权配置文件没读到、数据库只监听本地、用户 host 不匹配时间字段扫描报错DSN 的 parseTimeMySQL 时间字段没有转成 time.Time中文或 emoji 写入异常charset、库表字符集DSN 和数据库字符集不一致时间差 8 小时DSN loc、数据库时区本地和服务器时区不同PostgreSQL 表不存在search_path、schema表在 public查询走了别的 schema初始化脚本执行失败SQL 方言和报错行号MySQL/PostgreSQL 脚本混用或表已存在7. 最后再回到项目配置等数据库能独立连通再回到项目配置。GoFrame 后台项目一般要确认这几项database: default: link: mysql:user:passwordtcp(127.0.0.1:3306)/app_db?charsetutf8mb4parseTimetruelocLocal debug: true maxIdle: 10 maxOpen: 100 maxLifetime: 30s开发环境可以打开 SQL debug生产环境要按日志量决定是否关闭。连接池参数不要照抄先用默认值跑通再结合数据库连接数上限调整。如果需要找一个真实的 GoFrame Vue3 后台项目对照目录和初始化脚本可以看 XYGo AdminGitHub - z312193608/xygo-admin: Open-source admin framework built with GoFrame v2 and Vue 3, featuring RBAC, full-stack CRUD code generation, MySQL/PostgreSQL, plugins, and single-binary deployment. · GitHub重点不是照搬配置而是看它把manifest/config、mysql_install.sql、pgsql_install.sql这些东西分开维护。数据库问题排查到最后往往不是某一行代码神秘失效而是配置、实例、脚本三者没有对齐。我的建议是保存一份最小排查命令清单。下次遇到“本地正常服务器不行”先跑SELECT NOW()、字符集、时区、search_path再看业务代码。这样能少绕很多弯路。
