$this->db在自定义类中报错是因为它仅在CI_Controller子类中自动注入，普通类中该属性不存在；正确方式有三：CI4用service('database')、CI3用get_instance()（慎用于CLI/监听器）、或手动构造注入$db实例。
为什么 $this->db 在自定义类里直接用会报错
因为 $this->db 是 CodeIgniter 控制器实例的属性，只在继承 CI_Controller 的类中自动注入。你在普通 PHP 类（比如 MyService、Logger 或模型外的工具类）里写 $this->db，PHP 会当成访问当前对象的 public 属性——而它根本不存在，直接 Notice 或 Fatal Error。
三种能真正拿到 $this->db 对象的方式
核心原则：必须从 CI 的服务容器或已初始化的上下文中取，不能靠“猜”或“复制粘贴控制器代码”。
-
推荐：通过
service('database')获取（CI4） —— 这是官方推荐方式，不依赖控制器上下文，只要服务容器已启动就能用：$db = service('database');注意：CI4 中service()是全局函数，无需$this。 -
兼容 CI3：用
get_instance()拿超级对象（慎用） —— 只适用于请求生命周期内（如控制器、模型中），不能在 CLI 命令或异步任务里稳定工作：$ci =& get_instance();<br>$db = $ci->db;
如果$ci->db还没加载过，得先$ci->load->database()。 -
手动传入
$db实例（最可控） —— 把数据库对象作为构造参数或方法参数传进自定义类，彻底解耦依赖：class MyService<br>{<br> protected $db;<br><br> public function __construct($db)<br> {<br> $this->db = $db;<br> }<br>}调用时：new MyService(service('database'))或new MyService($this->db)。
get_instance() 在监听器/命令行里为什么经常失效
因为 get_instance() 依赖 CI 的核心对象注册机制，而事件监听器（如 post_controller）和 CLI 命令执行时，CI 的“超级对象”可能尚未完全初始化，或已被销毁。常见现象是 Call to a member function query() on null。
- CI4 事件监听器里直接用
service('database')更可靠，它走的是独立的服务定位器； - CI3 的 CLI 脚本里，必须显式加载数据库：
$this->load->database()，且不能依赖get_instance()—— 此时$this就是 CLI 类实例，不是控制器； - 任何自定义类若需跨环境（Web/CLI/队列），优先选构造注入或
service()，别硬绑get_instance()。
自动加载配置后，为什么有些地方还是提示 $this->db 未定义
自动加载只影响控制器和模型等 CI 管理的类，对 app/Services/ 下的手动 new 出来的类、第三方库、或 helpers 里的函数完全无效。
- 检查是否误把自定义类放进了
app/Controllers/目录但没继承Controller； - 确认
autoload.php中$autoload['libraries'] = ['database']已启用，且拼写无误； - CI4 中自动加载配置已废弃，必须用
services.php注册服务或显式调用service()； - 最易忽略的一点：IDE 提示错误（如 PHPStorm）常因没识别 CI 的魔法属性，实际运行没问题 —— 别被静态分析误导。
service('database') 和构造注入能避开大部分生命周期陷阱，而 get_instance() 只适合快速原型，上线前务必评估执行上下文。 
