CodeIgniter的MVC在中小型项目中因部署极简、学习平缓、调试直观而高频选用，但在复杂场景下因路由僵化、测试困难、扩展乏力及Model非领域模型、View无状态、Controller易臃肿等结构性短板暴露瓶颈。
要真正理解CodeIgniter框架中MVC模式为何在中小型项目中被高频选用，又为何在复杂业务场景下容易暴露瓶颈，必须穿透表层结构，直击Model、View、Controller三者在CI实际运行时的协作边界与权责摩擦点。
CI中Model层的真实角色：不是数据容器，而是轻量契约
第一步：在application/models/目录下创建PHP类文件，类名必须与文件名一致（如User_model.php中定义User_model类），且必须继承CI_Model基类。
第二步：在构造函数中调用parent::__construct()，否则CI的数据库类、辅助函数等无法自动加载——这一步漏掉会导致后续所有数据库操作静默失败，无报错提示。
第三步：Model不强制绑定单一数据库表，但CI默认约定方法命名如get_by_id()、insert_user()需手动编写SQL或使用Active Record链式调用；它不提供自动映射（如Laravel的Eloquent），也不支持关系预加载，跨表关联必须手写join()或多次查询。
CI的Model本质是“带DB连接能力的工具包”，而非领域模型。它不承载业务规则校验（如库存扣减是否超限），这些逻辑若塞进Model，会迅速让其膨胀为“胖模型”，违背CI轻量初衷。
View层的自由与陷阱：模板即前端，但无状态管理
CI的View是纯PHP文件（.php后缀），可直接嵌入HTML+PHP混写代码，无需编译或构建流程。
方法一：用$this->load->view('user/list', $data)加载，其中$data是关联数组，键名直接转为模板内变量（如$users）。
方法二：View中可调用CI内置辅助函数（如anchor()生成链接、form_open()生成表单），但【不能直接调用Model方法】——CI禁止View层越过Controller访问Model，这是硬性隔离，违反将触发PHP致命错误。
View不处理用户交互逻辑（如按钮点击后的数据提交校验），所有事件必须回传Controller；它也不维护自身状态（如分页当前页码、筛选条件），这些必须由Controller显式传入，否则刷新即丢失。
Controller的临界点：简洁起点，臃肿终点
Controller接收HTTP请求，协调Model与View，是CI中唯一允许加载多个Model、多个View、多个辅助函数的层。
① 接收参数：用$this->input->get()或$this->input->post()获取，注意CI默认不自动过滤XSS，需手动启用global_xss_filtering = TRUE或对每个输入调用htmlspecialchars()。
② 调用Model：如$this->user_model->get_active_users()，返回数组或对象，Controller负责判断结果并决定跳转或渲染。
③ 输出响应：可直接echo输出JSON，也可$this->load->view()渲染HTML；但【禁止在Controller中拼接HTML字符串返回】，这会污染职责边界，导致View层形同虚设。
当一个Controller方法超过50行、加载Model超过3个、条件分支嵌套超3层时，已进入“臃肿预警区”——CI不提供Service层或Repository抽象，此时只能靠开发者手动拆分方法或新建Controller，否则维护成本陡增。
CI-MVC的不可替代优势
部署极简：仅需Apache/Nginx + PHP环境，无Composer依赖，上传即跑；整个框架核心文件不足2MB，适合虚拟主机或资源受限的VPS。
学习曲线平缓：没有注解、没有依赖注入容器、没有服务提供者注册机制，新手三天即可上手增删改查。
调试直观：错误堆栈直接指向Controller方法或View文件行号，无中间件拦截干扰，适合快速定位问题。
CI-MVC的结构性短板
路由僵化：默认仅支持domain.com/class/method/param路径格式，RESTful风格需手动解析$_SERVER['PATH_INFO']，无法原生支持路由组、中间件、命名空间。
测试困难：Controller强耦合CI全局对象（$this->db、$this->session），单元测试必须启动完整CI环境，无法Mock核心组件，导致测试速度慢、覆盖率难提升。
扩展乏力：无事件系统、无命令总线、无队列驱动，消息通知、异步任务、审计日志等需自行封装或引入第三方库，破坏框架一致性。
