CodeIgniter 自定义库开发完全指南创建、替换与扩展自己的 Library【免费下载链接】CodeIgniterOpen Source PHP Framework (originally from EllisLab)项目地址: https://gitcode.com/gh_mirrors/co/CodeIgniter导读在 CodeIgniter 中“库Libraries”通常指位于system/libraries/目录下、并在用户指南 Class Reference 中描述的核心类。而本指南讲解的是另一种更常用的开发模式在application/libraries/目录中创建你自己的库把业务代码与框架全局资源清晰隔离。读完本文你将掌握三类核心技能从零编写全新库、用同名类替换原生库Native Library、用MY_前缀继承扩展原生库并理解其底层的类加载机制与get_instance()超级对象用法。三大能力总览CodeIgniter 的自定义库体系允许开发者对库资源做三种操作创建全新的库从零实现业务类放在application/libraries/下通过$this-load-library()加载扩展原生库继承CI_前缀的框架类新增或覆写方法最小改动、最大化复用框架功能替换原生库在应用目录放置与原生类完全同名的类让框架优先使用你的版本。重要限制数据库相关的类Database classes不能被替换或扩展其余所有类均可被替换/扩展。这一点在 Loader.php 的系统库加载逻辑 中也可以印证——替换与扩展机制均作用于普通库加载路径。存储位置你的库类应放在application/libraries/目录下这是 CodeIgniter 初始化库时默认查找的位置。当前仓库中该目录默认仅含 index.html防目录列举占位文件即应用层还没有任何自定义库完全由你自由添加。从源码结构看CI_Loader::_ci_load_library()通过$this-_ci_library_paths依次搜索应用路径APPPATH、包路径package paths与系统路径BASEPATH下的libraries/目录见 Loader.php因此应用层库优先于系统层库被命中。命名约定自定义库必须遵守三条硬性规则否则加载器无法识别文件名首字母大写例如Myclass.php类声明名首字母大写例如class Myclass类名与文件名必须完全一致。命名不匹配时加载器会报Unable to load the requested class: xxx错误并终止请求Loader.php 中通过show_error()抛出。类文件基本骨架一个标准库类应遵循如下原型?php defined(BASEPATH) OR exit(No direct script access allowed); class Someclass { public function some_method() { } }说明首行的defined(BASEPATH) OR exit(...)是 CodeIgniter 的标准安全护栏防止文件被浏览器直接访问这里Someclass仅为示例类名实际使用请替换为符合业务语义的名字方法可以是任意数量、任意可见性public/protected/private由你的业务需要决定。使用你的类在任意 控制器 方法中用标准加载语法初始化库$this-load-library(someclass);其中someclass是不带.php扩展名的文件名。文件名大小写均可Someclass或someclass都行CodeIgniter 不区分。加载完成后用全小写版本访问该类实例$this-someclass-some_method(); // 对象实例名始终为小写这个“实例名永远小写”的行为源于加载器实现_ci_init_library()中若未指定自定义对象名$object_name会被强制strtolower($class)Loader.php随后挂载到$CI-$object_name上。因此无论文件名大小写如何控制器里始终通过小写属性访问。初始化时动态传递参数加载库时可通过第二个参数以数组形式动态传参该数组会原样传给类的构造函数$params array(type large, color red); $this-load-library(someclass, $params);使用该特性时类构造函数必须准备好接收数据?php defined(BASEPATH) OR exit(No direct script access allowed); class Someclass { public function __construct($params) { // Do something with $params } }从配置文件读取参数你还可以把参数放进配置文件创建一个与类文件名同名的配置文件存放在application/config/目录下加载器会在实例化前自动载入其中的配置项。注意如果使用了上面介绍的动态传参方式配置文件方案将不会生效——两种传参方式是互斥的动态参数优先。底层原理参数如何被消费结合 Loader.php 的_ci_init_library()实现可以看清完整链路若未显式传参加载器会依次在_config_paths的config/目录下查找strtolower($class)..php与ucfirst(strtolower($class))..php命名的配置文件兼容大小写敏感的文件系统还会检查config/ENVIRONMENT/环境子目录下的同名配置Loader.php找到配置后配置变量被合并进$config数组最终实例化时执行new $class_name($config)Loader.php因此无论配置来自文件还是动态数组最终都以构造参数形式进入你的类。在库内部使用 CodeIgniter 资源CodeIgniter 的原生资源helper、library、config 等在控制器、模型、视图中可通过$this直接访问$this-load-helper(url); $this-load-library(session); $this-config-item(base_url); // etc.但$this只在控制器、模型、视图内部有效。在自定义类中需要通过get_instance()方法获取 CodeIgniter超级对象Super Object它返回当前运行的CI_Controller单例实例——该函数定义于 system/core/CodeIgniter.php内部直接转发CI_Controller::get_instance()。基础用法引用赋值给变量$CI get_instance();取得变量后用它替代$this访问框架资源$CI get_instance(); $CI-load-helper(url); $CI-load-library(session); $CI-config-item(base_url); // etc.为什么必须用引用赋值按引用赋值可以让你直接操作原始的 CodeIgniter 超级对象而不是复制一份副本。副本对象的状态与框架实例脱钩可能导致资源加载、配置读取等行为异常。这一点官方文档明确强调“非常重要”。最佳实践构造函数中缓存为属性库本质是类应当充分利用面向对象思想。为了在类的所有方法中都能使用超级对象推荐在构造函数中把它赋值给类属性class Example_library { protected $CI; // 属性定义处无法直接调用函数因此放在构造函数中初始化 public function __construct() { // 将 CodeIgniter 超级对象赋给类属性 $this-CI get_instance(); } public function foo() { $this-CI-load-helper(url); redirect(); } public function bar() { echo $this-CI-config-item(base_url); } }此后类内任何方法都能通过$this-CI使用任意框架组件既避免了重复获取引用又保持了 OOP 风格的整洁。用你的版本替换原生库只要让类文件与某个原生库同名CodeIgniter 就会优先使用你的版本而跳过原生实现。使用该特性时文件名与类声明必须与原生库完全一致。例如要替换原生 Email 库创建application/libraries/Email.php并声明class CI_Email { }注意大多数原生类都以CI_前缀命名如CI_Email、CI_Input、CI_Config替换时必须保留该前缀这样加载器才能匹配到CI_Email这个类名。加载方式与平时完全相同$this-load-library(email);底层替换机制从 Loader.php 的_ci_load_stock_library()实现可以看到替换原理加载器会先把 APPPATH应用目录调整到搜索路径最前面array_unshift($paths, APPPATH)遍历路径查找libraries/file_pathlibrary_name.php若在应用目录先找到同名文件则include_once()后检查CI_前缀类是否存在若存在则直接初始化该应用层类跳过BASEPATH.libraries/...的系统原生文件该文件在最后才被include_once。这保证了“应用层同名文件 → 覆盖系统层实现”的优先级顺序。再次强调Database 类目前不支持被替换。扩展原生库Sub-class如果只是想给现有库追加一两个方法整体替换属于“杀鸡用牛刀”。更优雅的做法是继承原生类。继承与替换几乎相同但有两点区别类声明必须extends 父类新类名与文件名必须带MY_前缀该前缀可配置见下文。例如扩展原生 Email 类创建application/libraries/MY_Email.php声明class MY_Email extends CI_Email { }构造函数必须调用父类构造函数如果你的子类需要构造函数务必先调用父类构造函数class MY_Email extends CI_Email { public function __construct($config array()) { parent::__construct($config); // Your own constructor code } }注意并非所有库的构造函数都接收相同或任何参数。扩展前请先查看目标库源码确认其构造函数签名再决定如何实现。例如 system/libraries/Email.php 的构造函数接收$config array()而部分库如某些无参构造的驱动类则不接收参数。加载子类加载子类时使用标准语法且不要带前缀。以上面的 Email 扩展为例$this-load-library(email);加载成功后通过被扩展类的常规变量名调用Email 场景下即$this-email-some_method();底层扩展机制_ci_load_stock_library()在包含系统原生库文件后会继续在应用路径下查找MY_library_name.php子类名拼接自config_item(subclass_prefix).$library_name见 Loader.php若找到且MY_前缀类存在则把前缀切换为MY_进行实例化最终_ci_init_library()以$prefix.$class作为类名执行newLoader.php。这就是“加载原生名、实例化子类”的完整链路。自定义子类前缀默认子类前缀是MY_可在application/config/config.php中修改$config[subclass_prefix] MY_;当前仓库的 config.php 中即保留了该默认配置项。修改后子类文件名、类名都要随之改为新前缀例如改为App_则创建App_Email.php、声明class App_Email extends CI_Email。警告所有原生 CodeIgniter 库都以CI_为前缀切勿把自己的前缀设置为CI_否则会与框架类命名空间冲突破坏加载机制。小结三种模式的选用建议模式文件/类命名适用场景加载方式新建库Someclass.php/class Someclass独立业务模块、工具类$this-load-library(someclass)替换原生库Email.php/class CI_Email需要完全重写某个原生库行为$this-load-library(email)扩展原生库MY_Email.php/class MY_Email extends CI_Email为现有库追加/覆写少量方法$this-load-library(email)搭配 CI_Loader 加载器源码 与 CodeIgniter.php 超级对象实现 一起阅读可以对 CodeIgniter 的库加载体系形成从“调用语法”到“内部机制”的完整认知。若需要更深一步了解库在框架生命周期中的定位可参考用户指南中的 控制器、模型 与 加载器文档。【免费下载链接】CodeIgniterOpen Source PHP Framework (originally from EllisLab)项目地址: https://gitcode.com/gh_mirrors/co/CodeIgniter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考