CodeIgniter易因自由度高而滋生技术债务：控制器硬编码实例化、未过滤输入直写数据库、明文配置敏感信息、用辅助函数替代可测试服务、硬引入配置、复制粘贴中间件、滞留已终止支持的3.x版本。
当你在CodeIgniter项目中反复绕过路由抽象直接拼接URL、硬编码数据库字段名、或把验证逻辑全塞进控制器里，技术债务就已悄然生成——它不报错，但每次新增功能都更慢、更易出错。
轻量框架如何反向催生技术债务
CodeIgniter的“简单”特性本身会掩盖设计缺陷。它的核心机制不强制MVC分层边界，也不内置依赖注入容器，开发者极易写出紧耦合代码。
第一步：打开任意一个Controller文件，检查是否包含 【直接new Model()而非通过服务定位器获取】 的实例化方式。
第二步：搜索关键词 $_POST 或 $_GET，确认是否存在未经过滤/校验就直接写入数据库的操作。
第三步：查看config目录下的database.php，若用户名、密码、主机地址等敏感信息以明文形式写死，且未通过环境变量隔离，这已构成基础设施债务和安全债务双重风险。
初学者友好背后的隐性代价
CodeIgniter对新手友好的本质，是把架构约束交由人来判断，而非框架来约束。这种自由度在小项目中高效，在中大型项目中迅速演变为维护噩梦。
方法一：用全局辅助函数替代可测试的服务类
例如把用户权限判断封装成is_admin()辅助函数，而不是实现PermissionService接口——这会导致单元测试无法mock依赖，形成测试债务。
方法二：跳过自动加载配置，改用require_once硬引入
当多个模块共用同一份配置时，修改一处却漏改另一处，文档债务和实现债务同步爆发。
方法三：忽略钩子（Hooks）机制，改用复制粘贴式中间件
比如在10个控制器里重复写日志记录代码，而非启用post_controller_constructor钩子——这是典型的代码重复债务，静态分析工具会标记为高重复率。
框架版本滞留加剧债务累积
CodeIgniter 3.x仍被大量旧项目使用，但官方已于2024年8月终止支持。继续运行该版本意味着：
• 安全补丁缺失 → 每次PHP升级都可能触发未知兼容性断裂
• 无法接入现代CI/CD流水线 → DevOps债务持续滚动利息
• 第三方库适配困难 → 架构债务被锁定在单体模式
执行命令php -v确认当前PHP版本，若≥8.2，则【CodeIgniter 3.1.13是最后一个兼容版本，但已无安全更新】；必须评估迁移至CodeIgniter 4或切换框架的成本。
