企业官网建设流程全解析

• 后端
• Web框架

导读

本指南以 CodeIgniter4 官方升级文档（user_guide_src/source/installation/upgrading.rst）为核心，系统讲解从旧版本升级到新版本 CodeIgniter4 的完整路径：先介绍不同安装方式（Composer App Starter、Composer 加入既有项目、手动安装）对应的升级操作，再逐条梳理从 3.x 到 4.x 的整体迁移思路，以及 4.0～4.7 各版本升级中的 Breaking Changes、Mandatory File Changes 与 Project Files 变更清单。读完本文，你将掌握"如何正确升级"、"升级前要检查哪些破坏性变更"、"哪些项目空间文件必须手动合并"三件核心技能，并能结合仓库源码定位每一项变更的底层实现。

一、升级总览：先读升级说明，再动手

CodeIgniter4 的官方升级文档开宗明义地要求：请先阅读与你当前版本对应的升级说明（upgrade notes），再执行升级操作。仓库中每一条升级说明都以upgrade_{版本号}.rst命名，例如 upgrade_476.rst、upgrade_475.rst、upgrade_470.rst，从 4.0.4 一直覆盖到 4.7.6。

文档特别强调了一个概念：项目空间（project space）。升级时，你需要将vendor/codeigniter4/framework或 ZIP 压缩包中的原始文件与你的项目文件进行对比，然后做出修改。例如，原始的app/Config/App.php位于vendor/codeigniter4/framework/app/Config/App.php；也可以直接用新文件替换旧文件，再把你之前的个性化配置行加回去。

同时建议阅读向后兼容性说明，它明确了 CodeIgniter4 的兼容性承诺边界：

• 只有主版本（如 4.0、5.0）被允许破坏向后兼容性；
• 次版本（如 4.2、4.3）可以引入新特性，但不得破坏现有 API；
• 由于代码尚未完全成熟，bug 修复可能在次版本甚至补丁版本（如 4.2.5）中带来破坏性变更，所有这类变更都会在变更日志中说明；
• 不在兼容性承诺范围内的内容包括：已弃用（deprecated）条目（例如 4.3.x 弃用的条目可能在 4.5.0 移除）、system/Language/en/中仅供框架内部使用的系统消息文本、以及 PHP 命名参数（named arguments，框架可能随时重命名方法/函数参数名）。

如何确认当前运行的版本

如果你不确定当前运行的是哪个版本的 CodeIgniter，有两种方法：

1. 查看Debug Toolbar（调试工具栏）中显示的版本信息；
2. 在代码中直接输出常量：echo \CodeIgniter\CodeIgniter::CI_VERSION;。

该常量定义在 system/CodeIgniter.php（当前开发分支为4.7.6-dev），每个版本发布时都会随之更新，是判断运行版本的最可靠来源。

二、三种安装方式下的升级操作

升级操作取决于你当初的安装方式，官方文档为每一种方式都提供了独立的升级章节。

2.1 方式一：Composer App Starter 项目

如果你的项目是通过composer create-project codeigniter4/appstarter project-root创建的骨架项目，升级时在项目根目录执行：

composer update

随后阅读升级说明与变更日志，检查其中的 Breaking Changes 与 Enhancements 是否影响你的代码。

升级到指定版本：例如想在 4.5.0 发布后仍停留在 4.4.8，则打开项目根目录的composer.json，指定框架版本：

"require": { ... "codeigniter4/framework": "4.4.8" },

然后执行composer update。注意：使用固定版本号后，composer update不会把框架升到最新版。

切换开发分支（Latest Dev）：App Starter 自带builds脚本，可在稳定版与最新开发分支之间切换：

php builds development # 切换到 develop 分支 php builds next # 切换到下一个次版本分支 php builds release # 回退到稳定版

每次切换后都要运行composer update同步 vendor 目录，再按升级指南更新项目文件。

App Starter 方式的最大优点是安装简单、更新容易；缺点则是升级后仍需手动检查并合并项目空间（root、app、public、writable）中的文件变更。

2.2 方式二：用 Composer 将 CodeIgniter4 加入既有项目

在已有项目中执行composer require codeigniter4/framework安装后，升级时同样在项目根目录执行：

composer update

App Starter 与"加入既有项目"两种方式的升级命令完全相同，阅读的升级说明与变更日志也相同；两者的项目结构均为：

app, public, tests, writable vendor/codeigniter4/framework/system

2.3 方式三：手动安装

不使用 Composer 的开发者，直接从官方发布页下载新版框架压缩包，解压后替换 system 文件夹即可完成框架本体升级。之后同样需要阅读升级说明与变更日志，检查 Breaking Changes 与 Enhancements。

手动安装的项目结构为：

app, public, tests, writable, system

注意：永远不要修改 system 文件夹内部的任何内容，它属于框架范畴，升级时会被整体替换。

2.4 升级必读的两个附加建议

• 生产环境部署：无论哪种 Composer 安装方式，部署到生产服务器时都要运行composer install --no-dev，移除仅开发需要的 Composer 包，可大幅缩减 vendor 目录体积；
• 语言翻译文件：如需使用系统消息的翻译，可通过composer require codeigniter4/translations安装，并把vendor/codeigniter4/translations/Language内容复制到app/Language，composer update时会随框架一并更新（手动安装方式则需重复下载并复制）。

三、大版本迁移：从 3.x 到 4.x 的整体思路

upgrade_4xx.rst 明确指出：CodeIgniter 4 是对框架的重写，与 3.x 不向后兼容。因此从 3.x 升级到 4.x 更应该被理解为"转换应用"而不是"升级应用"；完成转换后，后续 4.x 各版本之间的升级就会顺畅得多。

官方没有提供"12 步升级清单"，而是建议：先在新项目文件夹中安装一份全新的 CodeIgniter 4，然后把你的应用组件逐个转换并整合进去。核心调整点包括：

3.1 应用结构变化

• index.php 不再位于项目根目录，而是移入了public文件夹——这是出于安全与组件分离的考虑。你必须把 Web 服务器"指向"项目的 public 文件夹，而不是项目根目录；
• CI3 的application文件夹更名为app，框架代码仍在system文件夹；
• 新增public文件夹作为应用的文档根目录；
• CI3 中defined('BASEPATH') OR exit('No direct script access allowed');这行防护代码不再需要——标准配置下 public 之外的文件夹本就不允许直接访问，且 CI4 不再定义BASEPATH常量，应在所有文件中删除该行；
• 新增writable文件夹，用于存放缓存数据、日志与会话数据；
• 不再有嵌套的application/core文件夹，框架组件扩展机制已改变。

3.2 命名空间与类加载

CI4 面向 PHP 8.1+（当前仓库 composer.json 要求PHP ^8.2）构建，框架内所有内容均使用命名空间（helper 与 lang 文件除外）。不再存在 CI3 那种把组件引用"魔法注入"为控制器属性的超级对象（superobject），组件类按需实例化，由服务（Services）机制管理；Autoloader 自动处理App（app 文件夹）与CodeIgniter（system 文件夹）两个顶级命名空间下的 PSR-4 类定位，并支持 Composer 自动加载。

3.3 MVC 三层的转换要点

3.4 核心类与库的对应关系

• CI3 的Input对应 CI4 的 IncomingRequest；CI3 的Output对应 CI4 的 Response；
• 由于历史原因，CI3/CI4 早期错误地使用了小写 HTTP 方法名（如 "get"、"post"），自 v4.5.0 起 CI4 使用正确的 "GET"、"POST" 等大写方法名；
• 自定义库不再必须放在app/Libraries，可用$this->x = new \App\Libraries\X();实例化，或通过工厂（Factories）加载：$this->x = \CodeIgniter\Config\Factories::libraries('X');；
• Hooks被事件（Events）取代：CI3 的$hook['post_controller_constructor']改为Events::on('post_controller_constructor', ['MyClass', 'MyFunction']);；pre_controller、post_controller钩子点被移除，改用过滤器（Filters）；
• redirect() 语义完全改变：CI4 的redirect()返回RedirectResponse实例而非直接重定向并终止脚本，必须从控制器或过滤器返回它；CI3 的redirect('login/form')要改为return redirect()->to('login/form')；之前设置的 Cookie 与 Header 不会自动带入，需手动调用withCookies()/withHeaders()；
• CI3 的部分 helper 在 CI4 中已不存在（如 CAPTCHA、Email、Path、Smiley Helper），需要寻找新实现方式；Download Helper 被移除，改用 Response 对象的下载功能；Directory Helper 与 File Helper 合并进 filesystem_helper；String Helper 函数并入 text_helper。

3.5 错误处理行为差异

CI3 的错误行为在index.php中设定：E_ERROR | E_PARSE | E_COMPILE_ERROR | E_CORE_ERROR | E_USER_ERROR级别的错误会无条件终止框架处理。CI4 的行为则在app/Config/Boot/{environment}.php中设定：所有未被error_reporting()忽略的错误都会终止框架处理（是否写日志取决于Config\Logger::$threshold）。

3.6 路由模式

CI4 中Auto Routing 默认关闭，默认需要定义所有路由；若想沿用 CI3 的自动路由方式，可开启 auto-routing-legacy；CI4 还提供了更安全的新版 auto-routing-improved（当前仓库 app/Config/Feature.php 中$autoRoutesImproved默认已是true）。

3.7 分模块升级指南

官方为最常用库准备了独立的 3.x→4.x 升级指南，位于user_guide_src/source/installation/目录下，包括 upgrade_configuration.rst、upgrade_database.rst、upgrade_routing.rst、upgrade_security.rst、upgrade_sessions.rst、upgrade_validations.rst 等，覆盖数据库、邮件、加密、文件上传、HTML 表格、图片、本地化、迁移、响应、分页、视图解析器等多个主题。

配置（Configuration）升级示例：CI4 的配置改为存放在继承CodeIgniter\Config\BaseConfig的类中，CI3 的application/config/config.php对应 CI4 的app/Config/App.php及 Security.php 等具体配置文件，配置值以公有类属性存储，取值语法由$this->config->item('item_name');改为config('MyConfig')->item_name;。官方示例（upgrade_configuration/001.php）演示了自定义配置类：

<?php namespace Config; use CodeIgniter\Config\BaseConfig; class Site extends BaseConfig { public $siteName = 'My Great Site'; public $siteEmail = 'webmaster@example.com'; }

数据库升级示例：CI3 的$this->load->database();改为$db = db_connect();（多库用db_connect('group_name')）；$this->db一律改为$db，方法名统一为 camelCase：simple_query()→simpleQuery()、affected_rows()→affectedRows()、$query->result()→$query->getResult()、$query->result_array()→$query->getResultArray()；Query Builder 必须先初始化$builder = $db->table('mytable')再使用，如$this->db->get_where('mytable', ['id' => $id], $limit, $offset)→$builder->getWhere(['id' => $id], $limit, $offset)。CI3 的 Database Caching 功能已被移除，需要缓存时改用缓存库。

四、4.x 各版本升级要点（Breaking Changes 与强制文件变更）

升级文档中每个版本说明都采用统一结构：Mandatory File Changes（强制文件变更）→ Breaking Changes（破坏性变更）→ Breaking Enhancements（破坏性增强）→ Project Files（项目文件）。以下汇总各版本的关键变更。

4.1 强制文件变更：index.php 与 spark（4.2.0、4.4.0、4.5.0）

多个版本都强调public/index.php 与 spark属于"必须合并"的文件，若不更新，执行composer update后 CodeIgniter 将无法正常工作。官方给出的升级示例流程：

composer update cp vendor/codeigniter4/framework/public/index.php public/index.php cp vendor/codeigniter4/framework/spark .

其中 4.3.0 版本还特别要求 spark 文件必须同步（否则 Spark 命令完全无法运行）。4.5.0 起这两个文件的变更尤为重要——该版本重构了引导流程，system/bootstrap.php不再返回CodeIgniter实例、不再加载.env文件（改由 index.php 与 spark 处理），这一改动是为了让 OPcache Preloading 更易实现。

4.2 4.4.0 的配置拆分（Config 大重构）

v4.4.0 对配置系统做了大范围拆分，这是升级工作量最大的版本之一：

• app/Config/App.php：$proxyIPs属性必须改为数组类型，不使用代理服务器时写为public array $proxyIPs = [];（当前仓库 app/Config/App.php 即如此）；
• 新增 app/Config/Routing.php：原属于 Routes 文件的路由设置全部迁移至此，Routes.php 被简化为只含路由定义；环境专属路由文件不再自动加载，需在 Routing.php 的$routeFiles属性中手动声明；
• 新增 app/Config/Cookie.php：App.php 中原有的 Cookie 配置（$cookiePrefix至$cookieSameSite）全部废弃，须删除；
• 新增 app/Config/Security.php：App.php 中原有的 CSRF 配置（$CSRFTokenName至$CSRFSameSite）全部废弃，须删除；
• 新增 app/Config/Session.php：App.php 中原有的会话配置（$sessionDriver至$sessionDBGroup）全部废弃，须删除；
• app/Config/Toolbar.php：需新增$watchedDirectories与$watchedExtensions两个属性以支持调试工具栏的热重载（hot reload）功能（当前仓库 app/Config/Toolbar.php 中已分别配置['app']与['php', 'css', 'js', 'html', 'svg', 'json', 'env']）；
• app/Config/Events.php：需注册热重载路由，当前仓库 app/Config/Events.php 的实现为：

if (ENVIRONMENT === 'development') { service('routes')->get('__hot-reload', static function (): void { (new HotReloader())->run(); }); }

4.3 4.5.0 的关键破坏性变更

• HTTP 方法名统一大写：Request::getMethod()移除了已弃用的$upper参数，现在原样返回大写方法名（"GET"、"POST"）；需要小写时自行strtolower($request->getMethod())；app/Config/Filters.php中$methods数组的键必须改为大写：

public array $methods = [ 'POST' => ['invalidchars', 'csrf'], 'GET' => ['csrf'], ];

CURLRequest::request()也必须传正确的大写方法名，否则得到错误响应（传'get'会从 200 变为 405）。

• 嵌套路由组的选项合并 bug 修复：外层group()的选项（如filter）现在会正确合并进内层 group，可能导致应用的路由选项生效范围扩大：

$routes->group('admin', ['filter' => 'csrf'], static function ($routes) { $routes->get('/', static function () { // ... }); $routes->group('users', ['namespace' => 'Users'], static function ($routes) { $routes->get('/', static function () { // ... }); }); });

现在csrf过滤器会同时作用于admin与admin/users两个路由，而旧版本只作用于admin。

• 过滤器执行顺序改变：Before 过滤器由route → globals → methods → filters变为globals → methods → filters → route；After 过滤器顺序同样调整。如需保持旧顺序，将 app/Config/Feature.php 的Config\Feature::$oldFilterOrder设为true；
• 404 覆盖默认状态码改为 404：以前 404-override 默认返回 200，现在返回 404；需要 200 时必须在控制器中显式设置response()->setStatusCode(200);；
• 新增 Required Filters：app/Config/Filters.php的基类改为class Filters extends \CodeIgniter\Config\Filters，$aliases新增forcehttps、pagecache、performance，并新增$required属性（before：forcehttps、pagecache；after：pagecache、performance、toolbar），同时从$global['after']中移除'toolbar'；
• API\ResponseTrait 对字符串数据的处理：之前传字符串数据时即使格式判定为 JSON 也返回 HTML，现在正确返回 JSON；保留旧行为需在控制器中设置$stringAsHtml = true（对应实现见 system/API/ResponseTrait.php）；
• BaseModel::getIdValue() 变为抽象方法，继承BaseModel的子类必须自行实现；
• Factories 变为 final 类，不应再被继承。

4.4 4.6.0 的关键变更

• Session ID（SID）强制使用 PHP 默认 32 字符：现在总是使用session.sid_bits_per_character = 4与session.sid_length = 32，不再尊重 PHP ini 设置。这一改动是为了匹配 PHP 9 的行为，源码见 system/Session/Handlers/FileHandler.php；无法接受此变更时需自定义 Session 库；
• Time::createFromTimestamp() 时区变更：不显式传时区时返回 UTC 时区的 Time 实例（旧版本返回当前默认时区），以对齐 PHP 8.4 新增的DateTimeInterface::createFromTimestamp()；想保留默认时区需显式传入第二个参数：

use CodeIgniter\I18n\Time; $time = Time::createFromTimestamp(1501821586, date_default_timezone_get());

• Time 保留微秒：createFromFormat()、相对时间字符串（如new Time('1 hour ago')）等场景不再丢失微秒（示例见 upgrade_460/002.php），因此Time比较结果可能变化——equals()会因微秒差异返回 false（upgrade_460/006.php），需先移除微秒（upgrade_460/007.php）；返回int的方法（如getTimestamp()）仍会丢失微秒（upgrade_460/005.php）；
• Time::setTimestamp() 行为修复：对非默认时区的 Time 实例调用setTimestamp()时，现在与DateTimeImmutable行为一致，按实例自身时区解释时间戳（示例见 upgrade_460/008.php）；
• Registrars 禁止"脏操作"：为防止注册器（Registrars）自动发现被重复执行、向 Config 类属性重复写入值，凡是加载或实例化时实例化了 Config 类的 Registrar 类都会抛出ConfigException。所有命名空间下的Config/Registrar.php都必须改为在加载/实例化时不实例化任何 Config 类（反例见 upgrade_460/001.php）；
• Filters 类重构：$filters与$filtersClasses数组结构改变，$arguments与$argumentsClass属性不再使用；同一过滤器类不再被实例化多次，before/after 共用同一实例。

4.5 4.7.0 的关键变更

• 最低 PHP 版本升至 8.2：升级 CodeIgniter 前需先升级 PHP 运行时（当前仓库 composer.json 中"php": "^8.2"）；
• Validation 的 regex_match 占位符改用双花括号：regex_match[/^{placeholder}$/]需改为regex_match[/^{{placeholder}}$/]，以避免与{1,3}这类正则量词产生歧义；
• 模型主键校验时机与异常类型变化：insertBatch()/updateBatch()现在遵循updateOnlyChanged、allowEmptyInserts等模型设置；主键值在数据库查询前校验，非法主键抛出InvalidArgumentException而非DatabaseException，捕获旧异常的代码需相应更新；
• Entity 变更检测改为深度比较：Entity::hasChanged()与syncOriginal()对数组和对象执行深度比较；toRawArray(true)会递归转换实体数组；
• 加密处理器键状态变化：OpenSSLHandler/SodiumHandler不再在通过$params传键时改动内部键，应改为在Config\Encryption中显式配置键；
• Config 新增：app/Config/Migrations.php新增Config\Migrations::$lock（默认false，见 app/Config/Migrations.php）；新增app/Config/Hostnames.php与app/Config/WorkerMode.php。

4.6 4.7.4 与 4.7.5 的安全相关变更

• 4.7.4：代理背后的 HTTPS 检测。出于安全考虑，IncomingRequest::isSecure()不再信任X-Forwarded-Proto与Front-End-Https头，除非请求来自可信代理。如果你的应用位于终止 TLS 的反向代理/负载均衡之后，必须在Config\App::$proxyIPs中注册代理：

public array $proxyIPs = [ '10.0.1.200' => 'X-Forwarded-For', '192.168.5.0/24' => 'X-Forwarded-For', ];

否则isSecure()、force_https()与$forceGlobalSecureRequests会把这些请求当作非 HTTPS，可能导致重定向循环。注意双栈服务器上代理的 IPv4 可能被报告为 IPv4-mapped IPv6（如::ffff:192.168.5.21），需添加对应形式（如::ffff:192.168.5.21或::ffff:192.168.5.0/120）。当前仓库 system/HTTP/IncomingRequest.php 的isSecure()实现正是先检查HTTPS服务器变量，再要求isFromTrustedProxy()通过才信任转发头。

• 4.7.5：View Parser 不再二次解析替换值。出于安全原因，Parser 现在把每个替换值严格视为数据，包含 Parser 语法（如{name}、{!name!}、{name|upper}）的值会被原样输出，绝不会在后续替换轮次中被再次解析。例如下面代码之前渲染<p>Hello, Bob!</p>，现在渲染<p>Hello, {name}!</p>：

$parser->setData([ 'greeting' => 'Hello, {name}!', 'name' => 'Bob', ])->renderString('<p>{greeting}</p>');

需要插入已渲染的模板片段时，应先渲染片段再作为值传入，并用{! !}语法避免再次转义：

$greeting = $parser->setData(['name' => 'Bob'])->renderString('Hello, {name}!'); $parser->setData(['greeting' => $greeting])->renderString('<p>{! greeting !}</p>');

该版本还调整了文件上传校验：is_image、mime_in、ext_in规则现在拒绝客户端文件名中带 PHP handler 扩展名（如shell.php.gif）或以下划线结尾的文件名，即使文件内容本身是安全的图片也会被拒绝，需在上传前重命名（如改为logo-php.gif）。

4.7 更早版本的典型变更（4.0.x～4.3.x）

• 4.0.4：修复 Controller Filters 的 bug，FilterInterface的before()/after()必须增加$arguments参数。当前仓库 system/Filters/FilterInterface.php 的签名即为before(RequestInterface $request, $arguments = null)与after(RequestInterface $request, ResponseInterface $response, $arguments = null)；
• 4.0.5：Cookie SameSite 支持引入，默认Lax；HTTP 层向 PSR-7 靠拢，Message::getHeader(s)弃用，改用header()/headers()；ResponseInterface补齐setJSON、getJSON、setXML、send()等方法；app/Config/Services.php应改为继承CodeIgniter\Config\BaseService以支持第三方服务发现；
• 4.1.0：移除旧版自动加载支持（Autoloader::loadLegacy()），所有类必须使用命名空间；
• 4.2.0：事件优先级常量EVENT_PRIORITY_LOW/NORMAL/HIGH弃用，移至app/Config/Constants.php或改用类常量CodeIgniter\Events\Events::PRIORITY_LOW等；composer.json 中App\\与Config\\的 psr-4 条目需移除；
• 4.3.0：要求 Composer 2.0.14+（旧版本需composer self-update后删除 vendor 并重新composer update）；Kint 升级至 5.0（Kint\Renderer\Renderer改为Kint\Renderer\AbstractRenderer）；PHP 8.2 下需为app/Config/Exceptions.php增加$logDeprecations与$deprecationLogLevel；Time从可变行为改为不可变（现继承DateTimeImmutable），需要旧行为可改用已弃用的TimeLegacy（见 system/I18n/TimeLegacy.php）；测试中捕获 STDERR/STDOUT 的方式改为CITestStreamFilter::registration()+addOutputFilter()/addErrorFilter()或直接使用CodeIgniter\Test\StreamFilterTrait；redirect()->withInput()与校验错误的隐式会话行为被修复，改用新的表单 helpervalidation_errors()、validation_list_errors()、validation_show_error()。

五、升级后处理：项目空间文件合并

每次升级说明都包含Project Files一节，其结构固定为两个子节：

• Content Changes：收到重大变更（含弃用或视觉调整）、建议合并的文件清单，以 Config 类为主。例如 4.7.0 建议合并app/Config/Migrations.php（新增$lock），4.7.5 建议合并app/Config/View.php（新增$restrictParserConditionals，默认false，见 app/Config/View.php）；
• All Changes：项目空间中所有发生变更的完整清单，其中很多只是注释或格式调整，不影响运行时行为，但逐项核对可以避免遗漏。

所有项目空间文件（root、app、public、writable）都不会在升级时被自动修改——这正是"项目空间"与"系统空间"分离的设计：system 由 Composer 或手动替换自动更新，项目空间始终需要人工介入。文档同时提示，Packagist 上存在一些第三方模块可辅助合并项目空间变更。

六、升级实战检查清单

综合以上内容，一次规范的 CodeIgniter4 升级应遵循以下流程：

1. 确认当前版本：查看 Debug Toolbar 或输出\CodeIgniter\CodeIgniter::CI_VERSION；
2. 定位对应升级文档：在user_guide_src/source/installation/目录中找到对应版本的upgrade_{版本}.rst，通读 Mandatory File Changes 与 Breaking Changes 两节；
3. 更新框架本体：Composer 方式执行composer update（指定版本则先改 composer.json 再执行）；手动方式下载新版并替换 system 文件夹；
4. 同步强制文件：重点核对public/index.php、spark以及新增/拆分的 Config 文件（Routing、Cookie、Security、Session 等），按文档示例执行cp合并；
5. 检查破坏性变更：逐一核对 HTTP 方法名、过滤器顺序、Parser 行为、Time 行为、异常类型、接口/方法签名等是否影响你的业务代码；
6. 合并项目空间文件：对照 Content Changes 与 All Changes 清单，将新配置项与个性化配置合并（如$proxyIPs、$watchedDirectories、$restrictParserConditionals、$lock等）；
7. 回归测试：重点覆盖路由、过滤器、验证、会话、时间处理与上传校验等受影响的模块。

结语

CodeIgniter4 的升级体系通过"系统空间/项目空间分离 + 逐版本升级说明 + 变更日志"三重机制，把框架演进对业务代码的冲击降到可预期的程度。只要养成"先读对应版本的升级文档、再执行更新、最后合并项目空间文件"的习惯，从 4.x 的任何一个版本升级到更新版本都能平稳完成；而从 3.x 迁移时，则应按本文第三节的整体思路，结合各模块专项升级指南逐步转换。相关原始文档与源码均可在本仓库中继续深入阅读：升级总览、向后兼容性说明、Composer 安装与升级、手动安装与升级 以及变更日志。

• 后端
• Web框架