codeigniter升级是分层验证与渐进适配过程，需遵循“先稳运行、再改逻辑、最后试新特性”原则，重点关注php版本门槛、配置迁移及隐性行为变更，并依版本跨度采取不同策略：2.2→3.0为架构跃迁，3.x→4.x本质重写，4.x小版本升级须核查变更日志，4.5.0+要求php 8.1以上且移除废弃功能。
CodeIgniter 升级不是简单替换文件，而是分层验证和渐进适配的过程。核心原则是：先稳运行、再改逻辑、最后试新特性。尤其要注意 PHP 版本门槛、配置迁移路径、以及那些“没报错但行为已变”的隐性变更。
明确升级路径与前提条件
不同版本跨度对应不同策略：
- CI 2.2 → 3.0：属于架构级跃迁，必须重命名控制器/模型文件（首字母大写）、切换数据库驱动（mysql → mysqli）、调整 session 方法参数格式、更新路由通配符规则（(:any) 不再匹配斜杠）；
- CI 3.x → 4.x：本质是重写，需重构目录结构（app/ 替代 application/）、改用命名空间、重写数据库连接配置、迁移路由到 app/Config/Routing.php；
- CI 4.x 小版本升级（如 4.3.7 → 4.4.3）：重点检查变更日志中的不兼容项，比如 public/index.php 和 spark 文件是否需更新、base_url() 在 CLI 下的行为修复、自动路由默认回退逻辑变化；
- CI 4.5.0 及以上：最低要求 PHP 8.1（4.7.0 要求 PHP 8.2），废弃功能已移除，Model::$updateOnlyChanged 等新属性需显式设置，否则批量更新可能失败；
处理二次开发带来的冲突
如果你改过 system/ 目录下的代码，升级时不能直接覆盖：
- 备份你修改过的 system/ 文件（如数据库连接类、Router 类）；
- 用新版完整替换 system/；
- 用文件夹对比工具（VS Code “比较文件夹”、Beyond Compare）找出差异，只把真正必要的补丁（比如特定错误兜底、字段兼容处理）迁移到新版本对应位置；
- 优先把定制逻辑移到 app/ 下：自定义库放 app/Libraries/，配置覆盖写在 app/Config/，视图替换放在 app/Views/，避免污染核心；
重点关注行为变更而非仅语法
很多问题不报错，但结果不对：
-
验证规则：4.7.0 中 regex_match 占位符从
{x}改为{{x}}，否则正则解析会出错； - 实体变更检测：从浅比较升级为深度规范化比较，嵌套对象、日期、枚举内部改动也会被识别为“已修改”，影响 save() 或脏检查逻辑；
-
主键校验：数据库查询前对主键值做更严格校验，非法值抛出的异常类型和时机不同，旧版用
try/catch Exception捕获的代码可能漏掉新异常； - 批量操作：insertBatch() 和 updateBatch() 现在尊重 Model 的 allowEmptyInserts 和 updateOnlyChanged 设置，行为和以前不一致；
Worker Mode 要单独评估
4.7.0 新增的 FrankenPHP Worker Mode 是实验性功能，不能和框架升级混在一起上：
- 先完成常规升级（PHP 8.2 + 框架代码 + 配置适配），确保应用在传统 FPM 模式下稳定运行；
- 再用 php spark worker:install 生成基础配置，手动核对端口、环境变量、日志路径、健康检查规则是否匹配现有部署；
- 重点验证常驻进程下的状态残留：静态属性、单例服务、未关闭的数据库连接、请求结束未清理的临时资源；
- 务必在压测或灰度环境验证，别信理论性能数字——真实负载下内存泄漏或连接耗尽更常见；
