CodeIgniter插件生态以“精而专”为特点，CI4转向PSR-4+Composer后质量提升但开箱即用插件仍少；HMVC是CI3成熟模块方案却易出错，CI4原生模块化不兼容其调用方式；Composer扩展需手动配置命名空间与服务，小而准的第三方工具更实用。

CodeIgniter 的插件生态整体偏“精而专”，不是靠数量堆砌，而是围绕核心框架轻量、松耦合的设计哲学自然生长出来的——尤其在 CI4 之后，官方明确转向 PSR-4 + Composer 原生支持，第三方扩展质量明显提升，但“开箱即用的炫酷插件”依然稀少。

HMVC 是 CI3 时代最成熟、也最容易翻车的模块化方案

HMVC（Hierarchical MVC）不是官方内置功能，而是由 wiredesignz 维护的第三方扩展，在 CI3 中几乎是大型项目模块拆分的事实标准。它允许你用 $this->load->module('auth/login') 直接调用其他模块控制器，实现跨模块逻辑复用。

• 容易踩的坑：CI3 默认不支持自动加载子模块的模型/库，需手动在 application/modules/auth/config/autoload.php 中补全配置，否则出现 Class 'Auth_model' not found
• CI4 已原生支持模块化目录结构（app/Modules/Auth），但不再兼容 HMVC 的 module() 调用方式；强行移植会破坏路由隔离和依赖注入机制
• 真实使用场景：遗留 CI3 系统升级过渡期，或需要快速切出独立后台管理模块（如 admin/ 和 api/ 分离部署）

CI4 的 Composer 生态正在补位，但文档和示例严重滞后

CI4 官方弃用传统 third_party 手动复制模式，转而推荐通过 Composer 加载扩展，

比如认证类常用 codeigniter4/authentication，邮件发送推荐 codeigniter4/email。

• 常见错误现象：执行 composer require codeigniter4/authentication 后，运行时报 Class 'CodeIgniter\Authentication\Authentication not found —— 实际是未在 app/Config/Autoload.php 中注册命名空间映射
• 参数差异：CI4 扩展大多依赖 Services 注册机制，例如启用 session 需确认 app/Config/Session.php 中 $driver 和 $savePath 正确，否则 authentication 会静默失败
• 性能影响：多数 CI4 扩展采用懒加载 + 单例模式，只要不调用就不会实例化，对冷启动无额外负担

真正好用的“小而准”工具类，往往藏在社区非热门仓库里

比起大而全的 CMS 插件，CI 开发者更依赖解决具体问题的小工具：比如处理 Excel 导入导出的 phpoffice/phpspreadsheet，或适配阿里云 OSS 的 aliyuncs/oss-sdk-php。这些不是“CI 插件”，但因框架无侵入性，接入极轻。

• 典型使用场景：上传文件后自动同步到对象存储，只需在控制器中 new 一个 OssClient 实例，不用改任何核心文件
• 兼容性注意：CI4.4+ 强制要求 PHP 8.1+，但很多老工具包（如 mpdf/mpdf 8.x）尚未完全适配，装完报 Deprecated: Return type of Mpdf\... must be compatible 是常事
• 建议做法：优先查 Packagist 上标有 codeigniter4 tag 的包，再看 GitHub 最近一次 commit 是否在 6 个月内

CI 的扩展从来不是拼数量，而是拼“是否愿意为它写三行配置、两行服务注册、一行调用”。生态不热闹，但每一块砖都贴得紧——只是你得自己判断哪块该往哪儿垒。