CI3 不自动生效 Composer autoload 是因默认绕过 vendor/autoload.php，仅识别 application/ 下路径；需在 index.php 中 require_once FCPATH . 'vendor/autoload.php' 提前加载，并用 new 实例化带命名空间的类。
为什么 composer autoload 在 CI3 里不自动生效
CI3 默认用自己那套 application/autoload.php 和 Loader 类加载逻辑，完全绕过 Composer 的 vendor/autoload.php。你执行 require 'vendor/autoload.php' 之后，类确实能加载，但 CI3 的 $this->load->library()、$this->load->helper() 这些方法压根不认识 Composer 安装的包——它们只认 application/ 下的路径或手动注册的映射。
手动桥接：在 index.php 里提前引入 autoload.php
这是最轻量、兼容性最好的做法。不是“改框架”，而是让 Composer 的自动加载器在 CI3 框架启动前就位，后续 new 或 use 都能走 PSR-4 自动解析。
- 打开
index.php，找到require_once BASEPATH.'core/CodeIgniter.php';这一行 - 在这行之前插入：
require_once FCPATH . 'vendor/autoload.php';
- 确保
FCPATH指向 webroot（即index.php所在目录），且vendor/确实在同级目录下 - 不需要修改任何 CI3 核心文件，也不需要重写
Loader
调用 Composer 库时要注意命名空间和实例化方式
CI3 本身没命名空间概念，但 Composer 包基本都有。直接 $this->load->library('monolog/logger') 会失败——CI3 的 load->library() 不解析命名空间，也不支持斜杠路径。
- 正确做法是用
new实例化，例如：$logger = new \Monolog\Logger('name'); - 如果库依赖 CI3 的
$this（比如要访问$this->db），得手动传参，不能指望自动注入 - 避免在控制器构造函数里直接 new 大型对象（如
Doctrine\ORM\EntityManager），可能拖慢响应；考虑延迟初始化或封装成服务类 - 某些包（如
guzzlehttp/guzzle）自带工厂方法，优先用GuzzleHttp\Client::create()而非new GuzzleHttp\Client()，更易测试
常见报错和绕不过去的坑
不是所有 Composer 库都能无痛接入。有些底层强依赖现代 PHP 特性或扩展，CI3 环境稍不注意就崩。
-
Fatal error: Uncaught Error: Class 'Psr\Log\LoggerInterface' not found：说明包用了 PSR 接口但没声明psr/log为 require，手动composer require psr/log -
Call to undefined function mb_strlen()：CI3 很多辅助函数依赖mbstring，而某些 Composer 库（如symfony/polyfill-mbstring）只是模拟，需确认是否已启用扩展 - 用
doctrine/dbal替换 CI3 的 DB 类？别试。它的连接管理、查询构建和 CI3 的DB_driver完全不兼容，混用会导致事务失效或连接泄漏 - 升级 PHP 版本比硬塞新库更有效——CI3 支持到 PHP 7.4，但很多现代库最低要求 PHP 8.0+，这时再怎么桥接也白搭
真正麻烦的从来不是怎么加载，而是加载之后要不要、能不能、值不值得让 CI3 的老逻辑和新库共享状态。这点没想清楚，后面 debug 会花掉比写桥接代码多十倍的时间。
