必须执行全量备份再升级，否则风险极高；备份需含时间戳和版本号、异地存储并验证可用性；TP7配置更严格，需显式设置PDO参数、校验表名与引擎、清理缓存并禁用OPcache。
升级前必须执行的数据库全量备份操作
不备份就升级，等于在生产环境玩俄罗斯轮盘。ThinkPHP版本升级本身不改数据结构，但迁移脚本、模型变更或自动迁移工具可能触发意外写操作，尤其是 php think migrate:run 或 php think schema:install 类命令。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 用
mysqldump导出时加--single-transaction --routines --triggers，避免锁表且保留存储过程和触发器（即使当前没用，第三方插件可能依赖） - 备份文件名必须含时间戳和TP版本号，例如
backup_20240521_tp6.3.0_to_tp7.0.sql，别用latest.sql这种会覆盖的命名 - 别只存本地：备份后立刻
scp到另一台机器，或上传至对象存储（如ossutil cp），本地磁盘故障是备份失效最常见原因 - 验证备份可用性：随机选一个备份，在测试库执行
mysql -u root -p test_db ，再查几条关键业务数据是否完整
config/database.php 中连接参数的兼容性检查
TP6 升 TP7 时，database.php 里 'deploy' => 1 的读写分离配置在 TP7.0+ 默认被禁用，且 'type' => 'mysql' 不再自动加载 PDO::ATTR_EMULATE_PREPARES，容易导致批量插入丢失精度或报错 SQLSTATE[HY000]: General error: 1366 Incorrect integer value。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 确认
'hostname'和'database'是字符串，TP7 对空值更敏感，null或未定义会直接抛InvalidArgumentException - 显式设置
'params' => [PDO::ATTR_EMULATE_PREPARES => false]，尤其当字段含TINYINT(1)存布尔逻辑时，否则 TP7 的 QueryBuilder 可能把0/1当字符串处理 - 如果用了 Redis 缓存连接池，检查
cache.redis.host是否仍指向旧配置——TP7 默认启用redis://协议解析，127.0.0.1:6379写法可能失败
模型类中 $table 属性与迁移脚本的双向校验
升级后首次运行 php think migrate:status 报 Table not found，大概率不是表真丢了，而是模型里硬编码的 $table = 'user_info' 和实际迁移生成的表名不一致，或者迁移文件中 up() 方法建表语句漏了 ENGINE=InnoDB 导致 TP7 的 Schema 检测失败。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 全局搜索所有模型里的
$table，对比database/migrations/下最新迁移文件中的Schema::create('xxx', ...)，确保大小写、下划线风格完全一致（Linux 环境区分大小写） - 迁移文件中建表必须显式指定引擎：
$table->engine = 'InnoDB';，TP7 的Schema类默认不再 fallback 到 MyISAM - 如果用过
php think make:model生成模型，检查生成的protected $connection = 'mysql';是否还指向已删除的连接配置名
升级后首次请求的缓存击穿防护
TP7 默认启用 think-swoole 兼容模式，但若项目没装 swoole 扩展，框架会退回到 FPM 模式，此时 Cache::store('redis')->get() 可能因连接复用问题返回旧缓存，表现为用户登录态错乱或配置未更新。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 升级后第一件事：清空全部缓存，执行
php think cache:clear，别信“缓存有 TTL 自会过期”——TP6 的File驱动缓存文件权限可能让 TP7 无法覆盖 - 检查
config/cache.php中'default' => 'redis'对应的stores.redis.handler是否为RedisHandler::class，TP7 移除了RedisCache别名，写错直接报Class not found - 在入口文件
public/index.php顶部加一行ini_set('opcache.enable', '0');，防止 OPcache 缓存旧的配置文件字节码（尤其 Docker 多层构建时易踩）
真正麻烦的不是备份动作本身，而是备份后没人验证、迁移后没人盯日志、缓存清完没人试登录——这些环节一漏，问题一定出现在凌晨三点的报警电话里。
