CodeIgniter多租户架构实现方法

CodeIgniter虽无原生多租户支持，但通过将tenant_id深度贯穿请求全生命周期——从路由层安全解析子域名或路径前缀、BaseController统一提取并注入会话、所有Model继承TenantModel自动添加租户过滤条件、重写URL生成与权限实时校验、加密密钥严格二进制配置、日志脱敏及缓存键强制租户隔离——即可构建健壮可靠的SaaS级多租户系统；任何一环疏漏（如手动拼SQL、忽略关联查询tenant_id、权限缓存在session中、缓存键无租户前缀）都可能导致数据越界、越权访问或解密失败，让隔离形同虚设。

CodeIgniter 本身不提供开箱即用的多租户支持，但完全能跑通 SaaS 场景——关键在于 tenant_id 是否真正贯穿了请求生命周期的每个环节：路由、会话、模型、日志、缓存、URL 生成。漏掉任意一环，就可能查到别人的数据或跳转到错误商户后台。

怎么让 tenant_id 从请求入口落到每个 Model 查询里

不能靠人工在每个 get() 或 where() 里补 tenant_id，必须收口到基类。CI3 和 CI4 都推荐在 BaseController 的构造函数中统一提取：

• $this->tenant_id = $this->session->userdata('tenant_id');（CI3）或 $this->tenant_id = service('session')->get('tenant_id');（CI4）
• 所有业务 Model 必须继承一个 TenantModel，其 select()、get()、update() 等方法默认自动追加 where('tenant_id', $this->tenant_id)
• 特别注意：关联查询（如 join()）不会自动带 tenant_id，必须显式写 $this->db->join('orders o', 'o.tenant_id = u.tenant_id AND o.user_id = u.id')
• 避免使用 $this->db->query() 拼接 SQL，哪怕只拼一个 WHERE —— 参数化缺失会让 tenant_id 校验形同虚设

子域名还是路径前缀？路由层怎么安全提取 tenant_id

子域名（acme.example.com）和路径前缀（/m/acme）都能用，但提取方式和风险点不同：

• 子域名需从 $_SERVER['HTTP_HOST'] 解析，再查主库映射表得到 tenant_id；必须做白名单校验，否则攻击者可伪造 evil.com.example.com 绕过匹配
• 路径前缀依赖 routes.php 中的通配符路由，例如 $route['m/(:any)/(.*)'] = 'tenant_router/$2';，然后在 tenant_router 控制器里用 $this->uri->segment(2) 取出 slug 查库
• 无论哪种方式，tenant_id 必须在进入业务逻辑前完成校验并写入 session —— 不要等到 Controller 方法里才查，否则中间件或钩子可能已执行无隔离操作
• URL 生成函数（如 site_url()）要重写，确保生成的链接仍带当前租户上下文，否则点击侧边栏菜单可能跳回默认租户

为什么权限校验不能只读 session userdata

子账号登录后，把 user_id、tenant_id、role 全塞进 session 看似方便，但会立刻引发越权问题：

• 管理员修改某员工权限后，该员工的 session 里仍是旧权限，直到过期或手动登出
• 正确做法是每次请求进 Controller 前调用实时校验函数，例如：if (!$this->auth->hasPermission('order:delete')) { throw new \CodeIgniter\Exceptions\PageNotFoundException(); }
• 这个 hasPermission() 应查 user_permissions 关联表，或 Redis 中以 "perm:{$user_id}:{$tenant_id}" 为 key 的预热集合（更新权限时同步刷新）
• 子账号的 session cookie 名必须与主账号分离，比如设为 ci_subsession，否则同域下主账号登出会导致子账号 session 被清空

加密敏感字段时 encryption_key 写错会导致解密永远为空

商户系统常需加密手机号、身份证号等字段，但 CI 的加密机制对密钥极其敏感：

• $config['encryption_key'] 必须是 32 字节二进制数据，不能是明文字符串；填 'my-secret-key' 表面不报错，实际 decrypt() 永远返回空
• 生成方式只能是：$key = bin2hex(openssl_random_pseudo_bytes(32));，然后在 config 中写 $config['encryption_key'] = hex2bin($key);
• CI4 使用 service('encrypter')->encrypt($data)，但密钥配置位置在 app/Config/Encryption.php 的 $key 属性，同样要求二进制
• 数据库字段类型必须是 TEXT 或 VARBINARY，因为加密后数据膨胀约 1.3 倍，且含不可见字符；用 VARCHAR(20) 存手机号加密结果会截断

最易被忽略的是日志和缓存——如果 log_message() 里写了未脱敏的用户数据，或 Redis 缓存键没带 tenant_id 前缀（如用 cache:orders 而不是 cache:tenant_123:orders），隔离就只是纸糊的。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。