升级前必须备份information_schema.COLUMNS表结构快照、带业务主键的表数据、think_migration表；已发布迁移文件禁止修改up()，字段变更须新建迁移；生产环境迁移务必指定--env=production并校验实际表结构。
升级前必须备份的三个数据库对象
不只备份整库，ThinkPHP 升级常因模型定义变更、字段类型映射调整或迁移脚本执行顺序错乱，导致 db:seed 或 php think migrate:run 覆盖已有数据。重点备份：
- information_schema.COLUMNS 中当前表结构快照（尤其 extra 和 column_default 字段）
- 所有带业务主键的表（如 user、order），用 mysqldump --no-create-info 单独导出数据
- think_migration 表本身——它记录了已执行迁移版本，删掉或重置会触发重复执行
迁移文件里不能直接改 up() 已发布的函数体
ThinkPHP 的 think-migration 依赖版本号+时间戳识别迁移顺序。如果在已上线的 20230512102345_create_user_table.php 中直接修改 up() 里的 addColumn('status', 'tinyint') 为 addColumn('status', 'enum')，本地测试可能通过，但线上执行时会跳过该文件（因 hash 或时间戳未变），造成结构不一致。
- 已发布的迁移文件只允许新增 down() 逻辑，用于安全回滚
- 字段变更必须新建迁移文件，用 changeColumn() 或先 dropColumn() 再 addColumn()
- 若用 php think migrate:refresh 清库重跑，务必确认环境配置中 'migrate' => ['enable' => false] 在生产环境已生效，否则自动清空
模型类字段验证与数据库字段不一致的静默失败
ThinkPHP 6.1+ 默认开启模型严格模式，但若旧项目沿用 protected $autoWriteTimestamp = false 或未定义 $schema，升级后新增的 created_at 字段可能被自动填充 null，而 MySQL 8.0+ 的 strict mode 会直接报错 Field 'created_at' doesn't have a default value。
- 检查每个模型的 $schema 是否完整映射数据库字段类型（尤其是 datetime vs timestamp）
- 在迁移中显式设置默认值：用 $table->datetime('created_at')->useCurrent();，而非依赖模型自动写入
- 线上执行迁移前，在测试库运行 SHOW CREATE TABLE `user`; 对比新旧 DDL，确认 created_at 是否带 DEFAULT CURRENT_TIMESTAMP
多环境迁移命令要加 --env=production 显式指定
ThinkPHP 默认读取 .env 中的 APP_ENV，但 CLI 下执行 php think migrate:run 时，若未传参且 .env 里是 APP_ENV=local，命令会连测试库——这是最常导致线上数据被误操作的原因。
- 所有生产环境迁移必须带参数：php think migrate:run --env=production
- 在部署脚本中硬编码检查：if [ "$(cat .env | grep APP_ENV | cut -d'=' -f2)" != "production" ]; then exit 1; fi
- 不要依赖 php think migrate:status 判断是否需要执行——它只查 think_migration 表，不校验实际表结构是否匹配当前迁移文件
真正危险的不是迁移没跑完，而是你以为它跑对了。每次升级后，拿一条真实业务数据（比如某个 user_id=123 的用户），手动查新旧字段值、时间戳精度、JSON 字段解析结果，比看控制台输出的 “Migrated” 更可靠。
