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\Authenticationnot 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/mpdf8.x）尚未完全适配，装完报Deprecated: Return type of Mpdf\... must be compatible是常事 - 建议做法：优先查 Packagist 上标有
codeigniter4tag 的包，再看 GitHub 最近一次 commit 是否在 6 个月内
CI 的扩展从来不是拼数量，而是拼“是否愿意为它写三行配置、两行服务注册、一行调用”。生态不热闹，但每一块砖都贴得紧——只是你得自己判断哪块该往哪儿垒。
