当前（2019-03-22）CodeIgniter 框架的最新版本是 3.1.5，于2017年6月发布，距今快两年了也没有更新，这与 Laravel 的更新速度相比差距太大了。因为确实，它是一个很古老的框架了（第一个版本在2006年发布），当初的设计原则，开发环境与现在都已经大为不同。它有自己的设计原则，有相配套的一大堆工具、库，使用这些现有的工具就已经能很好地满足日常开发所需。
虽然已经是2019年了，但是公司用的框架是CI框架，所以我也应当快速适应CI框架的开发模式。本文就针对CI框架开发中的一些重点问题进行梳理和记录。CI框架的官网文档 很完善，但是我觉得仍然有必要整理出自己的一套实用规则。
就一个常规PHP框架来说，我认为应当包含这几个部分：
（1）index.php 或全局 App 对象，一个提供统一入口，一个提供容器资源管理
（2）路由控制
（3）请求和响应对象的封装，输入数据过滤和验证，输出数据的验证和转义，各种输入输出方法
（4）MVC 分层，控制器，模型和视图层，以及 Service 层
（5）数据库操作：数据库驱动、查询构造器、通用的查询方法
（6）文件存储、缓存管理
（7）Session, Cookie管理
（8）安全性、配置、国际化、自动加载、第三方扩展机制
（9）常见的工具类（其实应当通过扩展提供）
（10）模板语言（这个不是必要的，因为PHP本身就能输出）
入门了解框架我们下载好CI框架解压之后的初始目录是下面这样的：
application/
controller/
cache/
config/
controllers/
core/
helpers/
hooks/
language/
libraries/
logs/
models/
third_party/
views/
.htaccess
index.html
system/
core/
database/
fonts/
helpers/
language/
libraries/
index.html
.gitignore
composer.json
index.php
其中，我注意到，每个目录下面都有一个index.html文件，其内容也都是一样的：403 Forbidden。这是为了防止意外访问吗？
application/ 就是是项目目录，就是我们实际的项目代码存放处，下面分了很多子目录，看名字就知道会放哪种功能的代码，这些子目录目前除了包含一个 403 index.html 文件，没有别的内容。system/ 就是框架目录，下面就是框架代码。
根目录的 index.php 是整个项目的唯一入口点。index.php 主要的功能是定义了一些系统目录，包括项目目录、视图目录、框架目录，在最后调用了框架目录下的 core/CodeIgniter.php，这个文件是CI框架的入口点和结束点，即包含了CI框架的所有生命周期。它的执行过程如下：
* 定义全局常量，加载全局函数，环境检测，PHP版本判断
* 注册错误处理函数，自动加载函数（Composer判断）
* 加载一系列类：
* Hooks，钩子函数类
* Config，配置类
* UTF-8，
* URI，（CI_URI）
* Router，路由类
* Output，输出类
* Security，安全类
* Input，输入类
* Lang，多语言类
* 加载控制器类
* 判断控制器类、方法是否存在，不存在则404
* 调用控制器前置钩子函数
* 实例化控制器
* 调用控制器后置钩子函数
* 调用控制器方法（业务逻辑）
* 输出响应
* 调用系统后置钩子函数
在实例化控制器这一部分中，注意到它定义了一个静态实例，代码如下
# core/CodeIgniter.php
# 此处定义了一个全局函数 get_instance()，返回一个静态对象。
function &get_instance()
{
return CI_Controller::get_instance();
}
// ...
$CI = new $class();
# core/Controller.php
class CI_Controller {
public function __construct()
{
self::$instance =& $this;
// ...
}
public static function &get_instance()
{
return self::$instance;
}
}
在之后的任意位置的代码中，只要通过 get_instance() 方法就能获取唯一的 Controller 对象，它其实就是CI框架中的“容器”。
调用控制器方法（即业务逻辑）通过这段代码调用执行：
call_user_func_array(array(&$CI, $method), $params);
业务逻辑在调用上述代码之后，就进入到 application/ 目录下我们的实际的业务功能代码。上面的 &$CI 就是 $class 名对象，即根据URL参数解析对应到 application/controllers/ 目录下的实际控制器类文件名。具体的映射方法可以看文档
比如，有一个 URI 是这样的：/welcome，会解析为 application/controller/Welcome.php 文件，它应该是一个继承自 CI_Controller 的类。/welcome 相当于 /welcome/index，URI 的第一个部分是控制器，第二个部分是控制器的方法，所以这个 URI 会调用 Welcome 类的 index 方法。URI 中只有第一个部分时，那第二个部分默认是 index。在控制器方法中我们编写实际的业务功能代码。示例如下：
defined('BASEPATH') OR exit('No direct script access allowed');
class Welcome extends CI_Controller {
public function index()
{
$this->load->view('welcome_message');
}
}
加载功能模块（类库）CI框架默认提供了模型、视图、辅助函数、日志、配置、缓存等功能。这些功能模块默认是不加载的，需要在控制器中进行手动按需加载。另外，libraries 目录中的类库，也是同上的加载机制，只不过这里面的类库是开发人员自己写的功能模块。下面详细描述每种模块的加载方式。
model首先，我们看到上节中的 $this->load，这就是CI框架中的加载类（CI_Loader），我们所有需要的类库、模块都可以通过它来加载。这个加载类实际上是“容器”的一个对象属性，从下面 model 的源码可以看到，实际上所有容器的“对象属性”都可以直接通过模型获取：
class CI_Model {
public function __get($key)
{
return get_instance()->$key;
}
}
在业务功能开发中，使用最频繁的就是模型了。CI框架提供的模型类是 core/Model.php 即 CI_Model 类，它其实就是一个很简单的类，没有提供任何内容，如果你需要使用模型，那就应该在 application/models 下面新建一个继承自 CI_Model 的类，然后在使用模型的地方先使用 $this->load->model() 来加载它，加载了之后，就能直接通过 $this->{模型名} 访问该模型对象：
$this->load->model('User_model');
$result = $this->User_model->get_one($id);
model() 默认到 application/model/ 目录下寻找 user_model.php 这个文件名，然后加载 User_model 类，实例化之，并赋值作为“容器”的对象属性，属性名就是模型名。model() 方法部分源码：
public function model($model, $name = '', $db_conn = FALSE)
{
// ...
$model = new $model();
$CI->$name = $model;
}
model() 方法的第二个参数可以指定属性名，示例代码如下：
$this->load->model('User_model', 'USER');
$result = $this->USER->get_one($id);
CI框架并没有规定模型类中应当放什么，这取决于你。通常我们会写一个 Base_Model 类，用来提供各种查询方法，然后在具体的模型类中实现具体模型对应的业务方法。在控制器中直接调用模型类的业务方法获取数据。在CI框架中我们使用模型类的理由就是封装逻辑，不然所有的逻辑都写在控制器中（我看到项目中现在有一部分老代码就是这样做的！）。CI也没有提供进一步Service层，这由你自己决定。
database一般在 Base_Model 类中，我们会加载一下默认的数据库，封装若干查询方法：
class Base_Model
{
function __construct()
{
// ...
$this->load->database();
}
function save() {}
function get_one() {}
function get_all() {}
function update() {}
function delete() {}
function query() {}
...
}
调用了 database() 之后，会调用一个 DB “对象”，并赋值为控制器的 $db 属性，database() 部分源码如下：
public function database($params = '', $return = FALSE, $query_builder = NULL)
{
// ...
if ($return === TRUE)
{
return DB($params, $query_builder);
}
// ...
$CI->db =& DB($params, $query_builder);
}
可以看到，当第二个参数为 TRUE 时，直接返回 DB 对象，并不会设置为控制器的属性。这一点在具体的模型类中会有用，比如我们会在具体的模型类中加载不同的数据库类：
class Article_model extends Base_Model
{
public function __construct()
{
$this->db = $this->load->database('myDb2', TRUE);
}
}
这里获取 myDb2 数据库对象，避免了污染全局的 $CI->db 对象。
关于这个 DB 对象，我想再多讲一点，打开这个 DB 类文件，发现其实它只是一个函数，这个函数根据某些条件，动态定义了 CI_DB 类，条件满足时，CI_DB 类继承自 CI_DB_query_builder 类，条件不满足时则继承自 CI_DB_driver。
function &DB($params = '', $query_builder_override = NULL)
{
// ...
if (条件) {
class CI_DB extends CI_DB_query_builder { }
} else {
class CI_DB extends CI_DB_driver { }
}
// ...
$driver = 'CI_DB_'.$params['dbdriver'].'_driver';
$DB = new $driver($params);
// ...
$DB->initialize();
return $DB;
}
然后通过配置实例化具体的数据库驱动类，因为具体的数据库驱动类（比如：CI_DB_mysqli_driver）继承自 CI_DB，这样根据配置条件就可以控制数据库驱动类是否继承 query_builder，最终返回的是具体的数据库驱动类实例。
实际上 CI_DB_query_builder 也是继承自 CI_DB_driver 的。那什么时候不需要 query builder 呢？我猜测为了追求性能，少加载一个文件，可能会选择不加载 query builder。
// database/drivers/mysqli/mysqli_driver.php
class CI_DB_mysqli_driver extends CI_DB {
// ...
}
最复杂的部分其实已经介绍完了，下面是一些常用的类库介绍
helper在使用自定义的辅助函数之前，需要加载一下，语法同上。只不过它会去 application/helpers 目录下去寻找相应文件。
$this->load->helper('dt');
librariesapplication/libraries 目录下的类，加载语法同上，使用其实没什么问题，值得注意的是如何写一个自己的类库。
$this->load->library('t');
config配置文件也需要加载，然后 item 方法直接访问配置文件中的值，自定义的配置需要设置为 $config 数组的属性的形式。
# application/config/d.php
$config['ddd'] = '';
# Controller
$this->load->config('d');
$data = $this->config->item('ddd')
view由于现在CI项目只是作为API，所以并无视图，但为了介绍，下面提供了一个示例：
# application/views/welcome.php
# Controller
$this->load->view('welcome', $data);
这个视图文件就是一个普通的PHP文件，可以直接输出。
driver驱动其实也是类库的一种。
总结就我入手这个CI项目的一个月经验来看，日常业务开发就是这些东西，后面也不过是在这个框架基础上不断深入和完善。所以这篇文章作为入门总结应该算是足够了。