SQLite Web: gitea.db

id

Primary key. INTEGER NOT NULL

repo_id

INTEGER

index

INTEGER

poster_id

INTEGER

original_author

TEXT

original_author_id

INTEGER

name

TEXT

content

## 自动代码审查报告

**分支**: app-260616
**提交**: `2cbeb8c33a65d65046e103dc44a6abcac4ac25c0`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 17:25:50

---

## 1. 审查摘要
- **代码质量评分**：4.5 / 10 分
- **总体评价**：该模型文件承担了极其繁重的数据查询与报表统计职责，属于典型的“上帝类（God Class）”。代码整体呈现早期 CodeIgniter 3 风格，存在大量原生 SQL 拼接、硬编码密钥、返回值类型不一致及未清理的调试代码。核心业务逻辑（如退款、报表）缺乏安全防护与边界校验，存在较高的安全与稳定性风险。
- **风险等级**：🔴 高
- **⚠️ 局限性说明**：您提供的代码在末尾 `get_goods_sales` 方法处被截断（`$privShopIds = $this->ahead_yc_merchant_user_model->get_one(['_id' => $para`），本次审查仅基于已提供部分。若截断处包含关键权限校验或 SQL 逻辑，请补充后重新评估。

---

## 2. 问题详情

| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 全局多处方法 | **SQL 注入漏洞**：`$addsql` 变量被直接拼接到 SQL 字符串中（如 `where a." . $addsql . "`）。若该参数源自前端或外部接口，攻击者可轻易闭合引号执行恶意 SQL。 | 彻底废弃字符串拼接。统一使用 CI Query Builder 的数组条件传入，或在 Model 内部构建白名单过滤逻辑。 | `// ❌ 危险 $sql = "... WHERE a." . $addsql . " ...";` `// ✅ 安全 $this->db->where($addsql_array);` |
| 🔴 严重 | `refund()` 方法 | **硬编码密钥与弱加密**：退款签名使用硬编码字符串 `'1441600902'` 等结合 `md5()` 生成。MD5 已不具备抗碰撞性，且密钥硬编码极易泄露，导致伪造退款请求。 | 将密钥迁移至 `config.php` 或环境变量。使用 `hash_hmac('sha256', ...)` 替代 `md5()`。 | `$secret = config_item('refund_sign_key');` `$data['refund_key'] = hash_hmac('sha256', $payload, $secret);` |
| 🔴 严重 | `get_consumption_trend_data` 等多处 | **动态 IN 子句注入风险**：`_shop_id in (" . $shop_ids . ")` 直接拼接逗号分隔字符串。未做类型强转与过滤，存在注入风险且无法利用索引。 | 将字符串转为整型数组，使用 `$this->db->where_in()` 安全绑定。 | `$ids = array_map('intval', explode(',', $shop_ids));` `$this->db->where_in('_shop_id', $ids);` |
| 🟠 警告 | `get_new_add_people_trend_data` | **SQL 语法错误/逻辑缺陷**：`NOT IN (select DISTINCT(_ahead_user_id))` 子查询缺失 `FROM` 表名，执行将直接报错。且 `COUNT(DISTINCT)` 在大数据量下性能极差。 | 补全子查询表名，或改用 `LEFT JOIN ... IS NULL` 优化执行计划。 | `NOT IN (SELECT _ahead_user_id FROM ahead_user WHERE 1=1)` |
| 🟠 警告 | 全局顶部 | **全局实例化反模式**：文件顶部 `$CI =& get_instance(); $CI->load->model('Simple_model');` 会在文件被 `include` 时立即执行，破坏框架生命周期，易引发内存泄漏与依赖混乱。 | 移至 `__construct()` 中，或依赖框架自动加载。 | `public function __construct() { parent::__construct(); }` |
| 🟠 警告 | 多处查询方法 | **返回值类型不一致**：部分方法返回 `json_encode()` 字符串，部分返回数组，部分返回 `false`。增加 Controller 层处理负担，易引发 `TypeError`。 | Model 层统一返回结构化数组/对象。JSON 序列化严格交由 Controller 或 API 响应层处理。 | `return ['status' => true, 'data' => $rows, 'total' => $count];` |
| 🟠 警告 | `set_select_db()` 调用 | **非标准数据库切换**：`$this->set_select_db(1/2)` 非 CI3 原生方法，疑似自定义读写分离扩展。频繁切换可能引发连接池耗尽或事务状态不一致。 | 查阅 `phpci` 官方文档确认连接池机制。若为读写分离，建议使用 `$this->load->database('read_group')` 显式指定。 | 建议封装为独立的数据源路由服务，避免在业务 Model 中硬编码切换。 |
| 🟡 建议 | 全文件 | **违反 PSR-12 与可维护性规范**：变量命名带冗余前缀（如 `$_merchant_id`）、缺乏 PHP 7+ 类型声明、大量注释掉的代码、魔法数字散落。 | 遵循 PSR-12，添加严格类型提示，清理死代码，提取业务常量。 | `public function get_order_info(int $merchantId, string $orderId = '', ...): array` |
| 🟡 建议 | `get_business` 等方法 | **重复的权限校验逻辑**：子账号门店权限校验代码在多个方法中重复出现，违反 DRY 原则。 | 提取为私有方法 `checkUserShopPermission($uid, $userType)` 或使用中间件/基类统一拦截。 | `protected function filterByUserPermission(array &$where, int $uid, int $type) { ... }` |

---

## 3. 总结与行动建议

### 🚨 优先修复的关键问题（P0/P1）
1. **立即阻断 SQL 注入路径**：全局搜索 `$addsql` 与 `" . $shop_ids . "` 的拼接点。在未完成参数化改造前，必须在入口 Controller 层对传入的 `$addsql` 进行严格的正则白名单过滤（仅允许 `字段名 = 值` 格式），或临时关闭相关报表接口。
2. **修复退款签名逻辑**：将 `refund()` 中的硬编码字符串移至 `application/config/` 或 `.env`，并将 `md5()` 升级为 `hash_hmac('sha256', ...)`。同时增加退款金额校验（如 `refund_amount <= actual_pay` 且 `refund_amount > 0`）。
3. **修正语法错误**：修复 `get_new_add_people_trend_data` 中缺失 `FROM` 的子查询，避免线上 500 错误。

### 🛠 后续重构与优化方向
1. **架构拆分（上帝类解耦）**：当前 Model 承载了订单查询、报表统计、分页计算、退款调用等 20+ 个职责。建议按业务域拆分为：
   - `OrderQueryModel`（基础查询）
   - `OrderReportModel`（数据魔方/报表聚合）
   - `OrderRefundService`（支付退款逻辑，建议移至 Service 层而非 Model）
2. **统一数据访问层规范**：
   - 废弃原生 SQL 拼接，全面拥抱 Query Builder 或 Doctrine/ORM。
   - 统一返回类型：`Model` 永远返回 `array` 或 `object`，由 `Response` 类统一处理 JSON/HTTP 状态码。
3. **性能调优**：
   - 报表类查询涉及大量 `GROUP BY`、`COUNT(DISTINCT)` 与 `SUM()`，建议在 `_timestamp`、`_merchant_id`、`_shop_id` 上建立复合索引。
   - 对于 `get_consumption_trend_data` 等高频统计接口，强烈建议引入 Redis 缓存或定时任务预计算（ClickHouse/物化视图），避免实时全表扫描拖垮主库。
4. **框架适配确认**：代码中大量使用 `$this->set_select_db()`、`$this->setTablename()` 等非标准 CI3 方法。请核对 `phpci` 框架文档，确认这些方法是否已封装连接池复用与事务管理。若为自研扩展，建议补充单元测试覆盖。

> 💡 **专家提示**：该文件历史包袱较重（注释显示最早可追溯至 2016 年）。建议采用“绞杀者模式（Strangler Fig Pattern）”逐步替换：先为新增接口编写符合现代规范的 Service/Repository，再逐步迁移旧报表逻辑，避免一次性重写引发业务中断。

---
*此 Issue 由代码审查服务自动创建*

TEXT

milestone_id

INTEGER

priority

INTEGER

is_closed

INTEGER

is_pull

INTEGER

num_comments

INTEGER

ref

TEXT

deadline_unix

INTEGER

created_unix

INTEGER

updated_unix

INTEGER

closed_unix

INTEGER

is_locked

INTEGER NOT NULL (default 0

content_version

INTEGER NOT NULL (default 0

time_estimate

INTEGER NOT NULL (default 0

Update row 432 in issue