|
461
|
22
|
53
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 1
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `31456ab28 ## 自动代码审查报告
**分支**: app-260519
**提交**: `31456ab2853fc7a9a5abd0f0496e6cb8f06c4ee4`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 13:46:58
---
## 1. 审查摘要
- **代码质量评分**：5/10 分
- **总体评价**：代码实现了门店包厢时间预订的核心业务逻辑，功能完整但架构耦合度较高。时间计算、JSON 序列化与数据库交互混杂在单一 Model 中，违反单一职责原则。存在明显的框架误用、潜在的性能瓶颈及容错缺失，在并发或数据异常场景下易引发系统级问题。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 文件顶部 / 全局 | `$CI = &get_instance();` 在类外部直接调用，严重违反框架生命周期。在 CLI 环境、单元测试或异步任务中会直接抛出 `Fatal Error`，且造成全局状态污染。 | 移除文件顶部的 `$CI` 引用。依赖注入或模型加载应在类构造函数中完成，或交由框架自动加载器管理。 | `public function __construct() { parent::__construct(); $this->load->model('Simple_model'); }` |
| 🔴 严重 | `_update_un_book_time` / `update_day_book_info` | `json_decode($data['_time_info'], true)` 未做异常容错。若数据库字段被意外修改或存储非法 JSON，将返回 `null`，后续数组操作会触发 `Warning/Fatal Error` 导致流程中断。 | 增加 JSON 解析校验与降级策略，确保始终返回结构化数组。 | `$decoded = json_decode($data['_time_info'], true);<br>$time_info = is_array($decoded) ? $decoded : ['room_book_time' => [], 'un_book_time' => []];` |
| 🟠 警告 | `_update_un_book_time` / `get_shop_book_info` | 方法内部频繁调用 `$this->load->model()`。每次执行都会重新实例化模型类，造成不必要的内存分配与性能损耗。 | 将常用模型移至类属性，在 `__construct()` 中统一加载，或使用框架的依赖注入容器。 | `protected $bill_model; public function __construct() { $this->bill_model = $this->load->model('ahead_bill_model', '', true); }` |
| 🟠 警告 | `get_shop_book_info` / `v2` | 存在大量重复逻辑（跨天处理、订单状态映射、时间格式化），单方法超 300 行。且隐式存在 N+1 查询风险（循环内调用 `get_one` 或关联查询）。 | 抽取公共逻辑至独立 Service 类（如 `BookingTimeCalculator`）。使用 `WHERE IN` 批量查询替代循环单查，构建内存 Map 进行关联。 | `$ids = array_column($orders, '_id');<br>$map = $this->model->get_data_by_ids($ids, '*', '_id');` |
| 🟠 警告 | 多处时间处理逻辑 | 大量使用 `date()`、`strtotime()` 及硬编码 `86400`、`'00:00'`。未处理时区问题，且 `for` 循环按固定秒数步进，若起始时间戳未对齐 `min_minute_unit_time`，可能导致死循环或时间漏算。 | 统一使用 `DateTime` 对象处理时间，明确业务时区。将步进逻辑改为 `while` 循环配合 `modify()` 或严格对齐算法。 | `$dt = new DateTime('@' . $start, new DateTimeZone('Asia/Shanghai'));<br>while ($dt < $end) { $times[] = $dt->format('H:i'); $dt->modify('+5 minutes'); }` |
| 🟡 建议 | 全局多处 | 魔法数字/字符串泛滥（如 `1`, `2`, `'CYD'`, `'ZD'`, `256`, `'-1'`）。降低可读性，后续业务规则变更时极易遗漏修改点。 | 在类顶部定义语义化常量，替换所有硬编码值。`json_encode` 的 `256` 应替换为 `JSON_UNESCAPED_SLASHES` 等命名常量。 | `const TYPE_ADD = 1; const TYPE_DEL = 2; const PREFIX_BOOK = 'CYD'; const JSON_OPTS = JSON_UNESCAPED_UNICODE \| JSON_UNESCAPED_SLASHES;` |
| 🟡 建议 | `_update_un_book_time` | `array_intersect(...array_values($all_room_book_time))` 使用展开运算符 `...`。当房间数较多或时间段数组较大时，可能超出 PHP 函数参数数量限制（默认 10000+）或引发内存溢出。 | 改用循环逐步求交集，或使用 `array_reduce` 安全计算。 | `$common = array_shift($all_room_book_time);<br>foreach ($all_room_book_time as $arr) { $common = array_intersect($common, $arr); }` |
| 🟡 建议 | `update_day_book_info` | `@return true` 类型声明不规范。PHPDoc 应使用 `@return bool`。且方法直接返回 `true` 掩盖了底层数据库操作失败的可能（如 `insert`/`update` 返回 `false`）。 | 修正 PHPDoc 类型。增加数据库操作结果校验，失败时抛出异常或返回 `false`，便于上层捕获。 | `if (!$this->insert($where)) { throw new RuntimeException('Insert failed'); } return true;` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **移除全局 `$CI = &get_instance();`**：立即将其迁移至类构造函数或依赖注入容器中，避免在 CLI/测试/异步场景下引发致命崩溃。
2. **加固 JSON 解析容错**：所有 `json_decode` 处必须增加 `is_array()` 校验并提供默认空结构，防止脏数据导致服务雪崩。
3. **消除隐式 N+1 查询**：在 `get_shop_book_info` 及相关方法中，将循环内的单条查询改为批量 `WHERE IN` 查询，并在内存中构建索引映射，预计可降低 60%~80% 的数据库交互耗时。
### 🛠 后续重构与优化方向
1. **架构分层（SRP 拆分）**：当前 Model 承担了数据持久化、复杂时间计算、JSON 组装、看板数据格式化等多重职责。建议拆分为：
- `Ahead_shop_book_time_info_model`：仅负责 CRUD 与基础数据映射。
- `BookingTimeService`：处理时间步进、跨天切割、可用时间交集计算。
- `BookingDashboardFormatter`：负责看板数据组装、状态映射与前端格式转换。
2. **时间处理标准化**：废弃裸 `strtotime`/`date` 混用模式。引入 `Carbon` 或原生 `DateTimeImmutable`，统一时区配置（如 `Asia/Shanghai`），并封装 `TimeSlotGenerator` 工具类处理 `5分钟` 步进对齐逻辑。
3. **框架适配说明**：代码呈现典型的 **CodeIgniter 3** 架构特征。若 `phpci` 为内部定制框架，请查阅其官方文档确认：
- 是否支持构造函数依赖注入（推荐替代 `$this->load->model()`）。
- 模型基类 `Simple_model` 是否已封装事务处理（当前多处更新未包裹事务，跨天/跨表更新存在数据不一致风险）。
4. **引入事务保护**：`update_day_book_info` 与 `update_day_time_info_by_bill` 涉及多表/多日期状态联动，建议包裹在 `$this->db->trans_start()` / `$this->db->trans_complete()` 中，确保原子性。
> 💡 **提示**：以上建议代码均符合 PHP 7.4+ / 8.x 语法规范。重构前建议补充单元测试覆盖边界时间（如 `23:55`、跨天 `00:00`、夏令时切换）及异常 JSON 场景，以验证逻辑健壮性。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780379218
|
1780379218
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
120
|
22
|
2
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 提交测试钩子。
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `341c6d8dc ## 自动代码审查报告
**分支**: app-260519
**提交**: `341c6d8dc2b8ad1e55d1ca9fe910dd810534c47d`
**提交人**: zhangjunnan (121158035@qq.com)
**时间**: 2026-05-12 16:05:04
---
## 1. 审查摘要
- **代码质量评分**：3/10
- **总体评价**：当前代码为独立调试脚本形态，存在多处致命逻辑阻断（`exit` 导致后续代码不可达）、cURL 资源泄漏风险、硬编码 HTTP 明文传输等高危问题。代码未遵循 PSR-12 规范，缺乏类型声明与异常安全设计，且未融入目标框架的 MVC/组件化架构。若直接投入生产环境，将导致功能失效、数据泄露及服务器句柄耗尽。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `t.php:2,4` | **逻辑阻断/死代码**：脚本开头连续使用 `exit;`，导致后续所有函数定义、数据构造及业务调用均无法执行。 | 移除所有调试用的 `echo` 与 `exit`，确保代码按预期流程执行。若需保留调试逻辑，应通过环境变量或配置开关控制。 | `// 删除 echo "test21"; exit; 及后续 exit;` |
| 🔴 严重 | `t.php:10-38` | **cURL 句柄泄漏**：`throw new Exception()` 会中断执行流，跳过底部的 `curl_close($curl)`，长期运行将耗尽系统文件描述符。 | 使用 `try...finally` 结构确保无论是否抛出异常，cURL 资源均被正确释放。 | `try { $reponse = curl_exec($curl); /* 校验逻辑 */ } finally { curl_close($curl); }` |
| 🔴 严重 | `t.php:45` | **敏感数据明文传输**：支付/业务回调接口使用 `http://` 协议，未启用 TLS 加密，极易遭受中间人攻击与数据篡改。 | 强制升级为 `https://`，并在 cURL 中配置证书验证（`CURLOPT_SSL_VERIFYPEER` / `CURLOPT_SSL_VERIFYHOST`）。 | `$post_url = "https://pre-pay.g-hi.com/...";` |
| 🟠 警告 | `t.php:15,18,21` | **cURL 选项配置不规范**：`CURLOPT_POST` 应接收布尔值或 `1`，传入 `'2'`、`'3'` 属于未定义行为。POST 类型应由 `CURLOPT_POSTFIELDS` 格式与 Header 决定。 | 统一设置 `curl_setopt($curl, CURLOPT_POST, true);`，根据 `$posttype` 仅处理数据序列化与 Header。 | `curl_setopt($curl, CURLOPT_POST, true);`<br>`if ($posttype == '2') curl_setopt($curl, CURLOPT_POSTFIELDS, http_build_query($jsondata));` |
| 🟠 警告 | `t.php:19` | **冗余且易错的 Header**：手动计算并设置 `Content-Length` 容易因编码问题导致长度不匹配，cURL 底层会自动计算。 | 移除 `'Content-Length: ' . strlen($jsondata)`，交由 cURL 自动处理。 | `curl_setopt($curl, CURLOPT_HTTPHEADER, ['Content-Type: application/json; charset=utf-8']);` |
| 🟡 建议 | `t.php:全文件` | **违反 PSR-12 与框架规范**：缩进混用（Tab/Space）、全局函数定义、无类型声明、注释乱码（`첽֪ͨ`）。在框架项目中应封装为 Controller/Service 类。 | 遵循 PSR-12，添加 `declare(strict_types=1);`、参数/返回值类型提示，将逻辑迁移至框架的 `application/controllers/` 或 `libraries/`。 | 见下方重构示例 |
| 🟡 建议 | `t.php:10` | **变量命名拼写错误**：`$check_reponse` 拼写错误，降低可读性。 | 修正为 `$check_response`。 | `function curlRequest(..., bool $check_response = true)` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **清除死代码**：立即移除顶部的 `exit;` 调试语句，恢复业务逻辑执行流。
2. **修复资源泄漏**：将 `curlRequest` 改造为 `try...finally` 结构，确保 `curl_close()` 必执行。
3. **升级传输协议**：将接口地址改为 `https://`，并补充 SSL 验证配置，避免支付/业务数据裸奔。
4. **修正 cURL 配置**：统一 `CURLOPT_POST` 为 `true`，移除手动 `Content-Length`，避免底层协议栈异常。
### 🛠 后续重构与优化方向
1. **框架化集成**：
> *注：根据提供的项目目录结构（`system/libraries`, `system/database` 等），该架构高度吻合 **CodeIgniter 3**。若 `phpci` 为内部定制框架，请结合其官方文档调整。*
- 建议将 `curlRequest` 封装为独立 Library（如 `application/libraries/Http_client.php`）或 Service 类，避免全局函数污染命名空间。
- 在 CI 框架中，推荐优先使用官方 `curl` 扩展或引入现代 HTTP 客户端（如 `GuzzleHttp`），以获得更好的连接池管理、重试机制与 PSR-7 兼容性。
2. **代码规范与类型安全**：
- 启用严格模式 `declare(strict_types=1);`。
- 为函数添加类型声明（PHP 7.4+ 推荐）：
```php
function curlRequest(string $url, int $postType = 1, ?string $jsonData = null, int $timeout = 0, bool $checkResponse = true): string
```
- 统一使用 UTF-8 编码，修复注释乱码，补充完整的 PHPDoc 块。
3. **健壮性增强**：
- 增加请求重试机制（如指数退避）。
- 对 `$jsondata` 进行 `json_encode` 前的有效性校验（`JSON_THROW_ON_ERROR`）。
- 若用于生产环境，建议将敏感配置（URL、超时、密钥）抽离至 `config.php` 或环境变量，禁止硬编码。
> 💡 **局限性说明**：当前提交仅为单文件调试脚本，未包含路由、控制器入口、配置加载及依赖注入上下文。若需进行完整的架构级审查，请提供完整的 Controller/Model 调用链及框架配置文件。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1778573104
|
1778573104
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
275
|
22
|
25
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 1
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `3c0f5bd7e ## 自动代码审查报告
**分支**: app-260519
**提交**: `3c0f5bd7e1855634449c535406dafffe29548c54`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-21 15:48:50
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该模型文件承载了核心预订、退款、开房等复杂业务逻辑，功能覆盖较全。但存在**事务控制不严谨、N+1 查询性能瓶颈、敏感日志未脱敏、文件级全局代码执行**等典型架构缺陷。代码风格与 PSR-12 规范存在较大差距，魔法数字泛滥，可维护性较低。
- **风险等级**：🔴 高（事务回滚失效可能导致资金/状态不一致；日志泄露存在合规风险）
> ⚠️ **局限性说明**：提供的代码在 `_add_order_data` 方法处被截断，本次审查仅基于已提供内容。若截断部分包含核心支付或状态机逻辑，建议补充后二次审查。
> 📌 **框架说明**：代码特征（`$CI = &get_instance()`、`$this->load->model()`、`$this->db->trans_start()`）高度疑似基于 **CodeIgniter 3/4** 架构。若 `phpci` 为内部定制框架，请对照其官方事务与模型加载规范微调建议。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `invalid_book` / `refund_by_notify` | **事务控制与异常处理冲突**。`throwError()` 若底层调用 `exit/die` 或抛出非 `Exception`，将跳过 `trans_rollback()`，导致已执行的 DB 操作未回滚，引发订单状态与资金流水不一致。 | 使用 `try-catch` 包裹事务块，确保任何异常均触发回滚。避免在事务中直接调用可能终止脚本的全局函数。 | ```php<br>$this->db->trans_begin();<br>try {<br> $this->update(...);<br> $res = $this->refund_by_notify(...);<br> if (!$res['status']) throw new \Exception($res['msg']);<br> $this->db->trans_commit();<br>} catch (\Exception $e) {<br> $this->db->trans_rollback();<br> throw $e; // 交由上层统一处理<br>}<br>``` |
| 🔴 严重 | `refund_by_notify` (约第 118 行) | **敏感支付数据明文落盘**。`doLog(var_export($res, true), "BookOrderWxRefundchin")` 直接记录微信/银联完整响应报文，可能包含商户密钥、签名、用户 OpenID 等敏感信息，违反数据安全规范。 | 记录前过滤敏感字段，或使用框架安全日志组件。仅记录关键状态码与脱敏后的业务标识。 | ```php<br>$safe_log = [<br> 'order_id' => $order_data['_id'],<br> 'result_status' => $result_status,<br> 'code' => $res_code ?? ''<br>];<br>doLog(json_encode($safe_log, JSON_UNESCAPED_UNICODE), "WxRefund");<br>``` |
| 🟠 警告 | `get_list` (约第 215 行) | **N+1 查询性能瓶颈**。在 `foreach` 循环中逐条执行 `$this->ahead_yc_order_model->get_one()`，当列表数据量 >50 时将产生严重数据库连接风暴。 | 收集所有 `relation_order_id`，使用 `where_in` 一次性批量查询，在内存中建立映射关系。 | ```php<br>$ids = array_filter(array_column($order_info, 'relation_order_id'));<br>$room_map = [];<br>if ($ids) {<br> $rooms = $this->ahead_yc_order_model->get_list(['where_in' => ['_id', $ids]]);<br> foreach ($rooms as $r) $room_map[$r['_id']] = $r['_machine_name'];<br>}<br>// 循环内直接 $v['room_name'] .= $room_map[$v['relation_order_id']] ?? '';``` |
| 🟠 警告 | `refund_by_notify` (约第 105 行) | **循环内单条更新**。`foreach ($pay_log_data as $pay_log)` 逐条调用 `update()`，增加网络往返与锁竞争开销。 | 若框架支持 `update_batch` 则使用批量更新；否则收集数据后统一执行，或改用 `CASE WHEN` 语句。 | 使用框架批量更新 API，或拼接 `UPDATE ... SET _status = CASE _id WHEN ? THEN 4 END ...` |
| 🟠 警告 | `refund_by_notify` (约第 88 行) | **潜在 SQL 注入风险**。`$log_where = '_relation_id="' . $order_data['_id'] . '" ...'` 采用字符串拼接构造 WHERE 条件，若 `_id` 未严格校验类型，可被注入恶意 SQL。 | 统一使用框架查询构造器的数组语法，由底层驱动自动转义。 | `$log_where = ['_relation_id' => $order_data['_id'], '_status' => 1, 'where_in' => ['_type', [5, 13]]];` |
| 🟡 建议 | 文件顶部 (第 4-5 行) | **文件级全局代码执行**。`$CI = &get_instance(); $CI->load->model('Simple_model');` 在类定义外执行，每次 `require` 该文件都会触发，违反 OOP 封装原则且增加内存开销。 | 移除文件级代码，将依赖加载移至构造函数或按需加载。 | ```php<br>public function __construct() {<br> parent::__construct();<br> $this->load->model('Simple_model');<br>}<br>``` |
| 🟡 建议 | 多处 (`get_list`, `get_hall_book_orders`) | **方法命名不一致**。混用 `setTablename()` 与 `set_table_name()`，易导致框架底层路由失败或覆盖异常。 | 统一使用框架规范方法（推荐 `$this->db->from($alias)` 或框架标准别名设置方法）。 | 全局替换为 `$this->db->from($this->table_name . ' a');` |
| 🟡 建议 | 全文件 | **魔法数字泛滥**。状态值 `1,2,3,4,5`、支付平台 `1,3,14,17...` 硬编码散落各处，可读性差且后期维护极易出错。 | 提取为类常量或独立配置类，集中管理业务枚举。 | ```php<br>const STATUS_PAID = 1;<br>const STATUS_REFUNDED = 4;<br>const PAY_PLATFORM_WX = 1;<br>``` |
| 🟡 建议 | `refund_by_notify` (约第 145 行) | **动态 `include_once` 破坏自动加载**。`include_once COMMONCLASS . 'WxClass/...'` 依赖全局常量且绕过现代 PHP 自动加载机制，不利于单元测试与部署。 | 使用 Composer 自动加载或框架 `load->library()`，将类实例化移至构造函数或依赖注入。 | `use App\Libraries\WxPayApi;` 或 `$this->load->library('WxPayApi');` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题（P0/P1）
1. **事务安全加固**：立即将 `invalid_book` 及 `openRoomByCommunityOrder` 中的手动事务控制替换为 `try-catch` 结构，确保 `throwError` 或任何未捕获异常均能触发 `trans_rollback()`，防止资金与订单状态不一致。
2. **消除 N+1 查询**：重构 `get_list` 与 `get_detail` 中的关联查询逻辑，采用 `where_in` 批量拉取关联数据并在内存中映射。预计可降低 70% 以上的数据库查询耗时。
3. **日志脱敏与 SQL 安全**：支付回调日志必须脱敏；废弃字符串拼接的 WHERE 条件，全面改用框架查询构造器数组语法。
### 🛠 后续重构与优化方向
1. **架构解耦**：
- 当前 Model 承担了过多业务逻辑（退款计算、第三方支付调用、消息推送、打印机控制等）。建议将 `refund_by_notify` 拆分为独立的 `RefundService` 或 `PaymentGateway`，Model 仅负责数据持久化。
- 移除文件顶部的 `$CI = &get_instance()`，遵循依赖注入或构造函数初始化原则。
2. **规范与可维护性**：
- 引入 `const` 定义业务状态与支付渠道枚举，替换所有魔法数字。
- 统一变量命名风格（推荐驼峰 `camelCase`），统一数组语法为 `[]`。
- 清理历史注释（如 `// 20210712版本，hlj`），使用 PHPDoc 规范方法签名。
3. **框架适配建议**：
- 若 `phpci` 框架支持，建议启用 `trans_strict(TRUE)` 并依赖 `trans_complete()` 的自动回滚机制，减少手动 `trans_rollback()` 调用。
- 频繁加载的模型（如 `ahead_yc_order_model`, `ahead_shop_config_model`）建议在构造函数中预加载，或使用框架的 `autoload` 配置。
> 💡 **下一步行动**：建议先针对 **事务控制** 与 **N+1 查询** 进行热修复，随后在迭代中逐步推进服务层拆分与常量枚举化。如需对截断的 `_add_order_data` 或支付网关交互逻辑进行深度审查，请提供完整代码片段。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779349731
|
1779349731
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
193
|
22
|
12
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - Merge remote-tracking branch 🔍 代码审查报告：app-260519 - Merge remote-tracking branch 'app/app-260519' into...
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `3e251a363 ## 自动代码审查报告
**分支**: app-260519
**提交**: `3e251a363b22be804cc9de7ae816688b5476f852`
**提交人**: zhangjunnan (121158035@qq.com)
**时间**: 2026-05-19 14:13:05
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：业务逻辑覆盖较全，支付、退款、预订等核心流程具备基础实现。但存在多处 **SQL 注入风险**、**事务管理不规范** 及 **逻辑缺陷**，且代码风格偏向老旧写法，未充分利用现代 PHP 特性与框架查询构造器。整体可维护性与安全性有待大幅提升。
- **风险等级**：🔴 高
> ⚠️ **局限性说明**：`Ahead_pay_log_model.php` 文件末尾代码被截断（`$this-`），无法评估完整逻辑。以下审查基于已提供片段，建议补全后二次复核。
> 📌 **框架说明**：代码结构特征（`$CI = &get_instance()`、`Simple_model`、`$this->load->model()`、`$this->db->trans_*`）高度符合 **CodeIgniter 3** 规范。若 `phpci` 为内部定制或衍生框架，请结合其官方文档调整生命周期与组件调用方式。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_pay_log_model.php`<br>`update_refund_amount` / `refund` | **SQL 注入漏洞**：WHERE 条件与 UPDATE 语句直接使用字符串拼接（如 `'_relation_id="' . $relation_id . '"`），未使用参数绑定或查询构造器，恶意输入可导致数据篡改或泄露。 | 全面改用 CI3 查询构造器（Query Builder）或 `$this->db->query()` 配合占位符。 | `$this->db->where('_relation_id', $relation_id)<br>->where('_type', $type)<br>->where_in('_status', [1, 4]);` |
| 🔴 严重 | `Ahead_preorder_order_model.php`<br>`open_room` 方法内循环 | **逻辑缺陷/数据错乱**：`$in_process[] = $data;` 错误地将外部查询结果 `$data` 插入流程数组，应为当前循环变量 `$in_process_v`。将导致流程记录错乱或插入空数据。 | 修正变量引用，确保插入正确的流程状态对象。 | `// 错误：$in_process[] = $data;<br>// 正确：<br>$in_process[] = $in_process_v;` |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`refund_by_notify` | **SQL 注入漏洞**：`$log_where = '_relation_id="' . $order_data['_id'] . '" and _status=1...'` 直接拼接。同属高危注入点。 | 使用模型封装的查询构造器方法，避免手写 SQL 字符串。 | `$this->ahead_pay_log_model->db->where('_relation_id', $order_data['_id'])<br>->where('_status', 1)<br>->where_in('_type', [5, 13]);` |
| 🟠 警告 | 多个 Model 文件 | **事务管理不规范**：手动调用 `trans_begin()` / `trans_rollback()` / `trans_commit()`，但业务中大量使用 `throwError()`。若该函数抛出异常或 `exit`，将跳过 `rollback`，导致脏数据或资金不一致。 | 使用 `try...catch` 包裹事务块，或改用 CI3 自动事务模式 `trans_start()` / `trans_complete()`。 | `try {<br> $this->db->trans_start();<br> // 业务逻辑<br> $this->db->trans_complete();<br>} catch (\Exception $e) {<br> $this->db->trans_rollback();<br> throw $e;<br>}` |
| 🟠 警告 | 多个 Model 文件 | **性能瓶颈 (N+1查询)**：在业务方法中频繁调用 `$this->load->model()`，部分甚至在循环或高频回调中加载。每次加载都会触发文件包含与实例化，拖慢响应。 | 将依赖模型统一移至 `__construct()` 初始化，或使用服务容器/依赖注入。 | `public function __construct() {<br> parent::__construct();<br> $this->load->model(['model_a', 'model_b', 'model_c']);<br>}` |
| 🟠 警告 | `Ahead_pay_log_model.php`<br>`add_order_pay_log` | **类型比较隐患**：`in_array($type, array_keys(self::PAY_LOG_TITLE_MAP))` 未开启严格模式。常量键为字符串 `'1'`，若传入整型 `1` 会因松散比较返回 `true`，可能引发类型混淆。 | 开启严格比较或统一类型转换。 | `in_array((string)$type, array_keys(self::PAY_LOG_TITLE_MAP), true)` |
| 🟡 建议 | 全局代码 | **代码规范与可维护性**：大量使用 `array()` 而非 `[]`；存在硬编码（如 `md5` 盐值、模板索引 `10`）；注释包含个人调试记录（如 `2020-09-30，hlj`）；未使用类型声明。 | 遵循 PSR-12；提取配置/常量；清理调试注释；启用 `declare(strict_types=1)` 与参数类型提示。 | `const WX_REFUND_SALT = '1441600902';<br>public function refund(int $pay_id, float $amount): bool` |
| 🟡 建议 | `Ahead_yc_order_process_model.php`<br>`add_order_process` | **空值判断不严谨**：`is_null($userInfo)` 用于判断数组返回值。若查询失败返回 `false` 或空数组，`is_null` 将失效。 | 使用 `empty()` 或 `isset()` 进行安全判断。 | `$userName = !empty($userInfo['_name']) ? $userInfo['_name'] : '';` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即修复 SQL 注入点**：全局搜索 `'_xxx="' . $var . '"` 或 `'_xxx=' . $var` 模式，全部替换为 CI3 Query Builder 的 `where()`、`where_in()`、`set()` 方法。支付与退款模块涉及资金安全，必须作为 P0 级任务处理。
2. **修正 `open_room` 变量赋值 Bug**：`$in_process[] = $data;` 会导致流程日志写入错误数据，直接影响订单状态追踪与售后排查。
3. **统一事务异常处理机制**：将 `trans_begin/rollback/commit` 包裹在 `try...catch` 中，或全面迁移至 `trans_start()/trans_complete()` 自动模式，确保任何异常（包括 `throwError`）都能安全回滚。
### 🛠 后续重构与优化方向
| 优化维度 | 具体建议 |
| :--- | :--- |
| **架构解耦** | 当前 Model 承担了过多业务逻辑（支付、退款、库存、消息推送、报表统计）。建议抽取 `PaymentService`、`RefundService`、`OrderProcessService` 等独立服务类，Model 仅负责数据持久化。 |
| **性能提升** | 1. 模型依赖集中初始化，避免运行时重复加载。<br>2. 报表类查询（如 `get_business`）增加数据库索引覆盖（`_create_time`, `_pay_platform`, `_status`）。<br>3. 高频读取的配置（如支付平台映射）建议接入 Redis 缓存。 |
| **规范升级** | 1. 全面启用 `declare(strict_types=1)` 与 PHP 7.4+ 类型声明。<br>2. 替换 `array()` 为 `[]`，统一使用 PSR-12 缩进与命名规范。<br>3. 移除硬编码，将支付盐值、模板 ID、业务状态映射移至配置文件或数据库字典表。 |
| **框架适配** | 若项目确为 `phpci` 定制版，请确认其是否重写了 `Simple_model` 的生命周期或查询构造器。建议查阅官方文档确认 `load->model()` 的缓存机制与事务钩子，避免与原生 CI3 行为冲突。 |
> 💡 **审查专家提示**：支付与退款链路是系统的“资金命脉”。建议在修复上述问题后，补充 **单元测试**（覆盖正常支付、部分退款、并发退款、异常回滚等场景）与 **集成测试**，并引入静态代码分析工具（如 `PHPStan` 或 `Psalm`）进行常态化质量门禁。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779171185
|
1779171185
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
285
|
22
|
27
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 1
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `484c4a1fb ## 自动代码审查报告
**分支**: app-260519
**提交**: `484c4a1fb47fd3e2600891fd4e22def5f973f656`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-22 13:40:50
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：该 Model 承载了复杂的预订、退款、社区开房及支付回调逻辑，业务覆盖全面。但存在明显的架构与编码规范问题：事务边界控制混乱、循环内查询导致 N+1 性能瓶颈、硬编码魔法值泛滥、部分 SQL 拼接存在注入风险。整体可维护性与健壮性有待提升。
- **风险等级**：🔴 高（存在事务提交后回滚无效、潜在 SQL 注入及严重性能隐患）
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `openRoomByCommunityOrder` ~L460 | **事务提交过早导致数据不一致**：`$this->db->trans_complete();` 在方法中段提前调用，后续更新预订单状态或支付流水失败时，`trans_rollback()` 已无法生效，造成脏数据。 | 将 `trans_complete()` 移至所有数据库操作完成后，或改用 `try-catch` 包裹完整事务块，依赖框架自动回滚机制。 | ```php<br>$this->db->trans_begin();<br>try {<br> // 所有 insert/update 操作<br> $this->db->trans_commit();<br>} catch (\Exception $e) {<br> $this->db->trans_rollback();<br> throwError($e->getMessage());<br>}<br>``` |
| 🔴 严重 | `refund_by_notify` ~L135 | **SQL 注入风险**：`$log_where` 使用字符串拼接构造 WHERE 条件，若 `$order_data['_id']` 来源不可控，将直接导致 SQL 注入。 | 废弃字符串拼接，统一使用框架查询构建器（Query Builder）或参数化查询。 | ```php<br>$this->ahead_pay_log_model<br> ->where('_relation_id', $order_data['_id'])<br> ->where('_status', 1)<br> ->where_in('_type', [5, 13])<br> ->update(['_status' => 4, '_refund_amount' => ...]);<br>``` |
| 🟠 警告 | `get_list` / `get_detail` | **N+1 查询性能瓶颈**：在 `foreach` 循环中频繁调用 `get_one()` 查询关联订单/房型数据，数据量大时将导致数据库连接耗尽与响应超时。 | 提取关联 ID 数组，使用 `WHERE IN` 批量查询后映射，或在 SQL 层使用 `LEFT JOIN` 一次性获取。 | ```php<br>$ids = array_column($order_info, 'relation_order_id');<br>$orders = $this->ahead_yc_order_model->where_in('_id', $ids)->get()->result_array();<br>$map = array_column($orders, null, '_id');<br>// 循环中直接 $map[$v['relation_order_id']] 取值<br>``` |
| 🟠 警告 | 文件顶部 L5-L6 | **全局实例化破坏框架生命周期**：`$CI = &get_instance();` 在类外部执行，文件被 `include` 时即触发，若框架未初始化完成将报 Fatal Error。 | 移除文件顶部代码，在类内部通过 `$this->ci = &get_instance();` 获取，或直接使用 `$this->load`。 | ```php<br>class Ahead_book_order_model extends Simple_model {<br> protected $ci;<br> public function __construct() {<br> parent::__construct();<br> $this->ci =& get_instance();<br> }<br>}<br>``` |
| 🟠 警告 | `refund_by_notify` / `invalid_book` | **类型比较不一致与隐式转换**：`$is_refund == '1'` 与 `$is_refund != '1'` 混用，且未对金额进行严格类型校验，易引发逻辑分支误判。 | 统一使用严格比较 `===`，并在入口处进行类型强转或校验。 | `if ((int)$is_refund === 1) { ... }` |
| 🟡 建议 | 全文多处 | **魔法数字/字符串泛滥**：大量使用 `-1, 1, 2, 3, 4, 5, 8, 9, 14, 17...` 表示状态、支付渠道、业务类型，可读性极差且后期维护成本极高。 | 使用类常量（或 PHP 8.1+ 枚举）集中管理业务状态码。 | ```php<br>const STATUS_PENDING_PAY = -1;<br>const STATUS_PAID = 1;<br>const PAY_PLATFORM_WX = 1;<br>``` |
| 🟡 建议 | `refund_by_notify` 等 | **重复加载模型**：同一方法内多次调用 `$this->load->model()`，虽框架有缓存，但增加解析开销且破坏单一职责。 | 在构造函数中统一加载所需模型，或采用依赖注入。 | `public function __construct() { parent::__construct(); $this->load->model(['ahead_book_order_refund_model', 'ahead_vip_model', ...]); }` |
| 🟡 建议 | `doLog(var_export($res, true), ...)` | **敏感数据日志泄露风险**：直接记录支付接口完整返回报文，可能包含商户密钥、用户 OpenID 或交易流水号，违反安全合规要求。 | 日志记录前进行脱敏处理，或仅记录关键状态码与业务 ID。 | `doLog(json_encode(['status'=>$res_code, 'order_id'=>$order_id]), "BookOrderWxRefund");` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修正事务边界**：立即重构 `openRoomByCommunityOrder` 与 `notifyCommunityBookOrder` 中的事务控制逻辑。确保 `trans_complete()` / `trans_commit()` 仅在**所有**核心数据落盘成功后调用，失败时统一由 `catch` 块或框架机制回滚。
2. **消除 SQL 注入隐患**：全局排查 `$log_where`、`$pay_where` 等字符串拼接条件，替换为 Query Builder 链式调用或预处理语句。
3. **解决 N+1 查询**：对 `get_list()` 和 `get_detail()` 进行批量查询改造，预计可降低 70% 以上的数据库 IO 开销。
### 🛠 后续重构与优化方向
1. **状态码与配置集中化**：建立 `OrderStatus`、`PayPlatform`、`RefundType` 等常量类或枚举。将硬编码的业务规则抽离至配置层，提升代码可读性与可测试性。
2. **方法职责拆分**：`refund_by_notify` 方法已超 200 行，混合了日志记录、流水更新、第三方支付调用、社区营收计算等多重职责。建议按 **策略模式** 拆分支付退款逻辑，按 **事件监听** 处理日志与通知，使 Model 回归数据访问本质。
3. **引入类型声明**：逐步为方法参数与返回值添加 PHP 7+ 类型提示（如 `int`, `array`, `bool`），配合静态分析工具（PHPStan/Psalm）提前拦截类型错误。
4. **框架适配说明**：当前代码呈现典型的 CodeIgniter 3 风格。若 `phpci` 为定制框架，请确认 `$this->db->trans_*` 与 `$this->load->model()` 的底层实现是否与 CI3 一致。若框架已支持依赖注入容器，建议逐步替换 `$this->load` 调用。
> ⚠️ **局限性说明**：提供的代码在 `_add_order_data` 方法末尾被截断，未能完整审查该方法的数据组装逻辑及后续调用链。建议补充完整代码以便进行全量评估。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779428450
|
1779428450
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
258
|
22
|
22
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 预订开房后去开房订单退款，更新自助营业两个报表
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `4d56bfce5 ## 自动代码审查报告
**分支**: app-260519
**提交**: `4d56bfce58b5a6aa4f3a82b3b494c92db85e6ec4`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-20 18:51:13
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该 Model 承载了支付流水、账单查询、报表统计、退款核心逻辑及第三方 API 调用，功能完整但**职责严重越界**。代码存在明显的 SQL 注入风险、循环内 N+1 查询性能瓶颈、事务与异常处理不一致等问题。类型处理松散、硬编码较多，不符合现代 PHP 工程化规范。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `update_refund_amount` / `refund` | **SQL 注入漏洞**：多处使用字符串拼接构造 `WHERE` 和 `UPDATE` 语句（如 `'_relation_id="' . $relation_id . '"`），未进行参数绑定或转义。 | 全面替换为框架查询构造器（Query Builder）或预处理语句，严禁直接拼接用户/业务输入。 | `$this->db->where('_relation_id', $relation_id)->where('_type', $type)->where_in('_status', [1,4])->update($this->table_name, $data);` |
| 🔴 严重 | `refund` 方法 | **事务与异常处理不一致**：使用自定义 `throwError()` 中断流程，若该函数非标准 `Exception` 或包含 `exit/die`，可能导致事务状态混乱或重复回滚。 | 统一使用 PHP 标准异常 `throw new \RuntimeException()`，配合 `try-catch-finally` 确保事务安全提交/回滚。 | `try { $this->db->trans_begin(); /* 业务逻辑 */ $this->db->trans_commit(); } catch (\Exception $e) { $this->db->trans_rollback(); throw $e; }` |
| 🟠 警告 | `get_bill_pay_log` / `get_refundable_pay_log` | **N+1 查询性能瓶颈**：在 `foreach` 循环内频繁调用 `get_one()` 加载关联模型（订单、扩展、用户、配置等），数据量稍大即导致数据库连接耗尽与响应超时。 | 提取循环所需 ID，使用 `WHERE IN` 批量查询，在内存中通过 `array_column` 或键值映射进行关联。 | `$ids = array_column($log_data, 'relation_id'); $orders = $this->ahead_yc_order_model->get_list(['where_in' => ['_id', $ids]]); $orderMap = turn_array_key($orders, '_id');` |
| 🟠 警告 | `get_bill_pay_log` | **未定义变量风险**：`$bondsman_data` 仅在 `if (!empty($bondsman))` 内赋值，后续 `$bondsman_data['_name'] ?? ''` 在 PHP 8+ 会触发 `Undefined variable` 警告。 | 在循环外或条件分支前初始化变量。 | `$bondsman_data = []; if (!empty($bondsman)) { $bondsman_data = $this->ahead_yc_merchant_user_model->get_one(...); }` |
| 🟠 警告 | `get_business` | **时间范围校验缺陷**：`strtotime()` 可能返回 `false`，直接参与减法运算会导致逻辑错误或类型警告。 | 增加时间格式校验，或使用 `DateTime` 对象进行安全计算。 | `$start = strtotime($params['start_time']); $end = strtotime($params['end_time']); if ($start === false || $end === false || ($end - $start) > 31 * 86400) throwError("...");` |
| 🟡 建议 | 类定义顶部 | **模型加载位置不当**：类外部使用 `$CI = &get_instance(); $CI->load->model('Simple_model');`，破坏封装性且可能引发重复加载。 | 移除外部加载，依赖框架自动加载或在 `__construct()` 中处理。若 `Simple_model` 为父类，直接 `extends` 即可。 | `class Ahead_pay_log_model extends Simple_model { public function __construct() { parent::__construct(); } }` |
| 🟡 建议 | `mobile_refund` | **硬编码敏感信息**：MD5 盐值 `'1441600902'`、`'2017040606573534'` 及 Redis DB 索引硬编码在业务逻辑中，存在泄露风险且不利于多环境配置。 | 将密钥、盐值、Redis 配置移至 `config/` 目录，通过 `$this->config->item()` 读取。 | `$salt = $this->config->item('wx_refund_salt'); $data['refund_key'] = md5($order_info['_id'] . $order_info['_trade_no'] . $salt);` |
| 🟡 建议 | 全局多处 | **类型不一致与松散比较**：数组键混用字符串 `'1'` 与整型 `1`，`in_array` 未开启严格模式，易引发隐式类型转换 Bug。 | 统一使用整型作为键/值，所有比较操作使用严格模式 `===` 或 `in_array($val, $arr, true)`。 | `const PAY_LOG_TITLE_MAP = [1 => '订单支付', 2 => '账单支付']; if (!in_array($type, array_keys(self::PAY_LOG_TITLE_MAP), true)) { ... }` |
| 🟡 建议 | `add_order_pay_log` | **冗余计算与死代码**：`$actual_pay += $params['_actual_pay'];` 累加后从未使用，增加无意义内存开销。 | 移除未使用的变量，或明确其业务用途（如返回给调用方）。 | `// 删除 $actual_pay 相关累加逻辑` |
> 📝 **框架适配说明**：基于 `$CI = &get_instance()`、`$this->load->model()`、`$this->db->trans_begin()` 等特征，判定代码运行于 **CodeIgniter 3** 或高度定制的同构框架。以下建议基于 CI3 最佳实践。若 `phpci` 为内部自研框架，请核对事务管理与查询构造器 API 是否一致。
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即修复 SQL 注入**：`update_refund_amount` 与 `refund` 中的原始 SQL 拼接是最高危漏洞，必须替换为 Query Builder 或参数绑定。
2. **统一异常与事务机制**：废弃全局 `throwError()` 中断模式，改用 `try-catch` 包裹事务块，确保资金操作具备强一致性。
3. **消除 N+1 查询**：`get_bill_pay_log` 等列表方法必须改为批量查询+内存映射，否则在并发或数据量增长时将直接拖垮数据库。
### 🛠 后续重构与优化方向
- **架构分层（SRP 原则）**：当前 Model 承担了数据持久化、业务规则校验、第三方 API 调用、Redis 操作、报表计算等职责。建议拆分为：
- `Model`：仅负责 CRUD 与基础查询构造。
- `Service/Domain`：处理退款流程、状态机流转、跨模型事务协调。
- `Gateway/Client`：封装微信/支付宝退款 API 调用。
- **配置集中化**：将支付类型映射、自定义支付平台、MD5 盐值、Redis 索引等全部抽离至 `config/` 文件，便于多环境部署与安全审计。
- **类型安全与 PSR-12 规范**：启用 PHP 8 严格类型声明（`declare(strict_types=1);`），统一方法命名（驼峰或下划线保持一致），补充 PHPDoc 类型注解（`@param int $type`, `@return array` 等）。
- **代码片段局限性说明**：末尾 `add_by_vip_recharge_order` 方法被截断，无法评估其完整逻辑与潜在风险。建议补充完整代码后二次审查。
> 💡 **行动建议**：建议先建立自动化测试用例覆盖核心退款与流水插入流程，随后按 `安全修复 → 性能优化 → 架构重构` 的顺序迭代。如涉及资金结算，务必在预发环境进行全链路压测与事务回滚验证。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779274273
|
1779274273
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
233
|
22
|
15
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 1
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `5dff766fa ## 自动代码审查报告
**分支**: app-260519
**提交**: `5dff766fa30044778ad01abab4b076a9e8f5739c`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-20 11:28:05
---
## 1. 审查摘要
- **代码质量评分**：5.5/10
- **总体评价**：业务逻辑覆盖较完整，但存在严重的安全隐患（SQL 字符串拼接）、架构反模式（数据库事务内同步调用外部支付 API）、性能瓶颈（N+1 查询）及代码规范问题。整体可维护性较低，需优先重构事务边界、统一异常处理与数据查询策略。
- **风险等级**：🔴 高
## 2. 问题详情
*(注：行号为基于提供代码片段的估算值，实际以文件为准)*
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`refund_by_notify()` | **SQL 注入风险**：使用字符串直接拼接 `WHERE` 条件（如 `$log_where`、`$uwhere`、`$sup`），未使用查询构造器或参数绑定。若上游数据未严格过滤，将导致注入。 | 全面改用 CI 查询构造器或数组条件，禁止手动拼接 SQL 片段。 | `$this->db->where('_relation_id', $order_data['_id'])`<br>`->where('_status', 1)`<br>`->where_in('_type', [5, 13]);` |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`invalid_book()` & `refund_by_notify()` | **事务内调用外部 API**：在 `trans_start()` 开启的事务中同步调用微信/银联退款接口。长事务会长时间持有数据库锁，极易引发死锁、连接池耗尽或请求超时。 | 采用“本地状态预更新 → 调用外部 API → 根据结果回调更新”的异步/补偿事务模式。将 API 调用移出事务块。 | 见下方重构建议 |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`get_list()` | **N+1 查询性能瓶颈**：在 `foreach` 循环中调用 `get_one()` 查询关联订单，数据量大时将产生大量冗余查询。 | 提前批量查询关联数据，在内存中通过 `key-value` 映射组装。 | `$ids = array_column($order_info, 'relation_order_id');`<br>`$orders = $this->ahead_yc_order_model->get_many(['where_in' => ['_id', $ids]]);`<br>`$orderMap = array_column($orders, null, '_id');` |
| 🟠 警告 | `Ahead_preorder_order_model.php`<br>`open_room()` | **批量操作未包裹事务**：连续执行多个 `insert_batch()` 和 `update()`，若中途失败会导致数据不一致（如订单已插入但流水未记录）。 | 使用 `$this->db->trans_start()` 包裹所有批量写入操作，依赖框架自动回滚。 | `$this->db->trans_start();`<br>`// ... batch inserts ...`<br>`$this->db->trans_complete();` |
| 🟠 警告 | 所有 Model 文件顶部 | **模型加载时机不当**：文件顶部直接执行 `$CI = &get_instance(); $CI->load->model('Simple_model');`，导致每次请求解析文件时均触发加载，浪费资源。 | 将模型加载移至 `__construct()` 中，或依赖框架自动加载配置。 | `public function __construct() { parent::__construct(); $this->load->model('Simple_model'); }` |
| 🟡 建议 | 多处方法 | **魔法数字泛滥**：状态值（`1,4,5,13`）、支付类型（`1,3,14`）等硬编码散落各处，可读性差且后期维护极易遗漏。 | 在类顶部或独立配置文件中定义常量，统一引用。 | `const STATUS_PAID = 1; const STATUS_REFUNDED = 4;`<br>`const PAY_WX = 1; const PAY_VIP = 3;` |
| 🟡 建议 | `Ahead_book_order_model.php`<br>`openRoomByCommunityOrder()` | **手动回滚与框架机制冲突**：在 `try-catch` 中手动调用 `$this->db->trans_rollback()` 后抛出异常，可能与 CI 的自动事务管理机制产生冲突或重复回滚。 | 移除手动 `trans_rollback()`，仅依赖 `$this->db->trans_complete()` 的自动回滚特性。捕获异常后直接抛出或返回错误数组。 | 移除 `try` 块内的 `$this->db->trans_rollback();`，交由框架处理。 |
| 🟡 建议 | `Ahead_book_order_model.php` 末尾 | **代码截断**：文件在 `_add_order_data()` 方法处中断，无法审查完整逻辑及后续方法。 | 请补充完整文件以便进行全量评估。 | - |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **消除 SQL 拼接隐患**：立即将 `$log_where`、`$uwhere`、`$sup` 等字符串拼接改为查询构造器链式调用或数组条件。这是最高优先级的安全修复。
2. **重构事务边界**：将 `refund_by_notify()` 中的微信/银联退款 API 调用移出数据库事务。建议改为：
```php
// 1. 开启事务更新本地状态为“退款处理中”
$this->db->trans_start();
$this->update(['_status' => 3], ['_id' => $book_order['_id']]);
$this->db->trans_complete();
// 2. 调用外部退款 API
$api_res = $this->callRefundApi($order_data);
// 3. 根据 API 结果更新最终状态（可走异步回调或同步更新）
if ($api_res['success']) {
$this->update(['_status' => 4], ['_id' => $book_order['_id']]);
}
```
3. **解决 N+1 查询**：在 `get_list()` 和 `get_detail()` 中，使用 `WHERE IN` 批量拉取关联表数据，在 PHP 层进行数组映射，可将数据库查询次数从 `O(N)` 降至 `O(1)`。
### 🛠 后续重构与优化方向
- **统一异常与错误处理**：当前混用 `throwError()`、`return ['status'=>false]` 和 `try-catch`。建议统一使用标准 PHP 异常（如 `throw new \RuntimeException()`）或框架提供的异常类，配合全局异常处理器记录日志并返回标准化响应。
- **常量与配置抽离**：将支付平台、订单状态、业务模式等硬编码数字提取至 `config/constants.php` 或类常量中，提升代码自解释能力。
- **方法职责拆分**：`refund_by_notify()` 和 `openRoomByCommunityOrder()` 方法过长（超 150 行），违反单一职责原则。建议按“数据准备 → 外部交互 → 状态更新 → 日志记录”拆分为多个私有方法。
- **框架适配说明**：代码结构高度符合 **CodeIgniter 3** 规范。若 `phpci` 为内部定制框架，请重点核对：
- `$this->db->trans_start()/trans_complete()` 的自动回滚行为是否与 CI3 一致。
- `$this->load->model()` 的缓存机制是否支持构造函数内加载。
- 若存在差异，请查阅 `phpci` 官方文档调整事务与模型加载策略。
> 💡 **提示**：本次审查基于提供的代码片段。若 `Ahead_book_order_model.php` 后续逻辑涉及敏感金额计算或并发控制，建议补充完整代码以便进行死锁风险与精度丢失的专项评估。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779247685
|
1779247685
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
238
|
22
|
17
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 1
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `6c086caae ## 自动代码审查报告
**分支**: app-260519
**提交**: `6c086caae3f89423a968fde5f171071ce76cd7d6`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-20 14:10:42
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该 Model 承载了核心支付流水、退款及营收统计逻辑，业务覆盖较全。但代码存在明显的 **SQL 注入风险**、**事务回滚隐患**、**N+1 查询性能瓶颈** 以及 **硬编码敏感密钥** 等问题。代码风格偏向早期 CI3 开发习惯，缺乏现代 PHP 类型约束与防御性编程设计。
- **风险等级**：🔴 高
- **框架说明**：注：代码结构、加载方式（`get_instance()`、`$this->load->model()`、`system/` 目录）及查询构造器特征高度符合 **CodeIgniter 3** 框架，而非 `phpci`。以下审查基于 CI3 架构规范与 PHP 8+ 最佳实践进行。若实际为 `phpci`，请确认底层是否兼容 CI3 语法。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `refund()` / `update_refund_amount()` | **SQL 注入风险**：多处使用字符串拼接构造 `WHERE` 和 `UPDATE` 语句（如 `'_id = "' . $pay_id . '"'`），未使用查询构造器或参数绑定。若 `$pay_id` 或 `$type` 未严格过滤，将导致注入。 | 全面改用 CI3 Query Builder 或预处理机制，利用框架自动转义功能。 | `$this->db->where('_id', $pay_id)->where_in('_status', [1,4])->get()->row();`<br>`$this->db->set('_refund_amount', '_refund_amount + ' . floatval($refund_amount), FALSE)->update($this->table_name, $where);` |
| 🔴 严重 | `mobile_refund()` | **硬编码敏感密钥**：退款验签使用硬编码字符串 `'1441600902'` 等作为 Salt。一旦泄露或需多环境隔离，将引发严重安全与运维问题。 | 将密钥移至 `application/config/config.php` 或环境变量，通过 `$this->config->item()` 读取。 | `$salt = $this->config->item('refund_salt_wechat');`<br>`$data['refund_key'] = md5($order_info['_id'] . $order_info['_trade_no'] . $salt);` |
| 🔴 严重 | `refund()` | **事务安全性隐患**：依赖全局 `throwError()` 中断流程。若该函数直接 `exit/die` 或抛出未捕获异常，会导致 `$this->db->trans_begin()` 开启的事务未执行 `trans_rollback()`，引发数据不一致。 | 使用 `try...catch` 包裹事务逻辑，确保任何异常都能触发回滚。 | `try { $this->db->trans_begin(); ... } catch (\Throwable $e) { $this->db->trans_rollback(); log_message('error', $e->getMessage()); throwError($e->getMessage()); }` |
| 🟠 警告 | `get_bill_pay_log()` / `get_refundable_pay_log()` | **N+1 查询性能瓶颈**：在 `foreach ($log_data as &$v)` 循环内频繁调用 `get_one()` 查询关联模型（订单扩展、门店配置、挂账日志等）。数据量 >50 时响应时间呈指数级增长。 | 提取循环内查询条件，使用 `where_in` 批量查询，在内存中建立映射关系后填充。 | 见下方优化示例 |
| 🟠 警告 | `add_order_pay_log()` | **数组状态污染**：循环内 `unset($params['_payment_amount'])` 会修改原数组引用。若 `$params` 在循环外被复用，将导致后续逻辑丢失字段。 | 在循环内创建副本操作，避免污染入参。 | `$current_params = $params; unset($current_params['_payment_amount']); $insertRes = $this->_deal_add_pay_log(..., $current_params);` |
| 🟠 警告 | 多处方法 | **频繁加载模型**：在业务方法内部重复调用 `$this->load->model()`，增加框架解析与实例化开销。 | 将高频依赖模型移至构造函数加载，或配置 `autoload.php`。 | `public function __construct() { parent::__construct(); $this->load->model(['ahead_vip_model','ahead_bill_model','ManageMap']); }` |
| 🟡 建议 | 全局常量定义 | **魔法数字泛滥**：状态码 `14, 15, 11, 6, 17~28` 等散落在代码中，可读性与可维护性差。 | 提取为类常量，统一使用常量进行条件判断。 | `const PLATFORM_CUSTOM_MIN = 17; const PLATFORM_CUSTOM_MAX = 28;`<br>`if ($platform >= self::PLATFORM_CUSTOM_MIN && $platform <= self::PLATFORM_CUSTOM_MAX) { ... }` |
| 🟡 建议 | 全局注释/规范 | **过期注释与类型缺失**：存在 `//之前不知道为啥被注释掉...2020-09-30` 等无效注释；方法缺乏 PHPDoc 类型声明，不符合现代 PHP 规范。 | 清理无用注释，补充 `@param`、`@return` 类型提示，遵循 PSR-12 缩进与命名规范。 | `/** @param int $pay_id @param float $refund_amount @return bool */ public function refund(int $pay_id, float $refund_amount): bool` |
### 💡 N+1 查询优化示例 (`get_bill_pay_log` 循环段)
```php
// 1. 批量提取需要查询的 ID
$order_ids = array_unique(array_column($log_data, 'relation_id'));
$shop_ids = array_unique(array_column($log_data, 'shop_id'));
// 2. 批量查询并建立映射
$order_ext_map = [];
if ($order_ids) {
$this->load->model('ahead_yc_order_extension_model');
$extensions = $this->ahead_yc_order_extension_model->select(['where_in' => ['_order_id', $order_ids]]);
foreach ($extensions as $ext) { $order_ext_map[$ext['_order_id']] = $ext; }
}
// 3. 循环内直接读取映射，消除 DB 调用
foreach ($log_data as &$v) {
$v['manager_reason'] = '';
if ($v['type'] == 1 && isset($order_ext_map[$v['relation_id']]['_alter_timing_reason'])) {
$v['manager_reason'] = $order_ext_map[$v['relation_id']]['_alter_timing_reason'];
}
// ... 其他逻辑保持不变
}
```
## 3. 总结与行动建议
### 🚨 优先修复的关键问题（P0/P1）
1. **修复 SQL 注入漏洞**：立即替换 `refund()`、`update_refund_amount()` 中所有字符串拼接的 SQL 条件，改用 `$this->db->where()`、`$this->db->set()` 或预处理语句。
2. **加固事务边界**：将 `refund()` 中的事务逻辑包裹在 `try...catch` 中，确保任何异常或 `throwError()` 触发前执行 `$this->db->trans_rollback()`。
3. **移除硬编码密钥**：将 `mobile_refund()` 中的验签 Salt 抽离至配置文件，支持多环境隔离与密钥轮换。
### 🛠 后续重构与优化方向
1. **性能架构升级**：
- 彻底消除 Model 方法内的循环 DB 查询，采用 `where_in` + 内存映射模式。
- 考虑将高频只读配置（如支付平台映射、门店自定义支付）接入 Redis 缓存，降低 DB 压力。
2. **代码规范化**：
- 清理 `2020-09-30` 等历史调试注释，统一使用 PHPDoc 规范。
- 逐步引入 PHP 8 类型声明（`int`, `float`, `array`, `bool`），提升静态分析能力。
- 将魔法数字收敛至类常量或独立配置类。
3. **框架适配建议**：
- 若项目确为 CI3，建议启用 `$config['db_debug'] = FALSE;` 生产环境配置，并统一使用 CI3 的 `trans_strict` 模式。
- 若实际使用 `phpci`，请确认其底层是否完全兼容 CI3 的 Query Builder 与事务 API，必要时需适配对应框架的 ORM 语法。
> ⚠️ **局限性说明**：由于提供的代码在 `add_by_vip_recharge_order` 方法末尾被截断，该方法的完整逻辑、返回值处理及潜在缺陷未能纳入本次审查。建议补充完整代码后再次进行深度评估。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779257443
|
1779257443
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
467
|
22
|
54
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 订单详情返回用户的会员卡号
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `7136a48c5 ## 自动代码审查报告
**分支**: app-260519
**提交**: `7136a48c5358a221cdd324dfa2658ccab6831642`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 15:48:11
---
## 1. 审查摘要
- **代码质量评分**：4.5 / 10 分
- **总体评价**：该控制器承载了路由分发、身份鉴权、多业务逻辑处理及响应格式化，属于典型的“上帝控制器”。代码中存在敏感信息硬编码、明文密码比对、绕过框架输入过滤等高危安全隐患；架构上严重违背单一职责原则，维护成本极高。整体符合早期 CI3 遗留系统的常见写法，但距离现代 PHP 安全与工程规范差距较大。
- **风险等级**：🔴 高
> 📌 **框架说明**：根据目录结构（`system/`、`application/`）、常量 `BASEPATH` 及 `$this->load->` 等语法，该代码实际运行于 **CodeIgniter 3.x** 框架。下文审查将基于 CI3 最佳实践与 PSR-12 规范进行。若 `phpci` 为内部定制框架，核心安全与架构建议依然适用。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 约 L340-L346 | **敏感配置硬编码**：科大讯飞 TTS 的 `APPID`、`APISecret`、`APIKey` 直接暴露在源码中，极易通过版本库泄露。 | 移至独立配置文件（如 `config/xfyun.php`）或服务器环境变量，通过 `$this->config->item()` 读取。 | `// config/xfyun.php<br>$config['xfyun'] = [<br> 'APPID' => getenv('XFYUN_APPID'),<br> 'APISecret' => getenv('XFYUN_SECRET'),<br> 'APIKey' => getenv('XFYUN_KEY')<br>];` |
| 🔴 严重 | 约 L280 | **明文密码存储与比对**：`$data['_discount_pwd'] != $_old_password` 疑似明文比对，违反密码安全基线。 | 数据库必须存储 `password_hash()` 结果，验证时使用 `password_verify()`。 | `if (!password_verify($_old_password, $data['_discount_pwd'])) {<br> $this->error_response('旧密码不正确');<br>}` |
| 🔴 严重 | L45, L18 | **绕过框架输入过滤**：直接使用 `$_POST` 与 `php://input`，未使用 CI 的 `$this->input` 类，丧失 XSS 过滤与全局过滤机制。 | 统一使用 `$this->input->raw_input_stream` 或 `$this->input->post()`，并开启全局 XSS 过滤。 | `$raw = $this->input->raw_input_stream;<br>$this->stream = json_decode($raw, true) ?: [];` |
| 🟠 警告 | L1-L100+ | **上帝控制器/路由耦合**：`__construct` 与 `index()` 混合了鉴权、配置加载、业务路由、数据组装，代码超千行，难以测试与维护。 | 将鉴权逻辑抽离至 `BaseController` 或 CI Hook；将 `switch` 分支拆分为独立方法；业务逻辑下沉至 Service/Model。 | 使用 CI 路由配置映射 `function` 到独立方法，或采用命令模式分发。 |
| 🟠 警告 | 多处 `error_response` | **破坏框架生命周期**：错误处理疑似直接 `exit/die`，导致 CI 的 `post_controller`、Session 写入、日志记录等钩子无法执行。 | 改为抛出标准异常，或使用 CI 的 `show_error()`；若必须返回 JSON，应在统一输出层处理。 | `throw new \RuntimeException('token参数错误', 401);`<br>配合全局异常处理器统一输出 JSON。 |
| 🟠 警告 | L105, L115, L200+ | **重复加载模型/配置**：在 `switch` 各分支中频繁 `load->model()` 与 `load->config()`，增加 I/O 开销。 | 在 `__construct` 中统一加载高频模型；低频模型按需加载但需避免重复调用。 | `$this->load->model(['ahead_yc_merchant_model', 'ahead_yc_shop_model']);` |
| 🟡 建议 | L12, L14 | **拼写与命名不一致**：`AplicationController` 拼写错误；`$current_vresion` 拼写错误；属性命名混合驼峰与下划线。 | 修正拼写，统一使用 `camelCase` 命名类属性，遵循 PSR-12。 | `class MerchantAppServer extends ApplicationController`<br>`public $currentVersion = '2.0';` |
| 🟡 建议 | L118, L300+ | **魔法数字/硬编码泛滥**：如 `23142`、`600`、`533`、`10` 等无业务语义的常量散落各处。 | 提取为类常量或配置文件，添加明确注释。 | `const MERCHANT_CAMBODIA_ID = 23142;`<br>`const PAY_TYPE_MEMBER = 10;` |
| 🟡 建议 | 全文 | **PSR-12 规范缺失**：缩进不统一、超长行未换行、缺少类型声明、注释风格混杂。 | 使用 `PHP-CS-Fixer` 自动格式化；添加 `declare(strict_types=1);` 及参数类型提示。 | 配置 `.php-cs-fixer.php` 并执行 `php-cs-fixer fix`。 |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题（P0/P1）
1. **立即移除硬编码密钥**：将 `xfyun_tts_config` 迁移至环境变量或加密配置，并执行密钥轮换。
2. **修复密码验证逻辑**：全面排查 `_discount_pwd` 等密码字段，实施 `password_hash`/`password_verify` 迁移脚本。
3. **统一输入获取方式**：替换所有 `$_POST`/`php://input` 为 `$this->input->raw_input_stream`，确保全局 XSS 过滤生效。
4. **规范错误响应机制**：避免在控制器中直接 `exit`，改用异常机制或统一 JSON 响应中间件，保障 CI 生命周期完整。
### 🛠 后续重构与优化方向
1. **架构拆分（SRP 原则）**：
- 将 `index()` 中的 `switch` 逻辑改造为 **路由分发器** 或 **命令模式**。每个 `function` 对应一个独立的 Service 类方法。
- 鉴权、Token 解析、权限校验抽离至 `BaseController::initAuth()` 或 CI `pre_controller` Hook。
2. **性能优化**：
- 合并重复的模型加载与配置读取。
- 针对 `array_merge` 频繁操作大数组的场景，改用引用传递或按需构建。
- 对高频查询（如门店配置、权限列表）引入 CI Cache 或 Redis 缓存。
3. **工程规范落地**：
- 引入 `PHP-CS-Fixer` 与 `PHPStan` 进行静态检查与格式化。
- 为关键业务方法补充单元测试（PHPUnit），覆盖鉴权失败、参数异常、权限越权等边界条件。
- 若项目允许，建议逐步向 CI4 或现代 PHP 框架迁移，利用其内置的依赖注入、路由分组、中间件等特性降低耦合。
> ⚠️ **局限性说明**：由于提供的代码在 `case "1001"` 处截断，未能完整审查结账取消逻辑、数据库事务处理及并发控制部分。建议补充完整文件后，针对 `bill_frequency`、`open_room_log` 状态机流转进行二次专项审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780386491
|
1780386491
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
246
|
22
|
21
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 预订开房后去开房订单退款，更新自助营业两个报表
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `744f17de2 ## 自动代码审查报告
**分支**: app-260519
**提交**: `744f17de2f739b9a120bfdeded7621cd34a9c95a`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-20 17:10:29
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：业务逻辑覆盖较全面，支付、退款、营收统计等核心流程已实现。但代码存在**严重的安全隐患**（SQL注入、权限校验被注释）、**显著的性能瓶颈**（循环内N+1查询）、以及**框架使用不规范**（全局实例获取、原始SQL拼接、静态缓存污染）。整体可维护性与健壮性亟待提升。
- **风险等级**：🔴 高
---
## 2. 问题详情
| 严重程度 | 文件/方法 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_pay_log_model::update_refund_amount` | **SQL注入漏洞**：WHERE 条件与 UPDATE 语句直接使用字符串拼接，未做参数过滤或绑定，若 `$relation_id` 或 `$type` 来自外部输入将导致数据库被篡改或拖库。 | 严格使用框架查询构造器（Query Builder）或参数绑定，禁止手动拼接 SQL 片段。 | ```php<br>// 错误<br>$where = '_relation_id="'.$relation_id.'" and _type='.$type;<br><br>// 正确<br>$this->db->where('_relation_id', $relation_id)<br> ->where('_type', (int)$type)<br> ->where_in('_status', [1, 4]);<br>``` |
| 🔴 严重 | `Ahead_pay_log_model::refund` | **权限校验缺失**：退款核心逻辑中，权限检查代码被完整注释（`/*if ($admin_data['_user_type'] == 2)...*/`），任何持有该接口调用权限的用户均可执行退款，存在越权操作风险。 | 立即恢复权限校验逻辑，并将其封装为独立的权限拦截方法，结合 RBAC 机制进行统一拦截。 | ```php<br>if (!$this->check_refund_permission($admin_data, $order_data)) {<br> throwError('无退款权限');<br>}<br>``` |
| 🟠 警告 | `Ahead_pay_log_model::get_bill_pay_log` | **N+1 查询性能瓶颈**：在 `foreach ($log_data as &$v)` 循环内多次调用 `get_one()`、`get_custom_pay_platform()` 等数据库查询。若列表返回 50 条数据，将触发 150+ 次 SQL 查询，极易导致接口超时。 | 采用批量查询（`WHERE IN`）或 `JOIN` 预加载关联数据，将循环内查询移至循环外。 | ```php<br>// 收集所有关联ID后一次性查询<br$ids = array_column($log_data, 'relation_id');<br$extensions = $this->db->where_in('_order_id', $ids)->get('yc_order_extension')->result_array();<br$ext_map = array_column($extensions, null, '_order_id');<br>// 循环中直接读取 $ext_map[$v['relation_id']]<br>``` |
| 🟠 警告 | `Jh_community_shop_revenues_detail_model::get_date_type_info` | **静态缓存污染**：使用 `self::$date_type_info` 缓存门店相关的时间配置。在单次请求处理多门店数据或并发请求时，会返回错误的门店时间范围，导致报表数据错乱。 | 移除静态属性缓存，或改用带唯一键的缓存机制（如 CI Cache / Redis），键名需包含 `shop_id`。 | ```php<br>// 移除 public static $date_type_info;<br>// 改用实例属性或缓存<br$cache_key = "date_type_info_{$shop_id}";<br>$data = $this->cache->get($cache_key);<br>if (!$data) { /* 计算并缓存 */ }<br>``` |
| 🟠 警告 | `Ahead_pay_log_model::update_after_pay_call_back` | **类型比较隐患**：`$newPayLogData['_type'] == '1'` 使用松散比较，PHP 会自动转换类型。若数据库返回整型 `1`，逻辑可能产生非预期分支，且后续 `switch` 中字符串与整型混用。 | 统一数据类型，使用严格比较 `===` 或在入口处进行类型转换。 | ```php<br$type = (int)$newPayLogData['_type'];<br>if ($type === 1) { ... }<br>``` |
| 🟡 建议 | 全局 / 文件头部 | **框架规范不符**：文件顶部直接使用 `$CI = &get_instance();` 加载模型，违背 CI3/PHP 面向对象规范。模型依赖应在构造函数中初始化。 | 将模型加载移至 `__construct()`，遵循 PSR-12 与框架生命周期。 | ```php<br>public function __construct() {<br> parent::__construct();<br> $this->load->model('Simple_model');<br> $this->load->model('ahead_server_daily_income_model');<br>}<br>``` |
| 🟡 建议 | `Jh_community...::create_community_revenues_trend_data` | **日期计算缺陷**：`strtotime("+$i month", $start_time)` 在月末日期（如 1月31日）加月份时会溢出至 3月，导致时间轴数据缺失或错位。 | 使用 `DateTime` 对象或固定以每月 1 号为基准进行偏移计算。 | ```php<br>$date = new DateTime(date('Y-m-01', $start_time));<br>$date->modify("+{$i} month");<br>$key = $date->format('Ym');<br>``` |
| 🟡 建议 | 全局 | **魔法数字与拼写错误**：大量硬编码数字（如 `1, 2, 3, 15, 16`）未提取为常量；变量名存在拼写错误（如 `$date_type_gourp`）；存在过时注释（`// 之前不知道为啥被注释掉...`）。 | 提取业务枚举常量，清理冗余注释，统一命名规范。 | ```php<br>const PAY_PLATFORM_WECHAT = 1;<br>const PAY_PLATFORM_ALIPAY = 2;<br>const PAY_TYPE_INCOME = 1;<br>const PAY_TYPE_REFUND = 2;<br>``` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复 SQL 注入**：立即替换 `update_refund_amount` 及 `Jh_community...` 中所有原始 SQL 拼接逻辑，全面启用框架的查询构造器（Query Builder）或预处理语句。
2. **恢复权限控制**：取消 `refund` 方法中的权限注释，并在退款、账单修改等敏感接口前增加统一的中间件或基类权限校验。
3. **消除 N+1 查询**：重构 `get_bill_pay_log` 与 `get_refundable_pay_log`，将循环内的单条查询改为批量 `WHERE IN` 查询或 `LEFT JOIN`，预计可提升接口响应速度 5~10 倍。
### 🛠 后续重构与优化方向
- **事务管理规范化**：当前 `refund` 使用 `trans_begin()` + 手动 `trans_rollback()`。建议改用 CI3 推荐的 `$this->db->trans_start(); ... $this->db->trans_complete();`，配合异常捕获自动回滚，避免遗漏 `commit/rollback` 导致锁表。
- **错误处理统一化**：代码中混用 `throwError()`（疑似全局函数）与框架原生异常。建议统一使用 `throw new \Exception()` 或 CI3 的 `show_error()`，并在控制器层捕获处理，避免模型层直接中断请求。
- **常量与配置集中化**：将支付平台、订单类型、状态码等硬编码提取至独立的 `config/pay_platform.php` 或类常量中，降低后续业务变更的维护成本。
- **框架适配说明**：注：当前代码结构高度符合 **CodeIgniter 3** 规范。若项目实际运行于 `phpci` 框架，请确认其底层是否完全兼容 CI3 的 `load->model()`、`db->trans_*()` 等 API。若存在差异，建议查阅 `phpci` 官方文档替换为框架原生组件。
> 💡 **局限性提示**：本次审查基于提供的两个 Model 文件。支付回调、退款等核心链路通常涉及 Controller 路由、第三方 SDK 调用及前端交互，建议结合完整调用链进行端到端的安全与性能压测。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779268229
|
1779268229
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
245
|
22
|
20
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 1
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `7fee8c3d9 ## 自动代码审查报告
**分支**: app-260519
**提交**: `7fee8c3d9e1a261473bb091dfebc9a63a034cbd9`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-20 16:25:38
---
## 1. 审查摘要
- **代码质量评分**：5.5/10 分
- **总体评价**：代码实现了较为复杂的支付流水、退款及报表统计业务，整体功能完整。但存在**严重的 SQL 注入风险**、**明显的 N+1 查询性能瓶颈**以及**循环内状态变量污染**的逻辑缺陷。代码风格偏向传统 PHP 写法，未充分利用现代 PHP 特性与框架的安全机制，且金额计算缺乏精度控制。
- **风险等级**：🔴 高
*(注：代码结构高度符合 CodeIgniter 3 规范，若 `phpci` 为内部定制框架，以下建议基于 CI3/PHP 最佳实践，请结合框架底层查询构建器实现进行适配。)*
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `update_refund_amount` / `refund` | **SQL 注入漏洞**：多处使用字符串直接拼接构造 `WHERE` 和 `UPDATE` 子句（如 `'_relation_id="' . $relation_id . '"`），若传入恶意字符将直接破坏 SQL 结构或越权操作。 | 废弃字符串拼接，全面改用框架查询构建器或参数化查询。 | `$where = ['_relation_id' => $relation_id, '_type' => $type, '_status' => [1, 4]];`<br>`$this->db->where($where)->update($this->table_name, $data);` |
| 🔴 严重 | `refund` 方法 | **SQL 注入/语法错误**：`$sales_update` 字符串直接拼接 `$CI->admin_data['_name']`，未做转义或参数绑定，极易引发注入或 SQL 语法中断。 | 使用 `$this->db->set()` 方法或数组传参，框架会自动处理转义与类型安全。 | `$this->db->set('_refund_admin_name', $CI->admin_data['_name'] ?? '');`<br>`$this->db->where($sales_where)->update('ahead_songs_sales_pay_log');` |
| 🟠 警告 | `get_bill_pay_log` / `get_refundable_pay_log` | **N+1 查询性能瓶颈**：在 `foreach` 循环内频繁调用 `get_one()`、`get_custom_pay_platform()` 等数据库操作。若返回 100 条记录，将产生数百次额外查询，严重拖慢接口响应。 | 提前收集所有关联 ID，使用 `WHERE IN` 批量查询，在循环外构建映射数组（Map）进行内存匹配。 | `$ids = array_column($log_data, 'relation_id');`<br>`$orders = $this->model->get_by_ids($ids);`<br>`$orderMap = array_column($orders, null, '_id');`<br>`// 循环内直接 $orderMap[$v['relation_id']]` |
| 🟠 警告 | `get_refundable_pay_log` | **逻辑缺陷：状态变量污染**：`$is_can_refund` 在循环外初始化为 `true`，循环内一旦某条记录不可退款，该变量被置为 `false` 且**未重置**，导致后续所有记录的退款权限被错误标记。 | 将状态判断逻辑收敛至循环内部，使用局部变量记录当前项状态。 | `$current_can_refund = $this->ahead_yc_order_model->check_is_can_refund($order_data);`<br>`$data[$k]['order_is_can_refund'] = $current_can_refund;` |
| 🟠 警告 | `add_order_pay_log` / `get_business` | **金额精度丢失风险**：使用 `+` 或 `array_sum` 直接对浮点数进行累加计算，PHP 浮点数运算存在固有精度问题，可能导致财务对账差 1 分钱。 | 统一使用 `BCMath` 扩展函数（如 `bcadd`, `bcsub`）或转换为“分”进行整数运算。 | `$actual_pay = bcadd($actual_pay, $params['_actual_pay'], 2);`<br>`$sum = array_reduce($newData, fn($c, $i) => bcadd($c, $i['actual_pay'], 2), '0.00');` |
| 🟡 建议 | 类定义顶部 | **框架规范违规**：`$CI = &get_instance(); $CI->load->model('Simple_model');` 放在类外部全局执行，违反 MVC 生命周期，易引发内存泄漏或加载冲突。 | 移除全局代码，将模型加载移至构造函数或依赖注入。 | `public function __construct() { parent::__construct(); $this->load->model('Simple_model'); }` |
| 🟡 建议 | 全局/常量定义 | **魔法数字泛滥 & 类型不一致**：大量硬编码数字（如 `1, 2, 15, 16`）代表支付类型/状态，且常量键使用字符串 `'1'` 但比较时使用整数 `1`，易引发类型隐式转换 Bug。 | 提取为语义化类常量，统一键类型，增强可读性与类型安全。 | `const PAY_TYPE_WECHAT = 1;`<br>`const PAY_STATUS_PAID = 1;`<br>`if ($type === self::PAY_TYPE_ORDER) { ... }` |
| 🟡 建议 | `update_after_pay_call_back` | **同步回调阻塞风险**：支付成功回调内同步执行营收更新、地图数据准备、消费记录更新等重逻辑，易导致第三方回调超时重试，引发重复处理。 | 核心状态更新保留，非核心/耗时逻辑剥离至消息队列异步执行。 | `// 回调仅返回 success`<br>`$this->queue->push('ProcessPayCallback', $newPayLogData);` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即修复 SQL 注入漏洞**：全局搜索并替换所有字符串拼接的 SQL 语句（特别是 `WHERE` 和 `UPDATE` 子句）。务必使用框架提供的参数化查询或查询构建器。这是最高优先级的安全红线。
2. **修复退款权限判断逻辑 Bug**：在 `get_refundable_pay_log` 中，将 `$is_can_refund` 改为循环内局部变量，避免状态交叉污染导致前端退款按钮显示异常或越权退款。
3. **消除 N+1 查询**：对 `get_bill_pay_log` 和 `get_refundable_pay_log` 进行重构，采用“批量查询 + 内存映射”模式，预计可将接口响应时间降低 60% 以上，并显著降低数据库连接池压力。
### 🛠 后续重构与优化方向
- **财务计算标准化**：建立统一的金额计算工具类，强制使用 `BCMath` 或整数（分）运算，彻底杜绝浮点数精度问题。建议在数据库层也统一使用 `DECIMAL` 类型。
- **架构解耦与异步化**：支付回调（`update_after_pay_call_back`）和退款（`refund`）属于核心资金链路，建议引入事件总线（Event Dispatcher）或消息队列，将报表统计、地图数据同步、短信通知等非强一致性操作异步化，提升系统吞吐量与容错率。
- **规范与现代化**：
- 遵循 PSR-12 规范，补充类型声明（如 `public function refund(string $pay_id, float $refund_amount): bool`）。
- 废弃全局函数 `throwError`，改用 PHP 标准异常机制（`throw new \InvalidArgumentException(...)`），便于统一捕获与日志记录。
- 若 `phpci` 框架支持，建议启用自动事务模式（`$this->db->trans_start()` / `$this->db->trans_complete()`）替代手动 `trans_begin/commit/rollback`，防止异常中断导致事务未正确回滚。
- **⚠️ 局限性说明**：提供的代码在 `add_by_vip_recharge_order` 方法处被截断（`$t` 后中断），未能审查该方法及后续可能存在的关联逻辑。建议补充完整代码以便进行全链路评估。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779265538
|
1779265538
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
272
|
22
|
23
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 1
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `836f2d9ed ## 自动代码审查报告
**分支**: app-260519
**提交**: `836f2d9edc2f41bda7356d3937a68b1e9b9f943c`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-21 15:44:22
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了复杂的预订退款、支付回调及开房业务流程，具备一定的基础架构意识。但存在**金融级事务处理不当、循环内直接中断导致资金状态不一致、N+1 查询性能瓶颈、SQL 拼接注入风险**等核心缺陷。代码风格混合了 CI3 传统写法与现代规范，部分方法职责过重，可维护性有待提升。
- **风险等级**：🔴 高（涉及资金流转与外部支付 API，当前逻辑易导致账务不平或长事务锁表）
> 📌 **框架说明**：提交代码的目录结构、`$CI = &get_instance()`、`$this->load->model()` 及 `$this->db->trans_start()` 等特征高度符合 **CodeIgniter 3** 规范。若项目实际基于 `phpci`，请确认是否为 CI3 的定制分支。以下审查基于 CI3 架构与通用 PHP 最佳实践。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_book_order_change_pay_log_model.php`<br>`wx_refund()` 循环内 | **批量退款中断无补偿**：`foreach` 遍历退款时，若单笔失败直接 `return`，已成功的退款无法回滚或标记，极易导致财务对账不平。 | 采用**结果收集模式**。循环结束后统一判断，若存在失败项，记录失败明细并触发补偿/重试队列，而非直接中断。 | 见下方重构示例 |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`invalid_book()` / `refund_by_notify()` | **事务包裹外部 API**：`$this->db->trans_start()` 后直接调用微信/银联退款 API。网络超时会导致数据库长事务、连接池耗尽或死锁。 | **事务与外部调用解耦**。先更新本地状态为 `退款中` 并提交事务 → 调用 API → 根据回调/结果异步更新为 `退款成功/失败`。 | 见下方状态机示例 |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`refund_by_notify()` 约第 118 行 | **SQL 注入风险**：使用字符串拼接构造 WHERE 条件：`'_relation_id="' . $order_data['_id'] . '" and _status=1...'`，若 `_id` 未严格过滤将导致注入。 | 全面使用 CI 查询构建器或参数绑定，禁止手动拼接 SQL 片段。 | `$this->db->where('_relation_id', $order_data['_id'])`<br>`->where('_status', 1)`<br>`->where_in('_type', [5, 13])` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`get_list()` 循环内 | **N+1 查询性能瓶颈**：在 `foreach` 中逐条执行 `$this->ahead_yc_order_model->get_one()`，订单量稍大时数据库压力呈指数级上升。 | 收集所有 `relation_order_id`，使用 `where_in` 一次性查询，在 PHP 内存中建立映射关系。 | 见下方优化示例 |
| 🟠 警告 | 两个文件顶部 | **全局 `$CI` 滥用**：在类外部执行 `$CI = &get_instance();` 并加载模型。CI 模型实例化时 `$this` 已继承 CI 超对象，此写法易引发全局状态污染与重复加载。 | 删除文件顶部两行代码。在类方法内按需 `$this->load->model()`，或在 `__construct()` 中统一加载。 | `// 直接删除顶部 $CI = &get_instance(); 及 load 代码` |
| 🟠 警告 | `Ahead_book_order_change_pay_log_model.php`<br>`wx_refund()` 约第 105 行 | **未初始化变量直接使用**：`$result['msg'] = ...` 在部分分支中未定义 `$result` 数组，触发 PHP `Notice` 且可能返回脏数据。 | 方法开头初始化 `$result = ['status' => true, 'msg' => ''];`，或重构为直接返回标准结构。 | `$result = ['status' => true, 'msg' => '退款成功'];` |
| 🟡 建议 | 全局多处 | **魔法数字泛滥**：`1, 3, 4, 5, 8, 14, 17` 等硬编码表示支付平台、订单状态、业务场景，可读性差且极易误改。 | 提取为类常量或独立配置文件，统一引用。 | `const PAY_PLATFORM_WX = 1;`<br>`const STATUS_REFUNDED = 4;` |
| 🟡 建议 | 全局 | **PSR-12 规范不符**：方法命名混用 `snake_case` (`wx_refund`) 与 `camelCase` (`openRoomByCommunityOrder`)；`openRoomByCommunityOrder` 超 250 行，违反单一职责原则。 | 统一使用 `camelCase`；将大方法拆分为 `OrderRefundService`、`RoomOpenService` 等独立服务类。 | 遵循 PSR-12 命名规范 |
### 🔧 关键代码优化示例
**1. 批量退款安全处理（替代直接 `return`）**
```php
$failed_refunds = [];
foreach ($wx_refund_info as $refund_info) {
$api_res = $this->callRefundApi($refund_info); // 封装具体 API 调用
if ($api_res['result_code'] !== 'SUCCESS') {
$failed_refunds[] = [
'log_id' => $refund_info['log_id'],
'error' => $api_res['err_code_des'] ?? '退款失败'
];
}
}
if (!empty($failed_refunds)) {
// 记录失败明细，推入重试队列或返回给上层处理
doLog(var_export($failed_refunds, true), 'PartialRefundFailed');
return ['status' => false, 'msg' => '部分退款失败', 'data' => $failed_refunds];
}
return ['status' => true, 'msg' => '退款成功'];
```
**2. 事务与外部 API 解耦模式**
```php
// 错误做法：事务包裹 API
$this->db->trans_start();
$this->update(['_status' => 4], $where);
$api_res = $this->wx_refund(...); // 网络阻塞，事务未提交
if ($api_res['status']) $this->db->trans_complete();
else $this->db->trans_rollback();
// ✅ 正确做法：状态机 + 异步/补偿
$this->db->trans_start();
$this->update(['_status' => 3], $where); // 3: 退款处理中
$this->db->trans_complete();
$api_res = $this->wx_refund(...); // 独立调用，不持锁
if ($api_res['status']) {
$this->update(['_status' => 4], $where); // 4: 退款完成
} else {
$this->update(['_status' => 5], $where); // 5: 退款失败
// 触发告警或写入重试队列
}
```
**3. N+1 查询优化**
```php
// 原代码：循环内 get_one
// 优化后：
$relation_ids = array_filter(array_column($order_info, 'relation_order_id'));
$related_orders = [];
if ($relation_ids) {
$this->load->model('ahead_yc_order_model');
$related_orders = $this->ahead_yc_order_model->select(
['where_in' => ['_id', $relation_ids]],
'_id,_machine_name'
);
// 转为 key-value 映射
$related_orders = array_column($related_orders, null, '_id');
}
foreach ($order_info as &$v) {
$v['room_name'] = '';
if ($v['relation_order_id'] && isset($related_orders[$v['relation_order_id']])) {
$v['room_name'] .= ' - ' . $related_orders[$v['relation_order_id']]['_machine_name'];
}
}
```
---
## 3. 总结与行动建议
### 🚨 优先修复项（P0）
1. **重构退款事务逻辑**：立即将 `invalid_book` 与 `refund_by_notify` 中的外部支付 API 调用移出数据库事务。采用 `本地状态更新(处理中) → 提交事务 → 调用 API → 异步更新最终状态` 的模式，避免长事务拖垮数据库。
2. **修复批量退款中断缺陷**：`wx_refund` 循环中的 `return` 必须改为结果收集机制，确保资金流水可追溯，支持部分成功场景的财务对账。
3. **消除 SQL 拼接注入**：全局排查 `up()`、`select()` 等方法中手动拼接 WHERE 字符串的代码，统一替换为 CI 查询构建器或预处理参数。
### 🛠 后续重构方向
1. **架构分层**：当前 Model 承载了过多业务逻辑（支付、退款、开房、通知、打印）。建议引入 **Service 层**，将 `OrderRefundService`、`RoomOpenService`、`PaymentGatewayService` 独立出来，Model 仅负责数据持久化。
2. **常量与配置集中化**：将支付平台枚举、订单状态、业务场景等魔法数字提取至 `config/constants.php` 或类常量中，提升代码可读性与后期维护效率。
3. **性能治理**：除已指出的 N+1 查询外，建议对高频查询字段（如 `_status`, `_merchant_id`, `_shop_id`）补充复合索引；对 `doLog()` 日志输出进行脱敏处理，避免敏感交易信息明文落盘。
4. **规范统一**：严格遵循 PSR-12 规范，统一方法命名为 `camelCase`，补充完整 PHPDoc 类型声明，便于静态分析工具（如 PHPStan/Psalm）介入。
> ⚠️ **局限性说明**：`Ahead_book_order_model.php` 末尾代码被截断（`'_prime_service_charge' => 0,` 后缺失闭合括号与方法结尾），无法评估 `_add_order_data` 的完整逻辑。请提供完整文件以便进行闭环审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779349463
|
1779349463
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
273
|
22
|
24
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 1
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `8568f7701 ## 自动代码审查报告
**分支**: app-260519
**提交**: `8568f7701290cf3ef3c1ed10b0142e91fe86fe45`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-21 15:46:31
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了较为复杂的预订、退款、开房及社区业务逻辑，功能完整度较高。但存在明显的架构设计问题：方法过长违反单一职责原则（SRP）、事务管理不规范、存在 SQL 拼接隐患、循环内查询导致 N+1 性能瓶颈，且全局变量滥用与命名不一致降低了可维护性。
- **风险等级**：🔴 高（涉及资金退款、事务一致性、SQL 安全及并发状态污染）
> 📌 **框架说明**：从目录结构、`$CI = &get_instance();`、`$this->db`、`$this->load->model()` 等特征判断，该代码高度符合 **CodeIgniter 3** 架构规范。以下审查基于 CI3 最佳实践及通用 PHP 安全/性能标准。若 `phpci` 为内部定制框架，请对照其官方文档调整组件调用方式。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `refund_by_notify` 约第 118 行 | **SQL 注入风险**：使用字符串拼接构造 `$log_where`，若 `_id` 未严格过滤或类型转换，将导致注入。 | 使用框架 Query Builder 或参数化查询替代硬拼接。 | `$this->db->where('_relation_id', $order_data['_id'])->where('_status', 1)->where_in('_type', [5, 13])->update('table', $log_up);` |
| 🔴 严重 | 全局第 5-6 行 | **全局 `$CI` 实例化污染**：在类外部直接调用 `get_instance()`，每次请求无论是否调用该 Model 都会执行，浪费内存且破坏封装。 | 移除文件顶部全局 `$CI`，在方法内部按需使用 `$this->load->model()` 或 `$this->db`。 | `// 删除顶部 $CI = &get_instance(); 及 $CI->load->model();` |
| 🔴 严重 | `invalid_book` / `openRoomByCommunityOrder` | **事务管理混乱**：混用 `trans_start()`、手动 `trans_rollback()` 与 `trans_complete()`。CI3 的 `trans_complete()` 会自动回滚，手动回滚后若未正确退出，可能导致连接状态异常。 | 改用显式事务控制：`trans_begin()` → `try { ... trans_commit(); } catch { trans_rollback(); throw; }`。 | `try { $this->db->trans_begin(); /* 业务逻辑 */ $this->db->trans_commit(); } catch (\Exception $e) { $this->db->trans_rollback(); throw $e; }` |
| 🟠 警告 | `get_list` / `get_detail` | **N+1 查询性能瓶颈**：在 `foreach` 循环中调用 `get_one()` 关联查询订单/包厢信息，数据量大时数据库压力剧增。 | 收集所有 `relation_order_id`，使用 `where_in` 批量查询后映射到数组。 | `$ids = array_column($order_info, 'relation_order_id'); $orders = $this->ahead_yc_order_model->where_in('_id', $ids)->get()->result_array(); $map = array_column($orders, null, '_id');` |
| 🟠 警告 | `invalid_book` 约第 68 行 | **业务逻辑隐患**：注释掉了 `$book_order['_arrival_time'] > time()` 校验，直接按状态退款。可能导致已过期或已使用的订单被误退款。 | 恢复时间校验或明确业务规则，增加状态机校验（如 `in_array($status, [1, 3])`）。 | `if ($book_order['_status'] == 1 && $book_order['_arrival_time'] > time()) { /* 退款逻辑 */ }` |
| 🟠 警告 | 多处方法 | **魔法数字泛滥**：大量使用 `1, 2, 3, 4, 5, 8, 9, 14, 17` 等硬编码表示状态、支付渠道、业务类型，可读性差且易改错。 | 在类顶部定义 `const` 常量或枚举类。 | `const STATUS_PAID = 1; const STATUS_REFUND_DONE = 4; const PAY_WECHAT = 1;` |
| 🟠 警告 | `openRoomByCommunityOrder` | **方法过长违反 SRP**：单方法超 300 行，混合了参数校验、订单创建、事务、支付通知、日志、打印、消息推送等职责。 | 拆分为独立 Service 类（如 `CommunityRoomService`），Model 仅负责数据持久化。 | `// 将开房核心逻辑抽离至 service 层，Model 仅保留数据读写方法。` |
| 🟡 建议 | 全局 | **命名不一致**：混用 `setTablename()` 与 `set_table_name()`，且直接修改 `$this->table_name` 在并发请求下可能引发状态串扰。 | 统一命名规范，优先使用 Query Builder 的 `from()` 或 `table()` 方法指定表名，避免修改 Model 实例属性。 | `$this->db->from($this->table_name . ' a')->join(...)->get();` |
| 🟡 建议 | `openRoomByCommunityOrder` catch 块 | **异常信息吞没**：`catch (Exception $e) { throwError("网络错误请稍后重试"); }` 丢失了原始堆栈，极难排查线上问题。 | 记录详细日志后抛出业务异常，或返回结构化错误码。 | `log_message('error', '开房失败: ' . $e->getMessage() . ' | ' . $e->getTraceAsString()); throwError('系统繁忙，请稍后重试');` |
| 🟡 建议 | 全局 | **PSR-12 规范缺失**：缺少类型声明、返回值类型、部分缩进不一致、注释风格不统一。 | 补充 `declare(strict_types=1);`，为公开方法添加 `@param`/`@return` 及 PHP 8 类型提示（若环境支持）。 | `public function get_list(int $merchant_id, array $param): array { ... }` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复 SQL 注入隐患**：立即将 `refund_by_notify` 中的 `$log_where` 字符串拼接替换为 Query Builder 链式调用或预处理语句。
2. **规范事务控制**：统一采用 `trans_begin()` + `try/catch` + `trans_commit()/trans_rollback()` 模式，移除冗余的手动回滚调用，确保资金操作的数据强一致性。
3. **消除全局 `$CI` 滥用**：删除文件顶部的 `get_instance()`，所有依赖通过 `$this->load->model()` 或依赖注入获取。
4. **优化 N+1 查询**：在 `get_list` 和 `get_detail` 中，将循环内的单条查询改为批量 `where_in` 查询，内存映射后填充数据。
### 🛠 后续重构与优化方向
- **架构分层**：当前 Model 承载了过多业务逻辑（支付网关调用、消息推送、打印、状态机流转）。建议引入 **Service 层**，将 `refund_by_notify`、`openRoomByCommunityOrder` 等复杂流程抽离至 `BookOrderService`、`CommunityRoomService`，Model 仅保留数据读写与基础校验。
- **状态机与常量管理**：建立统一的 `OrderStatus`、`PayPlatform`、`RefundType` 常量类或枚举，替代魔法数字，提升代码自解释能力。
- **防御性编程**：对关键金额字段（如 `_actual_pay`、`refund_fee`）增加 `is_numeric()` 或 `bccomp()` 校验，避免浮点数精度丢失；对第三方 API 调用增加超时与重试机制。
- **代码截断说明**：提供的代码在 `_add_order_data` 方法末尾突然中断，未能审查完整逻辑。若该方法涉及金额计算或订单组装，请补充完整代码以便进行深度财务逻辑校验。
> 💡 **提示**：若 `phpci` 框架对事务或 Query Builder 有特定封装（如 `Db::transaction()` 或 `Model::query()`），请将上述建议替换为框架原生 API，并查阅官方文档确认最佳实践。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779349591
|
1779349591
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
450
|
22
|
51
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 1
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `900258a12 ## 自动代码审查报告
**分支**: app-260519
**提交**: `900258a1291f0558e08644cef69b1313517a8ea8`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 10:14:39
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：业务逻辑覆盖较完整，能处理复杂的预订、退款、开房及多支付渠道场景。但代码存在明显的“上帝类”倾向，方法冗长、职责混杂；事务边界管理不严谨，存在 SQL 拼接隐患与 N+1 查询性能瓶颈；魔法数字泛滥，可维护性与扩展性较弱。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 文件顶部 (1-3行) | 在类外部直接执行 `$CI = &get_instance();` 并加载模型。每次 `include/require` 该文件都会执行，易导致重复加载、上下文污染或内存泄漏。 | 移至类的 `__construct()` 构造函数中，或使用框架的自动加载机制。 | `public function __construct() { parent::__construct(); $this->load->model('Simple_model'); }` |
| 🔴 严重 | `refund_by_notify` 约第108行 | `$log_where` 使用字符串拼接构造 SQL 条件：`'_relation_id="' . $order_data['_id'] . '" and ...'`。若 `_id` 未严格校验，存在 SQL 注入风险，且违背框架查询构建器规范。 | 使用框架提供的查询构建器或参数绑定，彻底杜绝字符串拼接 SQL。 | `$this->db->where('_relation_id', $order_data['_id'])->where('_status', 1)->where_in('_type', [5, 13]);` |
| 🔴 严重 | `invalid_book` / `openRoomByCommunityOrder` / `notifyCommunityBookOrder` | **事务嵌套与手动回滚冲突**。CI 架构下事务通过计数器管理，在已开启事务的方法中调用含 `trans_start/rollback` 的子方法，或手动调用 `trans_rollback()`，极易破坏事务计数器，导致数据不一致或提前提交。 | 统一事务边界。仅在顶层业务方法开启事务，子方法仅返回状态或抛出异常，不直接操作事务生命周期。 | 顶层使用 `try { $this->db->trans_start(); ... $this->db->trans_complete(); } catch(\Exception $e) { $this->db->trans_rollback(); throw $e; }` |
| 🟠 警告 | `get_list` / `get_detail` 循环体 | **N+1 查询性能瓶颈**。在 `foreach` 中循环调用 `$this->ahead_yc_order_model->get_one()` 获取关联数据，数据量增大时将引发严重数据库压力。 | 收集所有关联 ID，使用 `where_in` 批量查询，或在主查询中使用 `JOIN` 一次性拉取，再在内存中映射。 | `$ids = array_column($order_info, 'relation_order_id'); $orders = $this->ahead_yc_order_model->where_in('_id', $ids)->get()->result_array();` |
| 🟠 警告 | 全局多处 | **魔法数字泛滥**。大量使用 `1,2,3,4,5,8,9,14,17` 等硬编码表示状态、支付渠道、业务模式，可读性差且极易因版本迭代引发逻辑错乱。 | 提取为类常量或独立配置类，统一命名管理。 | `const STATUS_PAID = 1; const PAY_PLATFORM_WX = 1; const BUSINESS_MODEL_COMMUNITY = 2;` |
| 🟡 建议 | `refund_by_notify` / `openRoomByCommunityOrder` | **违反单一职责原则 (SRP)**。单个方法超过 150 行，混合了状态更新、外部 API 调用、日志记录、消息推送、打印机控制等逻辑，难以测试与维护。 | 按业务域拆分。将退款、订单创建、通知推送、硬件交互等抽取为独立 Service 类或私有方法。 | 创建 `RefundService::process()`, `OrderNotifyService::send()`, `PrinterService::print()` 等。 |
| 🟡 建议 | 全局多处 | **松散比较与类型不严谨**。如 `$is_refund == '1'`、`$invalid_type != '4'`，PHP 松散比较易引发隐式类型转换漏洞。 | 统一使用严格比较 `===`，并在方法入口进行类型断言或强制转换。 | `if ((int)$is_refund === 1)` 或 `if ($invalid_type !== '4')` |
| 🟡 建议 | 全局多处 | **模型重复加载**。多处重复调用 `$this->load->model(...)`，增加框架解析开销。 | 高频依赖模型在构造函数中统一加载，或配置自动加载。 | `public function __construct() { parent::__construct(); $this->load->model(['model_a', 'model_b']); }` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复 SQL 拼接隐患**：立即将 `refund_by_notify` 中的 `$log_where` 字符串拼接替换为查询构建器或参数绑定，杜绝注入风险。
2. **重构事务管理**：梳理 `invalid_book`、`openRoomByCommunityOrder` 及其调用链的事务边界。移除子方法中的 `trans_start/rollback`，统一在顶层使用 `try-catch` 包裹事务，确保异常时能正确回滚。
3. **消除 N+1 查询**：对 `get_list` 和 `get_detail` 中的循环查询进行批量优化，使用 `JOIN` 或 `where_in` 批量获取关联数据，降低数据库 IO 压力。
### 🛠 后续重构与优化方向
1. **架构拆分**：当前 Model 承担了过多 Controller/Service 的职责。建议引入 Service 层处理复杂业务流（如退款、开房、通知），Model 层仅负责数据持久化与基础查询。
2. **常量/枚举化**：建立全局状态字典或配置类，替换所有魔法数字。可结合 PHP 8.1+ 的 `enum` 特性（若环境支持）提升类型安全。
3. **统一异常处理**：当前混用 `throwError()` 与 `try-catch`。建议统一使用标准 `Exception` 或框架内置异常类，配合全局异常处理器返回标准化错误响应。
4. **代码规范对齐**：严格遵循 PSR-12，统一方法命名（如 `setTablename` 与 `set_table_name` 混用）、缩进与注释规范。
> 📌 **框架适配说明**：代码呈现典型的 CodeIgniter 架构特征（如 `get_instance()`、`$this->load->model()`、`$this->db->trans_start()`）。若 `phpci` 为内部定制框架，其事务计数器机制或模型加载策略可能与原生 CI 存在差异，请务必查阅 `phpci` 官方文档中关于 **事务嵌套** 与 **模型生命周期** 的说明，并据此调整上述建议。
>
> ⚠️ **局限性提示**：提供的代码在 `_add_order_data` 方法末尾截断，未能完整审查该辅助方法及后续逻辑。建议补充完整代码以便进行全链路数据流与边界条件验证。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780366479
|
1780366479
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
143
|
22
|
3
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 0519
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `b8292b8a8 ## 自动代码审查报告
**分支**: app-260519
**提交**: `b8292b8a832fb77ffc57d9ed036a5b2f6eced983`
**提交人**: zhangjunnan (121158035@qq.com)
**时间**: 2026-05-18 17:53:43
---
## 1. 审查摘要
- **代码质量评分**：4.5 / 10 分
- **总体评价**：代码实现了较为完整的商家端业务逻辑与支付回调流程，但存在大量历史遗留问题。核心隐患集中在**敏感信息硬编码**、**PHP 8 兼容性断裂**、**密码明文处理**以及**控制器职责过重**。Redis 辅助函数设计存在性能瓶颈与并发风险，部分测试代码未清理即上线。整体可维护性与安全性亟待重构。
- **风险等级**：🔴 高
> 📌 **框架说明**：代码结构、加载方式（`$this->load->`、`BASEPATH`、`CI_DB`）高度符合 **CodeIgniter 3.x** 规范。若 `phpci` 为贵司内部定制框架，请结合其官方文档对底层组件加载方式做适配调整。以下建议基于标准 PHP 7.4+/8.x 及 CI3 最佳实践。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `common_helper.php` (多处) | **敏感密钥硬编码**：阿里云 AK/SK 及科大讯飞 API 密钥直接写在代码中，极易通过版本库泄露，导致云资源被盗刷。 | 立即迁移至配置文件（如 `config/aliyun.php`）或环境变量，通过 `$this->config->item()` 或 `$_ENV` 读取。 | `$ak = getenv('ALIYUN_ACCESS_KEY_ID') ?: $this->config->item('aliyun_ak');` |
| 🔴 严重 | `common_helper.php` (~L1050) | `decodeUnicode` 使用已废弃的 `create_function`，**PHP 8.0+ 将直接抛出 Fatal Error 导致服务崩溃**。 | 替换为现代匿名函数（Closure）。 | `return preg_replace_callback('/\\\\u([0-9a-f]{4})/i', function($m){ return mb_convert_encoding(pack("H*", $m[1]), "UTF-8", "UCS-2BE"); }, $str);` |
| 🔴 严重 | `common_helper.php` (~L680) | `rs_hmset` 函数被**重复定义两次**，PHP 解析时会触发 `Fatal error: Cannot redeclare`，直接阻断脚本执行。 | 删除第二个重复的 `if (!function_exists('rs_hmset')) { ... }` 代码块。 | （直接删除重复定义段） |
| 🔴 严重 | `MerchantAppServer.php` (~L450) | 修改打折密码时直接比对明文：`$data['_discount_pwd'] != $_old_password`。违反安全基线，且数据库若泄露将导致批量撞库。 | 密码必须使用 `password_hash()` 存储，验证使用 `password_verify()`。 | `if (!password_verify($_old_password, $data['_discount_pwd'])) { $this->error_response('旧密码不正确'); }` |
| 🔴 严重 | `WxNotify.php` (~L25, ~L55) | `try-catch` 块中 `$notify` 在 `try` 内部实例化。若实例化前抛异常，`catch` 中调用 `$notify->SetReturn_code()` 将触发 `Undefined variable` 错误，导致微信/支付宝收不到标准响应而重复回调。 | 将 `$notify = new WxPayNotify();` 移至 `try` 外部，或在 `catch` 中安全实例化。 | `$notify = new WxPayNotify(); try { ... } catch(Exception $e) { $notify->SetReturn_code("FAIL"); ... }` |
| 🟠 警告 | `MerchantAppServer.php` (~L45) | `__construct` 承载鉴权、配置、DB、时区、日志等逻辑，且 `json_decode` 未做错误处理。若传入非法 JSON，后续数组访问将触发 Warning/Notice 并污染业务流。 | 鉴权逻辑抽离至基类控制器或中间件；增加 JSON 解析校验。 | `$this->stream = json_decode($this->stream, true); if (json_last_error() !== JSON_ERROR_NONE) { $this->error_response('请求参数JSON格式错误'); }` |
| 🟠 警告 | `common_helper.php` (~L580) | Redis 辅助函数每次调用都执行 `connect()` 和 `close()`。高并发下频繁创建/销毁 TCP 连接，极易耗尽文件描述符并引发性能雪崩。 | 使用 CI 内置 Redis 驱动或实现连接池复用，避免手动 `close()`。 | 建议统一使用 `$this->load->driver('cache', ['adapter' => 'redis']);` 管理连接生命周期。 |
| 🟠 警告 | `common_helper.php` (~L630) | `rs_incrByFloat` 使用 `is_float($float)` 校验。PHP 中浮点数常以字符串形式传入（如 `'0.00'`），该判断会直接返回 `false` 导致逻辑失效。 | 改用 `is_numeric()` 进行安全校验。 | `if (!empty($keyName) && is_numeric($float)) { ... }` |
| 🟠 警告 | `WxNotify.php` (~L115) | 支付宝验签公钥硬编码为 `"test"`，且残留 `aliHallNativeNotifytest` 调试方法。线上支付回调将因验签失败而中断，测试代码增加攻击面。 | 从配置读取真实公钥；彻底删除 `test` 后缀方法及双分号等语法瑕疵。 | `$aopClient->alipayPublicKey = $this->config->item('alipay_public_key');` |
| 🟡 建议 | `MerchantAppServer.php` (~L100) | `index()` 方法超 500 行，包含大量 `switch-case` 路由分发。违反单一职责原则（SRP），难以进行单元测试与后续迭代。 | 按业务域拆分至独立 Controller，或使用 CI 路由配置替代手动 `switch`。 | 将 `case '0005'` 移至 `MerchantAppLogin.php`，`case '00063'` 移至 `MerchantAppPrinter.php`。 |
| 🟡 建议 | `Ahead_ai_vending_cabinet_shelf_model.php` (~L180) | `create_qrcode` 使用递归处理批量生成。当未生成码的柜子较多时，易触发 `Maximum function nesting level` 错误。 | 改为 `while` 循环或交由消息队列异步处理。 | `while (!empty($cabinet)) { $cabinet_id = array_shift($cabinet); ... }` |
| 🟡 建议 | 全局 | 存在大量魔法数字（如 `23142`, `0777`, `500000`）及未定义常量（`BRANCHNAME`, `DEBUG_VERSION`）。`@mkdir($dirname, 0777)` 权限过大。 | 提取为类常量或配置文件；日志目录权限改为 `0755`；明确常量定义来源。 | `const MERCHANT_CAMBODIA_ID = 23142;`<br>`@mkdir($dirname, 0755, true);` |
---
## 3. 总结与行动建议
### 🚨 优先修复的关键问题（P0）
1. **移除硬编码密钥**：立即将阿里云 AK/SK、科大讯飞密钥、支付宝公钥迁移至安全配置中心或环境变量，并轮换已泄露的旧密钥。
2. **修复 PHP 8 兼容性**：替换 `create_function`，删除重复的 `rs_hmset` 定义，否则升级 PHP 版本将直接导致服务宕机。
3. **密码安全改造**：废弃明文密码比对逻辑，全面接入 `password_hash()` / `password_verify()` 标准加密方案。
4. **支付回调容错**：修复 `WxNotify.php` 中 `$notify` 变量作用域问题，确保第三方回调始终能收到标准 XML/JSON 响应，避免资金对账异常。
### 🛠 后续重构与优化方向
1. **架构瘦身**：`MerchantAppServer.php` 的 `__construct` 和 `index()` 已演变为“上帝类”。建议引入 **路由分发机制** 或 **中间件** 处理 Token 校验、权限拦截与日志记录，控制器仅保留业务编排逻辑。
2. **Redis 连接治理**：废弃当前每次请求新建连接的 Helper 模式。改用 CI 官方 `Cache` 驱动或 `Predis` 连接池，将 `connect/close` 交由框架生命周期管理，预计可降低 30%~50% 的 I/O 延迟。
3. **异步化改造**：`control_line` 中的 `usleep(500000)` 会阻塞 PHP-FPM 工作进程。建议将硬件控制指令投递至 Redis 队列或 RabbitMQ，由独立 Worker 消费执行，提升接口响应速度。
4. **代码规范对齐**：逐步引入 `PHP_CodeSniffer` 配合 `PSR-12` 规则集进行静态扫描；统一命名规范（类名 `PascalCase`，方法/变量 `camelCase`，常量 `UPPER_SNAKE_CASE`）；补充类型声明（Type Hints）以提升 IDE 提示与静态分析能力。
> ⚠️ **局限性说明**：提供的 `MerchantAppServer.php`、`common_helper.php` 及 `Ahead_ai_vending_cabinet_shelf_model.php` 末尾存在代码截断（如 `if (isset($`、`$this-` 等语法未完成）。本次审查基于可见代码片段进行，若截断部分包含核心事务处理或敏感逻辑，请补充完整后再次提交审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779098024
|
1779098024
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
330
|
22
|
35
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 需求 订单回执
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `bb7c35b05 ## 自动代码审查报告
**分支**: app-260519
**提交**: `bb7c35b05eb2515e2a121fc31bf84e7d1c9d9947`
**提交人**: chenjunfeng (developer.jeff.c@gmail.com)
**时间**: 2026-05-26 15:31:55
---
## 1. 审查摘要
- **代码质量评分**：4 / 10 分
- **总体评价**：代码呈现典型的早期 CodeIgniter 3 架构风格（注：项目结构及 `get_instance()`、`$this->load->model()` 等用法高度契合 CI3，若 `phpci` 为内部定制框架，核心规范仍适用）。整体存在较多历史技术债务，包含**硬编码敏感凭证、已废弃 PHP 语法、非原子 Redis 操作、性能反模式及逻辑缺陷**。代码可读性与可维护性较低，未遵循现代 PHP (PSR-12) 规范，需进行系统性重构。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `common_helper.php`<br>`alioss_deleteObject` / `alioss_addObject` | **硬编码云厂商 AccessKey/SecretKey**，极易导致 OSS 资源被盗刷、数据泄露或恶意篡改。 | 立即将凭证迁移至配置文件或环境变量，通过框架配置加载。 | `'accessId' => getenv('ALI_OSS_ACCESS_KEY') ?? config_item('ali_oss.access_id')` |
| 🔴 严重 | `common_helper.php`<br>`decodeUnicode` | 使用 `create_function()`，该函数在 PHP 7.2 已废弃，**PHP 8.0+ 将直接抛出致命错误**。 | 替换为现代匿名函数（Closure）。 | `return preg_replace_callback('/\\\\u([0-9a-f]{4})/i', function($m) { return mb_convert_encoding(pack("H*", $m[1]), "UTF-8", "UCS-2BE"); }, $str);` |
| 🔴 严重 | `common_helper.php`<br>`doBatchFromTable` | **逻辑缺陷**：`foreach` 中 `$data` 为值拷贝，修改 `$data[$k]` 不会同步回 `$list`，导致函数实际无效。 | 直接赋值回原数组对应键。 | `foreach ($list as $k => $data) { $list[$k] = doSingleFromTable($data); } return $list;` |
| 🔴 严重 | `common_helper.php`<br>`getFirstCharter` | 使用 `$str{0}` 语法，PHP 7.4 已废弃，**PHP 8.0 将报 Fatal Error**。 | 统一改为方括号数组访问 `$str[0]`。 | `$fchar = ord($str[0]);` |
| 🟠 警告 | `common_helper.php`<br>`rs_*` 系列函数 | **严重性能瓶颈**：每次调用都通过 `get_aliyun_redis_conn()` 新建连接并 `close()`，高频调用将耗尽连接池并拖慢响应。 | 采用单例模式或复用 CI 内置 Redis 驱动，保持长连接/连接池复用。 | `static $redis = null; if(!$redis) $redis = get_aliyun_redis_conn(); return $redis->sMembers($keyName);` |
| 🟠 警告 | `common_helper.php`<br>`rs_set` | **竞态条件**：先 `exists()` 再 `set()` 非原子操作，高并发下可能覆盖其他进程写入的值。 | 直接使用 Redis 的 `NX` 选项保证原子性。 | `$obj->set($keyName, $string, ['nx' => true, 'ex' => $expireTime]);` |
| 🟠 警告 | `common_helper.php`<br>`doRedisLockRelease` | **非原子解锁**：先 `GET` 校验再 `DEL`，校验与删除之间存在时间窗口，可能误删其他客户端持有的锁。 | 使用 Lua 脚本保证 `GET` 与 `DEL` 的原子性。 | `$lua = 'if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end'; return $redis->eval($lua, [$key, $value], 1);` |
| 🟠 警告 | `Ahead_shop_config_second_model.php`<br>`get_shop_setting` | **缓存键冲突**：`self::$shop_config[$shop_id]` 仅以门店ID为键，未结合商户ID，多租户架构下极易串数据。 | 使用复合键缓存。 | `$cacheKey = "{$merchant_id}_{$shop_id}"; if (empty(self::$shop_config[$cacheKey])) { ... self::$shop_config[$cacheKey] = ... }` |
| 🟠 警告 | `common_helper.php`<br>`curlRequest` | `CURLOPT_SSLVERSION` 设为 `1` (SSLv3) 已被现代 TLS 协议废弃，新版 cURL 可能报错或降级为不安全协议。 | 强制使用 TLSv1.2+。 | `curl_setopt($curl, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);` |
| 🟡 建议 | `common_helper.php`<br>`get_mac_by_url` | Helper 中频繁调用 `get_instance()` 加载 Model 违反 MVC 分层原则，且 URL 解析逻辑冗长脆弱。 | 将业务查询逻辑下沉至 Model/Service 层，Helper 仅保留纯字符串处理。 | 提取 `UrlResolverService::resolveMac($url)` |
| 🟡 建议 | `common_helper.php`<br>`passport_encrypt/decrypt` | 自定义 XOR 加密算法强度极低，且使用已废弃的 `srand()`。不符合现代安全标准。 | 替换为 `openssl_encrypt()` 或 CI 内置 `Encryption` 库。 | `openssl_encrypt($str, 'AES-256-CBC', $key, 0, $iv);` |
| 🟡 建议 | `Ahead_shop_config_second_model.php`<br>类外部 `$CI` | 在类外部定义 `$CI = &get_instance();` 不符合 CI 模型实例化机制，可能导致上下文污染。 | 移除全局 `$CI`，在方法内按需 `$this->load->model()` 或通过构造函数注入。 | `public function __construct() { parent::__construct(); $this->load->model('Simple_model'); }` |
| 🟡 建议 | `common_helper.php`<br>`parseQrcodeContent` | 依赖外部 `zxing.org` 且使用正则解析 HTML，存在 **SSRF 风险** 且极易因目标站改版失效。 | 引入本地二维码解析扩展（如 `endroid/qr-code` 或 `chillerlan/php-qrcode`）。 | 使用 Composer 引入成熟库替代 HTTP 请求 |
> 📝 **局限性说明**：`common_helper.php` 末尾的 `import($file)` 函数代码被截断，无法完整评估其文件加载逻辑与安全性。建议补充完整代码以便进一步审查。
## 3. 总结与行动建议
### 🚨 优先修复项（P0）
1. **移除硬编码凭证**：立即将阿里云 AK/SK、数据库密码、固定 IP 等敏感信息迁移至 `.env` 或框架配置中心，杜绝泄露风险。
2. **兼容 PHP 8+**：全局替换 `create_function`、`$str{0}`、`srand()` 等已废弃语法，确保系统可平滑升级至现代 PHP 版本。
3. **修复数据操作 Bug**：修正 `doBatchFromTable` 的无效赋值逻辑，避免业务层数据转换静默失败。
### 🛠 架构与性能优化方向
1. **Redis 连接复用**：废弃“每次调用新建/关闭连接”的模式。建议封装 `RedisClient` 单例类，或使用 CI 的 `Cache` 驱动统一管理，降低网络开销。
2. **分层重构**：`common_helper.php` 已演变为“上帝文件”，混杂了 URL 解析、加密、OSS、短信、Redis、日志、排序等数十种职责。建议按领域拆分为 `services/` 目录下的独立类，Helper 仅保留轻量级工具函数。
3. **原子性保障**：所有分布式锁、缓存写入操作必须保证原子性。优先使用 Redis 原生命令（如 `SET NX EX`）或 Lua 脚本，避免 `GET` + `SET/DEL` 组合。
4. **规范与类型安全**：逐步引入 PHP 7.4+/8.0 类型声明（`declare(strict_types=1);`、参数类型、返回值类型），统一遵循 PSR-12 编码规范，提升代码可测试性与 IDE 支持度。
### 📖 框架适配提示
当前代码结构高度依赖 **CodeIgniter 3** 的生命周期（如 `BASEPATH` 守卫、`get_instance()`、`$this->load->model()`）。若项目确为 `phpci` 定制框架，请确认其是否完全兼容 CI3 的 Loader 机制。对于不确定的框架特定组件（如 `Simple_model` 基类行为、`throwError` 全局函数），建议查阅 `phpci` 官方文档或内部架构规范，确保异常处理与模型加载符合框架设计哲学。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779780715
|
1779780715
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
468
|
22
|
55
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 1
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `cba73c16a ## 自动代码审查报告
**分支**: app-260519
**提交**: `cba73c16a1126fa6360fe68b6349e638ce336128`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 15:51:41
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了商家端核心业务路由与鉴权逻辑，但存在严重的安全硬编码、密码明文比对隐患、控制器职责过重（God Class）及大量魔法数字。整体架构偏向过程式堆砌，缺乏面向对象封装与配置化管理，可维护性与扩展性较差。
- **风险等级**：🔴 高
> 📌 **框架说明**：代码结构、加载方式（`$this->load->`、`$this->db->`、`defined('BASEPATH')`）高度契合 **CodeIgniter 3** 规范。若 `phpci` 为内部定制框架，部分生命周期与组件行为请以官方文档为准。本审查基于 CI3 最佳实践进行。
> ⚠️ **局限性说明**：代码在 `case "1001"` 处被截断，后续逻辑无法评估。以下审查基于已提供片段。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `~330行` | **敏感信息硬编码**：科大讯飞 TTS 的 `APISecret`、`APIKey` 直接写在控制器中，极易随代码库泄露。 | 移至环境变量或受保护的配置文件（如 `application/config/secrets.php`），通过 `getenv()` 或 `$this->config->item()` 读取。 | `// config/secrets.php<br>'xfyun' => [<br> 'app_id' => getenv('XFYUN_APPID'),<br> 'api_key' => getenv('XFYUN_APIKEY'),<br> 'api_secret' => getenv('XFYUN_APISECRET')<br>]<br>// 控制器中<br>$config = $this->config->item('xfyun');` |
| 🔴 严重 | `~480行` | **密码明文比对**：`$data['_discount_pwd'] != $_old_password` 暗示密码可能以明文或弱哈希存储，违反安全基线。 | 数据库必须存储 `password_hash()` 生成的哈希值，验证时使用 `password_verify()`。 | `if (!password_verify($_old_password, $data['_discount_pwd'])) {<br> $this->error_response('旧密码不正确');<br>}<br>$new_hash = password_hash($_new_password1, PASSWORD_DEFAULT);<br>$this->ahead_yc_merchant_user_model->update(['_discount_pwd' => $new_hash], ['_id' => $uid]);` |
| 🔴 严重 | `全局` | **响应方法未终止执行**：`$this->error_response()` / `$this->success_response()` 调用后未 `exit` 或 `return`，导致后续代码继续执行，可能引发重复响应或逻辑越权。 | 确保响应方法内部调用 `exit()`，或在调用处使用 `return $this->error_response(...)`。 | `// 推荐写法<br>return $this->error_response("参数错误");<br>// 或在 error_response 方法末尾添加<br>exit(json_encode($response));` |
| 🟠 警告 | `~35行` | **CORS 策略过于宽松**：`Access-Control-Allow-Origin: *` 允许任意域名跨域请求商家接口，易被恶意站点利用。 | 根据实际业务限制来源域名，或使用动态白名单校验 `Origin` 头。 | `$origin = $_SERVER['HTTP_ORIGIN'] ?? '';<br>$allowed = ['https://merchant.yourdomain.com'];<br>if (in_array($origin, $allowed)) {<br> header("Access-Control-Allow-Origin: $origin");<br>}` |
| 🟠 警告 | `__construct` | **条件跳过初始化导致状态不一致**：`if ($this->router->fetch_method() !== "uploadPic")` 跳过了数据库、配置、模型的加载。若 `uploadPic` 依赖这些组件将直接报错。 | 将公共初始化移至 `__construct` 顶部，仅将鉴权逻辑放入条件判断，或为 `uploadPic` 单独创建控制器。 | `parent::__construct();<br>$this->load->database('default');<br>$this->config->load('config_talent');<br>// 鉴权逻辑独立<br>if ($this->router->fetch_method() !== 'uploadPic') {<br> $this->_check_auth();<br>}` |
| 🟠 警告 | `index()` | **巨型路由方法违反单一职责**：`index()` 方法超千行，包含登录、个人中心、打印机、支付配置等数十个业务分支，难以测试与维护。 | 按业务模块拆分为独立控制器（如 `AuthController`, `ProfileController`, `PrinterController`），或使用框架路由映射。 | `// 路由配置示例<br>$route['merchant/(:any)'] = 'MerchantApp/$1';<br>// 拆分后<br>class AuthController extends AplicationController { public function login() { ... } }` |
| 🟠 警告 | `~380,410行` | **冗余获取 CI 实例**：在控制器内部使用 `$CI = &get_instance();` 赋值属性，控制器本身已是实例，此操作多余且易引发作用域混淆。 | 直接使用 `$this` 访问属性或方法。 | `// 移除<br>$CI = &get_instance();<br>$CI->token = $result['token'];<br>// 改为<br>$this->token = $result['token'];` |
| 🟡 建议 | `全局` | **大量魔法数字与硬编码 ID**：如 `'0005'`, `694`, `849`, `533` 等散落在代码中，业务规则变更时需全局搜索替换。 | 提取为类常量或独立配置文件（如 `config/menu_ids.php`）。 | `const FUNC_LOGIN = '0005';<br>const MENU_FILTER_IDS = [694, 849, 824, 1250];<br>if (in_array($v['id'], self::MENU_FILTER_IDS)) { ... }` |
| 🟡 建议 | `类属性` | **属性全部声明为 `public`**：破坏封装性，外部可直接修改内部状态，增加不可预知的副作用风险。 | 改为 `protected` 或 `private`，通过 getter/setter 或构造函数初始化。 | `protected $stream;<br>protected $expire_sms_time = 600;<br>protected $current_version = "2.0";` |
| 🟡 建议 | `~35行` | **拼写错误**：基类名 `AplicationController` 缺少字母 `p`，若为框架核心类名不一致将导致致命错误。 | 修正为 `ApplicationController`（需确认框架实际基类名称）。 | `class MerchantAppServer extends ApplicationController` |
## 3. 总结与行动建议
### 🚨 优先修复项（P0）
1. **移除硬编码密钥**：立即将 `xfyun_tts_config` 中的 `APISecret` 和 `APIKey` 迁移至环境变量或服务器安全配置中，并检查 Git 历史是否已泄露。
2. **修复密码验证逻辑**：全面排查 `_discount_pwd` 字段存储方式，强制实施 `password_hash()` / `password_verify()` 标准流程。
3. **阻断响应后代码执行**：全局检查 `error_response()` 与 `success_response()` 实现，确保输出 JSON 后立即 `exit`，或统一改为 `return` 模式。
### 🛠 重构与优化方向
1. **控制器瘦身（SRP 原则）**：当前 `MerchantAppServer` 承担了路由分发、鉴权、登录、个人中心、打印机管理、支付配置等职责。建议按业务域拆分为 4~5 个独立控制器，`index()` 仅保留路由分发或废弃改用框架原生路由。
2. **配置与常量集中化**：将菜单过滤 ID、权限 ID、支付平台映射、API 版本号等提取至 `application/config/merchant_rules.php`，避免业务逻辑与配置耦合。
3. **性能优化**：
- `case '0005'` 中存在大量串行 DB 查询（`get_admin_menu`, `get_one`, `get_modules` 等）。建议对高频读取的配置类数据引入 Redis 缓存（框架已提供 `Cache` 组件）。
- 菜单过滤逻辑使用 `foreach` + `unset` + `array_values` 效率较低，可改用 `array_filter` 或预定义白名单映射。
4. **规范与可维护性**：
- 统一属性可见性为 `protected`。
- 清理过期注释（如 `//edit by nan 17.10.25`），改用 Git 提交记录追溯变更。
- 补充输入校验：`json_decode` 后应检查 `json_last_error()`，防止畸形 JSON 导致后续数组访问报错。
> 💡 **后续建议**：在重构前，建议为当前核心接口补充 PHPUnit 单元测试或集成测试，确保拆分与优化过程中业务逻辑不发生退化。若需针对 `case "1001"` 截断部分进行深度审查，请提供完整代码片段。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780386701
|
1780386701
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
239
|
22
|
18
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 1
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `cf10b03c5 ## 自动代码审查报告
**分支**: app-260519
**提交**: `cf10b03c5b5671f68ec5cf519da6871821349edf`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-20 14:39:24
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该 Model 承载了支付流水、退款、报表统计等核心财务逻辑，业务覆盖较全。但代码存在**严重的 SQL 注入风险**、**循环内 N+1 查询性能瓶颈**、**事务边界与外部 API 调用顺序设计缺陷**，且方法过长、魔法数字泛滥，严重违反单一职责原则与安全编码规范。需进行系统性重构。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `update_refund_amount`<br>`refund` 等多处 | **SQL 注入漏洞**：WHERE 条件与 UPDATE 语句直接使用字符串拼接（如 `'_relation_id="' . $relation_id . '"`），未使用预处理或查询构造器，极易被恶意参数注入。 | 全面废弃字符串拼接，改用框架 Query Builder 或参数化查询。若 `Simple_model` 不支持，应封装底层 PDO 预处理。 | `$this->db->where('_relation_id', $relation_id)->where('_type', $type)->update($this->table_name, $data);` |
| 🔴 严重 | `refund()` 方法 | **事务与资金一致性风险**：数据库事务 `trans_commit()` 提交后，才调用微信/支付宝退款接口。若第三方接口超时或失败，会导致“DB已退款但资金未退回”的资损问题。 | 引入**退款状态机**：先更新状态为 `退款处理中`，提交事务后调用 API；通过异步回调或定时对账任务更新最终状态。失败则触发补偿/人工介入流程。 | 状态流转：`1(已支付) -> 3(退款中) -> 4(已退款)`<br>API失败记录至 `refund_fail_log` 表重试。 |
| 🟠 警告 | `get_bill_pay_log`<br>`get_refundable_pay_log` | **N+1 查询性能瓶颈**：在 `foreach` 循环中频繁 `load->model()` 并执行 `get_one()`。数据量大时将导致数据库连接耗尽与响应超时。 | 循环外统一加载模型；使用 `IN` 查询批量获取关联数据，在内存中通过键值映射组装结果。 | `$order_ids = array_column($log_data, 'relation_id');`<br>`$orders = $this->ahead_yc_order_model->get_list(['_id' => $order_ids]);`<br>`$order_map = turn_array_key($orders, '_id');` |
| 🟠 警告 | `get_refundable_pay_log` | **循环变量状态污染**：`$is_can_refund` 在循环外初始化，循环内被覆盖。若某订单不可退款，后续所有订单的 `$is_can_refund` 均会被错误置为 `false`。 | 将状态变量改为按订单独立存储，或直接在循环内计算当前订单的退款权限。 | `$data[$k]['order_is_can_refund'] = $this->ahead_yc_order_model->check_is_can_refund($order_data);` |
| 🟠 警告 | `add_order_pay_log` | **未定义索引与累加逻辑错误**：`$actual_pay += $params['_actual_pay'];` 仅在 `$payPlatform == 14` 时赋值，其他分支直接累加未定义变量，可能触发 Notice 且金额计算错误。 | 明确初始化 `$params['_actual_pay']`，或在累加前进行 `isset()` 校验。 | `$actual_pay += $params['_actual_pay'] ?? 0;` |
| 🟡 建议 | 全局 | **魔法数字泛滥**：支付渠道、订单类型、状态码等硬编码数字（如 `1,2,3,11,14,15,16`）散落各处，可读性差且维护成本极高。 | 提取为类常量或独立配置类，统一引用。 | `const PAY_WECHAT = 1; const PAY_ALIPAY = 2; const STATUS_PAID = 1;` |
| 🟡 建议 | `refund()` 方法 | **违反单一职责原则 (SRP)**：单方法超 300 行，耦合了事务控制、VIP账户扣减、第三方API、报表更新、Redis队列、打印通知等。 | 拆分为独立服务或私有方法：`handleVipRefund()`, `callPaymentGateway()`, `syncReportData()`, `queueCrossDayRefund()`。 | 见下方重构方向 |
| 🟡 建议 | 全局 | **PSR-12 规范不符**：命名风格混杂（驼峰/下划线），缩进不一致，存在个人调试注释（如 `// 之前不知道为啥被注释掉...`）。 | 使用 `PHP-CS-Fixer` 统一格式化；清理历史注释；统一使用 `snake_case` 命名变量/方法。 | 配置 `.php-cs-fixer.dist.php` 并执行 `php-cs-fixer fix` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即修复 SQL 注入**：财务相关代码对安全性要求极高，所有动态拼接的 SQL 必须替换为 Query Builder 或预处理语句。
2. **修正循环状态污染**：`get_refundable_pay_log` 中的 `$is_can_refund` 逻辑错误会导致退款权限误判，需立即改为局部变量或数组映射。
3. **解决 N+1 查询**：报表与账单列表接口是高频调用场景，批量查询优化可将响应时间从秒级降至毫秒级。
### 🛠 后续重构与优化方向
1. **架构解耦（事件驱动/服务拆分）**：
- 将 `refund()` 中的副作用逻辑（更新营收、同步地图数据、记录跨日退款、发送短信、打印小票）抽离为**领域事件**或**消息队列任务**。支付主流程只负责核心账务变更，其余通过异步处理，提升接口响应速度与系统容错率。
- 示例：`Event::dispatch(new OrderRefundedEvent($pay_data, $refund_amount));`
2. **统一数据访问层**：
- 若 `phpci` 框架基于 CodeIgniter 演进，建议全面使用 `$this->db->select()`, `$this->db->where()`, `$this->db->update()` 等构造器方法，避免手写 SQL 字符串。
- 对于 `Simple_model` 的自定义 `select`/`up` 方法，建议审查其底层实现是否支持参数绑定，若不支持则应逐步替换。
3. **财务对账与状态机设计**：
- 引入明确的退款状态流转（待退款 -> 退款中 -> 退款成功/失败）。
- 第三方 API 调用必须配合**幂等性设计**（如使用 `refund_key` 防重）与**定时对账脚本**，确保资金流与信息流最终一致。
4. **代码规范与可维护性**：
- 建立常量映射文件（如 `config/pay_platform.php`），集中管理业务枚举。
- 使用 PHPStan 或 Psalm 进行静态分析，提前捕获类型错误与未定义变量。
> ⚠️ **局限性说明**：您提供的代码在 `add_by_vip_recharge_order` 方法处被截断（末尾为 `$t`），该部分可能包含更多逻辑或潜在问题。建议补充完整代码以便进行全量审查。此外，代码结构高度契合 CodeIgniter 3 规范，若 `phpci` 为定制框架，请确保上述 Query Builder 建议与框架底层实现兼容，必要时可查阅 `phpci` 官方文档确认安全查询的最佳实践。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779259164
|
1779259164
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
393
|
22
|
41
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 预买包段转房增加房态判断。
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `cf3bb0779 ## 自动代码审查报告
**分支**: app-260519
**提交**: `cf3bb07792eb4726b58d4c3e0e7b058dec020c48`
**提交人**: zhangjunnan (121158035@qq.com)
**时间**: 2026-05-28 10:57:03
---
## 1. 审查摘要
- **代码质量评分**：4/10 分
- **总体评价**：该文件为典型的遗留 CodeIgniter（注：根据目录结构推断 `phpci` 实为 `CodeIgniter`）模型代码。业务逻辑覆盖全面，但存在严重的 SQL 注入隐患、硬编码安全密钥、SQL 语法错误及性能瓶颈。代码风格陈旧，未充分利用框架的 Query Builder 特性，且 MVC 分层边界模糊（如在模型层直接 `json_encode`）。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_new_add_people_trend_data` (~L238) | **SQL 语法/逻辑错误**：子查询 `NOT IN (select DISTINCT(_ahead_user_id))` 缺失表名，执行将直接报错或返回全量数据，导致统计完全失真。 | 补全子查询表名与关联条件，确保逻辑闭环。 | `NOT IN (SELECT _ahead_user_id FROM ahead_yc_order WHERE _merchant_id = ? AND _status = 1)` |
| 🔴 严重 | `refund` 方法 (~L380) | **硬编码安全密钥**：`md5(... . '1441600902')` 等签名盐值硬编码在代码中，且使用已淘汰的 MD5。一旦泄露将导致支付接口被伪造调用。 | 将盐值移至 `config` 或环境变量，升级至 `hash_hmac('sha256', ...)`。 | `$salt = config_item('refund_salt'); $data['refund_key'] = hash_hmac('sha256', $order_info['_id'] . $order_info['_trade_no'], $salt);` |
| 🔴 严重 | 多处方法 (如 `get_order_manage`, `get_amount_info` 等) | **SQL 注入高危**：`$addsql` 变量通过字符串直接拼接进 SQL 语句。若该参数来自用户输入或未经严格白名单过滤，将导致严重注入漏洞。 | **彻底废弃 `$addsql` 拼接模式**，全面改用 CI Query Builder 的安全方法链。 | `$this->db->where('_status !=', 0)->where_in('_shop_id', $shop_ids)->get('ahead_yc_order');` |
| 🟠 警告 | `get_consumption_trend_data` 等多处 | **模型层越权处理 JSON**：在模型中直接 `json_encode($this->db->query(...)->result_array())` 返回，违反 MVC 分层原则，增加内存开销且不利于后续数据二次处理。 | 移除 `json_encode()`，直接返回数组。JSON 序列化应在 Controller 或 API 响应层统一处理。 | `return $result['data'] ? $result : false; // 移除 json_encode` |
| 🟠 警告 | `get_business` 方法 (~L445) | **类型转换与精度隐患**：`number_format()` 返回字符串，直接 `* 100` 会触发隐式类型转换；且 `$sum` 为 0 时的边界处理不够严谨。 | 使用原生浮点运算配合 `round()`，提升精度与可读性。 | `$tmp['percent'] = $sum > 0 ? round(($tmp['actual_pay'] / $sum) * 100, 2) : 0;` |
| 🟠 警告 | `cjy_get_other_order_info` (~L310) | **输入过滤过时**：使用 `addslashes()` 防注入已不符合现代 PHP 安全标准；正则校验逻辑复杂且易被绕过。 | 使用 CI 内置的 `$this->db->escape()` 或参数绑定；统一使用 Query Builder 处理 `LIKE`。 | `$this->db->like('_id', $_order_id, 'after');` |
| 🟡 建议 | 全局 | **违反 PSR-12 规范**：大量使用 `array()`、变量命名风格混乱（`$_merchant_id` vs `$merchant_id`）、存在大量注释代码块、缺乏类型声明。 | 升级至 PHP 7.4+/8.x 语法，使用 `[]`、添加参数类型提示、清理废弃注释、统一驼峰/下划线命名规范。 | `public function get_order_info(int $merchantId, string $orderId = '', ...): array` |
| 🟡 建议 | `__construct` 及多处 `load->model()` | **框架适配不佳**：在业务方法中频繁动态 `$this->load->model()` 和 `$this->config->load()`，增加不必要的 I/O 开销。 | 依赖模型应在 `__construct()` 中预加载，或通过 CI 的 `autoload.php` 配置。 | `public function __construct() { parent::__construct(); $this->load->model('ahead_yc_merchant_user_model'); }` |
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **修复 SQL 语法错误**：立即修正 `get_new_add_people_trend_data` 中的子查询缺失表名问题，否则该接口将直接崩溃。
2. **消除 SQL 注入风险**：全面重构 `$addsql` 拼接逻辑。建议封装一个统一的查询构建器方法，或使用 CI 的 `where()`、`where_in()`、`group_by()` 链式调用替代字符串拼接。
3. **移除硬编码密钥**：将 `refund` 方法中的 MD5 盐值及加密串 `$encrypt` 迁移至 `application/config/config.php` 或 `.env` 文件中，并升级哈希算法。
### 🛠 后续重构与优化方向
1. **架构分层优化**：
- **Model 层**：仅负责数据查询与基础组装，禁止 `json_encode`、禁止直接输出/跳转、禁止硬编码业务规则。
- **Controller/Service 层**：负责参数校验、权限控制、JSON 序列化及复杂业务编排。
2. **性能调优**：
- 将 `IN ($shop_ids)` 字符串拼接改为 `$this->db->where_in()`，便于框架底层进行参数绑定与查询缓存。
- 针对高频统计接口（如数据魔方系列），建议引入 **物化视图** 或 **定时任务预计算**，避免每次请求都执行 `SUM()`、`COUNT(DISTINCT)` 等重型聚合查询。
- 移除 `force index` 硬编码，交由 MySQL 优化器根据实际数据分布自动选择索引，或通过 `EXPLAIN` 验证后在数据库层维护。
3. **代码规范升级**：
- 启用 `phpcs` 配合 `PSR-12` 规则进行静态扫描。
- 逐步引入 PHP 类型声明（`declare(strict_types=1);`、参数类型、返回类型），提升代码健壮性与 IDE 提示体验。
- 清理所有 `// echo $this->db->last_query();` 等调试注释，改用日志系统（如 Monolog 或 CI 内置 Log）记录慢查询。
> ⚠️ **局限性说明**：您提供的代码在末尾 `get_goods_sales` 方法处被截断（`$this->ahead_yc_merchant_user_model->get_one(['_id' => $para`），未能完整审查该方法的权限校验与分页逻辑。若需对该部分进行深度评估，请补充完整代码。同时，本审查基于 `CodeIgniter 3` 架构假设，若实际框架版本不同，部分 Query Builder 用法需相应调整。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779937023
|
1779937023
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
279
|
22
|
26
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 1
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `d02519cb2 ## 自动代码审查报告
**分支**: app-260519
**提交**: `d02519cb223588259124e499eb73b7e8352cd596`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-21 15:58:13
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了预订变更差价退款的核心业务流程，但存在明显的架构与逻辑隐患。缺乏数据库事务保护、并发控制不足、硬编码严重、模型加载方式不规范，且部分第三方接口调用存在单号冲突风险。整体可维护性与生产环境稳定性有待大幅提升。
- **风险等级**：🔴 高（存在数据不一致、重复退款、接口调用失败等生产级风险）
> 📌 **框架说明**：从目录结构（`system/`、`application/`）、`$CI = &get_instance()` 及 `$this->load->model()` 等特征判断，该代码基于 **CodeIgniter 3** 架构。若 `phpci` 为内部定制分支，以下审查结论仍完全适用。建议后续统一遵循 CI3 官方规范或明确框架版本。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `refund()` 方法 | **缺乏数据库事务包裹**：状态更新、第三方退款、营收明细记录分散执行。若中间环节失败，将导致“已扣款但未退款”或“已退款但状态未更新”的数据不一致。 | 使用 CI 事务机制 `$this->db->trans_start()` / `$this->db->trans_complete()` 包裹核心退款逻辑，并在失败时 `$this->db->trans_rollback()`。 | `$this->db->trans_start();`<br>`// 核心逻辑`<br>`$this->db->trans_complete();`<br>`if ($this->db->trans_status() === FALSE) { $this->db->trans_rollback(); return ['status'=>false, 'msg'=>'事务回滚']; }` |
| 🔴 严重 | `refund()` 方法 | **并发竞态条件（重复退款）**：先 `select` 状态为 `1` 的记录，再 `update`。高并发下多个请求可能同时读到同一批记录，导致重复退款。 | 查询时添加行级锁 `FOR UPDATE`，或使用乐观锁（如 `_version` 字段）。确保 `update` 的 `WHERE` 条件包含原状态。 | `$this->db->select('*')->where(['_order_id'=>$id, '_status'=>1])->get($this->table_name)->result_array();`<br>改为使用 `$this->db->query("SELECT * FROM {$this->table_name} WHERE ... FOR UPDATE");` |
| 🟠 警告 | `wx_refund()` | **退款单号不唯一**：`SetOut_refund_no($shop_data['_mch_id'] . date('YmdHis'))` 在同一秒内多次调用会生成相同单号，微信接口将拒绝或覆盖。 | 使用唯一标识拼接，如 `$log['_id']` 或 `uniqid()`，确保全局唯一。 | `$out_refund_no = $shop_data['_mch_id'] . '_' . $refund_info['log_id'] . '_' . time();`<br>`$input->SetOut_refund_no($out_refund_no);` |
| 🟠 警告 | 文件顶部 | **全局获取 CI 实例**：`$CI = &get_instance();` 放在类外部，违反 CI 生命周期规范，可能导致实例未初始化或内存泄漏。 | 移除全局调用。在 `__construct()` 中通过 `$this->load->model()` 加载依赖，或继承的基类已处理实例获取。 | `public function __construct() { parent::__construct(); $this->load->model('ahead_vip_model'); $this->load->model('jh_community_shop_revenues_detail_model'); }` |
| 🟠 警告 | `wx_refund()` | **循环/条件内重复加载模型**：`$this->load->model()` 在方法内部多次调用，每次都会触发文件包含与实例化，浪费性能。 | 统一在构造函数中加载，或使用 `$CI->load->model()` 缓存机制。 | 见上方构造函数示例 |
| 🟠 警告 | `wx_refund()` | **`include_once` 置于方法内部**：每次执行都会进行文件路径解析与存在性检查，影响性能且不利于自动加载管理。 | 移至文件顶部，或配置 Composer/CI 自动加载机制。 | `require_once COMMONCLASS . 'WxClass/KtvPayApi/WxPay.php';`（置于 `<?php` 下方） |
| 🟡 建议 | 全局 | **魔法数字硬编码**：`1, 3, 4, 5, 8, 9, 10` 等状态/场景值直接写死，可读性差且后期维护极易出错。 | 定义类常量，提升语义化。 | `const STATUS_PAID = 1; const STATUS_REFUNDED = 4; const PLATFORM_WECHAT = 1;` |
| 🟡 建议 | `refund()` | **方法名拼写疑似错误**：`$this->ahead_vip_model->refund_book_orde($log);` 末尾缺少 `r`，可能导致 `Call to undefined method` 致命错误。 | 核对模型方法名并修正为 `refund_book_order`。 | `$this->ahead_vip_model->refund_book_order($log);` |
| 🟡 建议 | `wx_refund()` | **敏感数据日志记录**：`doLog(var_export($res, true), ...)` 可能完整记录支付响应（含签名、密钥、用户信息），存在合规风险。 | 仅记录关键状态码、单号与脱敏金额。 | `doLog(json_encode(['code'=>$res['result_code'], 'log_id'=>$refund_info['log_id']]), 'changeBookOrderWxRefund');` |
| 🟡 建议 | 全局 | **不符合 PSR-12 规范**：缩进不一致、`array()` 与 `[]` 混用、`if` 括号位置不统一、松散比较 `!= '1'`。 | 使用 `PHP-CS-Fixer` 或 IDE 格式化，统一使用严格比较 `!==` 与短数组语法。 | `if ($is_refund !== '1') { ... }` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **引入数据库事务**：退款属于强一致性操作，必须使用 `$this->db->trans_start()` 包裹 `update`、第三方退款调用、营收明细写入。任一环节失败立即回滚。
2. **解决并发重复退款**：在查询待退款记录时添加 `FOR UPDATE` 行锁，或改用乐观锁机制。确保 `update` 的 `WHERE` 条件严格匹配 `_status = 1`。
3. **修复退款单号冲突**：将 `out_refund_no` 改为 `商户号_日志ID_时间戳` 或 `uniqid()` 组合，满足微信支付唯一性要求。
4. **修正模型加载与实例化**：移除文件顶部的 `$CI = &get_instance();`，将依赖模型统一移至 `__construct()` 中加载，避免运行时重复实例化。
### 🛠 后续重构与优化方向
- **常量与配置抽离**：将支付平台标识、订单状态、场景值等硬编码提取为类常量或配置文件，便于后期扩展与多环境管理。
- **支付网关抽象化**：当前 `wx_refund()` 方法耦合了微信原生、嗨赞定制、银联等多套逻辑。建议采用 **策略模式 (Strategy Pattern)** 或 **工厂模式**，按 `pay_scene` 分发至独立的退款处理器类，降低 `if-elseif` 分支复杂度。
- **日志与监控增强**：引入结构化日志（如 Monolog），记录退款流水号、耗时、第三方响应状态。对失败请求增加重试机制或死信队列，避免资金卡单。
- **代码规范自动化**：在 CI/CD 流水线中集成 `phpcs` (PSR-12) 与 `phpstan` 静态分析，拦截低级语法错误与类型隐患。
> 💡 **提示**：若 `phpci` 为贵司内部定制框架，请确认其是否对 `Simple_model` 基类封装了事务/锁方法。如有，请优先使用框架内置 API 替代原生 `$this->db` 调用，以保持架构一致性。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779350293
|
1779350293
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
234
|
22
|
16
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 1
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `d26a61b26 ## 自动代码审查报告
**分支**: app-260519
**提交**: `d26a61b26e4e77436e307d60284609d79bf3f254`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-20 11:29:55
---
## 1. 审查摘要
- **代码质量评分**：4 / 10 分
- **总体评价**：该文件为典型的历史遗留型“上帝 Helper”，聚合了大量业务逻辑、底层工具与第三方服务调用。代码存在多处 **PHP 8.0+ 致命语法废弃**、**硬编码敏感凭证**、**数组操作逻辑缺陷**及**高频 Redis 连接创建**等严重问题。整体可维护性较低，需按模块拆分并遵循现代 PHP 规范进行重构。
- **风险等级**：🔴 高
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `alioss_deleteObject` / `alioss_addObject` | **硬编码云厂商 AccessKey/SecretKey**。直接暴露在源码中，极易导致 OSS 存储桶被恶意读写或产生高额账单。 | 移至 `config/oss.php` 或环境变量，通过 `$CI->config->item()` 读取。生产环境严禁硬编码。 | `'accessId' => $CI->config->item('oss_access_id')` |
| 🔴 严重 | `getFirstCharter` | **PHP 8 致命错误**：使用 `$str{0}` 访问字符串。PHP 7.4 已废弃，PHP 8.0+ 直接抛出 `Fatal Error`。 | 统一替换为方括号语法 `$str[0]`。 | `return strtoupper($str[0]);` |
| 🔴 严重 | `decodeUnicode` | **PHP 8 致命错误**：使用已移除的 `create_function()`。存在安全风险且无法在 PHP 8+ 运行。 | 使用匿名函数 `function($matches) { ... }` 替代。 | `preg_replace_callback('/\\\\u([0-9a-f]{4})/i', fn($m) => mb_convert_encoding(pack('H*', $m[1]), 'UTF-8', 'UCS-2BE'), $str);` |
| 🔴 严重 | `doBatchFromTable` | **逻辑缺陷**：`foreach` 中 `$data` 为值拷贝，`$data[$k] = ...` 不会修改原 `$list`，导致函数返回未处理的数据。 | 直接操作 `$list[$k]` 或使用引用传递。 | `foreach ($list as $k => $data) { $list[$k] = doSingleFromTable($data); }` |
| 🔴 严重 | `getTimeInfo` | **逻辑缺陷**：`foreach` 中 `unset($item)` 仅销毁局部变量，无法从原数组中移除元素，过滤逻辑完全失效。 | 使用键值遍历或构建新数组。 | `foreach ($array as $key => $item) { if (!条件) unset($array[$key]); }` |
| 🔴 严重 | `passport_encrypt` | **密码学不安全**：使用 `srand()` 和 `rand()` 生成加密密钥，可被预测。不符合现代安全标准。 | 废弃该自定义算法，改用 `openssl_encrypt()` 或 `sodium_crypto_secretbox()`。 | `openssl_encrypt($str, 'AES-256-GCM', $key, OPENSSL_RAW_DATA, $iv);` |
| 🟠 警告 | `get_aliyun_redis_conn` 及所有 `rs_*` 函数 | **严重性能瓶颈**：每次调用都新建 Redis 连接、认证、选库并 `close()`。高并发下将耗尽连接池并拖垮 Redis。 | 采用单例模式或复用 CI 的 Redis 驱动。移除函数末尾的 `$obj->close()`，交由 PHP 垃圾回收或连接池管理。 | 见下方重构建议 |
| 🟠 警告 | `rs_set` / `rs_incrBy` 等 | **逻辑隐患**：`rs_set` 检查 `!$obj->exists()` 导致无法覆盖已有值（实为 `SETNX` 行为）；`expireAt` 需绝对时间戳，若 `$expireTime` 为秒数应改用 `expire()`。 | 明确函数语义：若需覆盖则移除 `exists` 判断；统一使用 `$obj->expire($key, $seconds)` 设置相对过期时间。 | `$obj->set($key, $val); if($expireTime>0) $obj->expire($key, $expireTime);` |
| 🟠 警告 | `get_mac_by_url` | **潜在 Notice/Warning**：手动 `explode` 解析 URL 参数，未校验数组长度直接访问 `$check_url[1]`、`$vvs[0]` 易越界。 | 使用原生 `parse_url()` + `parse_str()` 替代手动拆分，增加 `isset()` 防御。 | `parse_str(parse_url($url, PHP_URL_QUERY) ?? '', $params); $id = $params['id'] ?? '';` |
| 🟠 警告 | `get_room_device_status` | **健壮性差**：超长 `if-elseif` 链直接访问 `$switch_list_arr['0']['state']`，缺失键时将触发大量 `Undefined index` 警告。 | 提取状态映射表，或使用空合并运算符 `??` 安全取值。 | `$state0 = $switch_list_arr['0']['state'] ?? null;` |
| 🟠 警告 | `curlRequest` / `asyncRequest` | **安全风险**：强制关闭 SSL 验证 `CURLOPT_SSL_VERIFYPEER = false`，易受中间人攻击（MITM）。 | 移除该配置或配置正确的 CA 证书路径。生产环境严禁关闭。 | `curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, true);` |
| 🟡 建议 | 文件顶部 | **结构不规范**：`defined('BASEPATH') OR exit(...)` 安全守卫放在第一个函数之后，且 `import()` 函数代码被意外截断。 | 将安全守卫移至文件首行；补全 `import()` 逻辑或改用 CI 原生 `$CI->load->helper()`。 | `<?php defined('BASEPATH') OR exit('No direct script access allowed');` |
| 🟡 建议 | 全局函数 | **规范缺失**：命名风格混用（驼峰/下划线），无类型声明，DocBlock 重复/错位，不符合 PSR-12。 | 统一使用 `snake_case`，添加 `@param`/`@return` 类型提示，PHP 7.4+ 建议添加标量类型声明。 | `function get_mac_by_url(string $family_server_id): string|false` |
---
## 3. 总结与行动建议
### 🚨 优先修复的关键问题（P0）
1. **移除硬编码凭证**：立即将 `alioss_*` 函数中的 `accessId`/`accessKey` 迁移至配置文件或环境变量，并轮换已泄露的密钥。
2. **修复 PHP 8 兼容性**：全局替换 `$str{0}` 为 `$str[0]`，移除 `create_function`，否则升级 PHP 版本将直接导致系统崩溃。
3. **修正数组操作 Bug**：修复 `doBatchFromTable` 和 `getTimeInfo` 中的无效赋值/删除逻辑，避免业务数据静默丢失。
4. **替换弱加密算法**：废弃 `passport_encrypt/decrypt`，迁移至 `openssl` 扩展，保障用户敏感数据安全。
### 🛠 后续重构与优化方向
1. **Redis 连接池化/单例化**：
当前每个 `rs_*` 函数独立建连是最大性能瓶颈。建议封装为单例类：
```php
class RedisPool {
private static $instance = null;
public static function getInstance($hostName = '', $dbId = 0) {
if (!self::$instance) {
self::$instance = get_aliyun_redis_conn($hostName, $dbId);
}
return self::$instance;
}
}
// 调用处改为：$redis = RedisPool::getInstance();
```
2. **职责拆分（SRP 原则）**：
该文件已严重违反单一职责原则。建议按领域拆分为：
- `redis_helper.php`（仅保留 Redis 封装）
- `oss_helper.php`（云存储操作）
- `security_helper.php`（加密、IP获取、短信）
- `format_helper.php`（时间、距离、排序、字符处理）
3. **框架适配说明**：
代码结构高度符合 **CodeIgniter 3** 规范（`get_instance()`, `BASEPATH`, `system/` 目录）。若 `phpci` 为内部定制框架，请确认其是否支持 PHP 8 及现代依赖注入。建议逐步将 Helper 中的模型加载 (`$CI->load->model()`) 移至 Controller 或 Service 层，避免 Helper 产生隐式依赖。
4. **引入静态分析工具**：
建议接入 `PHPStan` 或 `Psalm` 进行静态类型检查，配合 `PHP_CodeSniffer` 强制 PSR-12 规范，可在 CI/CD 流水线中拦截此类低级语法与逻辑错误。
> 💡 **提示**：若需针对某个具体函数（如 `get_mac_by_url` 或 `createRecordUrl`）进行深度重构或单元测试编写，可提供具体业务场景，我将输出完整可替换的代码实现。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779247795
|
1779247795
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
401
|
22
|
43
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 111
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `da80aa837 ## 自动代码审查报告
**分支**: app-260519
**提交**: `da80aa8372565576d62e8cead61d9d5e542af8a3`
**提交人**: zhangjunnan (121158035@qq.com)
**时间**: 2026-05-28 15:15:21
---
## 1. 审查摘要
- **代码质量评分**：4.5 / 10 分
- **总体评价**：该模型类承载了大量订单查询、报表统计与分页逻辑，业务覆盖面广。但代码存在**严重的 SQL 注入隐患**、**硬编码敏感信息**、**SQL 语法错误**及**MVC 职责越界**问题。大量使用字符串拼接构建 SQL、缺乏类型约束、模型层直接进行 `json_encode` 序列化，导致可维护性、安全性与扩展性较低。
- **风险等级**：🔴 高
> 📌 **框架说明**：提供的目录结构、加载方式（`$this->load->model()`、`$this->db->query()`）高度符合 **CodeIgniter 3** 规范。若 `phpci` 为内部定制或衍生框架，以下审查建议仍基于 CI3 核心机制与 PHP 通用最佳实践。若存在差异，请以官方文档为准。
> ⚠️ **局限性提示**：代码在 `get_goods_sales` 方法处意外截断，部分权限校验与关联查询逻辑未能完整评估。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 全局多处方法（如 `get_order_manage`, `get_amount_info` 等） | **SQL 注入漏洞**：大量依赖外部传入的 `$addsql` 字符串直接拼接至 SQL 语句中，未使用参数绑定或 Query Builder 过滤。攻击者可构造恶意条件绕过权限或拖库。 | 彻底废弃 `$addsql` 拼接模式。统一改用 CI Query Builder 链式调用，或严格使用 `?` 占位符+参数数组。 | `$this->db->where('_merchant_id', $merchantId)->where('_status !=', 0)->get('ahead_yc_order')->result_array();` |
| 🔴 严重 | `get_new_add_people_trend_data` | **SQL 语法错误**：子查询 `NOT IN (select DISTINCT(_ahead_user_id))` 缺失数据源表名，执行必报 `1241 - Operand should contain 1 column(s)` 或语法错误。 | 补全子查询表名及业务条件，明确对比范围。 | `... AND _ahead_user_id NOT IN (SELECT _ahead_user_id FROM ahead_user_buy_log WHERE _is_first_buy = 0)` |
| 🔴 严重 | 类属性 `public $encrypt = "Vs!Fs7VT";` | **敏感信息硬编码**：加密密钥直接暴露在类属性中，易随代码库泄露，且多环境部署时无法差异化配置。 | 移至 `application/config/config.php` 或 `.env`，通过 `$this->config->item()` 读取。 | `private $encryptKey; public function __construct() { parent::__construct(); $this->encryptKey = config_item('order_encrypt_key'); }` |
| 🟠 警告 | `get_business` 方法 | **类型转换与精度隐患**：`number_format($tmp['actual_pay'] / $sum, 4) * 100` 先格式化字符串再乘 100，依赖 PHP 隐式类型转换，可能丢失精度或触发 `E_WARNING`。 | 先完成浮点运算，最后统一格式化输出。 | `$percent = $sum > 0 ? ($tmp['actual_pay'] / $sum) * 100 : 0; $tmp['percent'] = number_format($percent, 2);` |
| 🟠 警告 | `cjy_consumption_trend_data`, `cjy_people_trend_data` | **Query Builder 滥用字符串拼接**：`$this->db->where('_timestamp between "' . $start_date . '" and "' . $end_date . '"')` 破坏框架防注入机制，且日期格式依赖外部输入。 | 使用 CI 原生范围查询语法，确保类型安全。 | `$this->db->where('_timestamp >=', $start_date)->where('_timestamp <=', $end_date);` |
| 🟠 警告 | `insert_room_count`, `insert_room_detail` | **DB 驱动兼容性风险**：`$this->db->where(implode(" and ", $where))` 传入完整 SQL 片段字符串。新版 CI 严格校验 `where()` 参数格式，可能抛出异常。 | 拆分为多次 `where()` 调用或使用数组条件。 | `$this->db->where('a._status !=', 0)->where_not_in('a._merchant_id', [11,107,150,110]);` |
| 🟠 警告 | `get_order_manage_by_page` | **索引提示滥用**：`force index(_merchant_id)` 基于 `strpos($addsql, '_shop_id')` 硬编码触发，缺乏执行计划验证，可能导致优化器选择次优路径。 | 移除硬编码 `force index`，依赖数据库优化器；或通过 `EXPLAIN` 分析后建立复合索引 `_merchant_id, _shop_id, _timestamp`。 | 直接删除 `force index` 逻辑，确保数据库索引设计合理。 |
| 🟡 建议 | `get_consumption_trend_data` 等多处 | **模型层职责越界**：模型中直接调用 `json_encode()` 返回数据，违反 MVC 分离原则，增加 Controller 解析负担且不利于单元测试。 | 模型仅返回标准数组/对象，JSON 序列化统一在 Controller 或 API 响应层处理。 | `return $this->db->query($sql)->result_array();` |
| 🟡 建议 | 全局 | **违反 PSR-12 规范**：变量命名混乱（`$_merchant_id`, `addsql`），缺少类型声明，方法过长且包含大量注释掉的调试代码。 | 遵循 PSR-12，使用驼峰命名，添加 PHP 8 类型提示，清理死代码，拆分超长方法。 | `public function getOrderInfo(int $merchantId, string $orderId = '', ...): array` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **全面重构 SQL 构建逻辑**：立即停止使用 `$addsql` 字符串拼接。建立统一的查询条件构建器（如 `buildWhereConditions(array $params)`），所有外部输入必须经过类型转换或白名单校验后传入 Query Builder。
2. **修复致命语法错误**：修正 `get_new_add_people_trend_data` 中的子查询缺失表名问题，该错误会导致相关报表接口直接 500 崩溃。
3. **移除硬编码密钥**：将 `$encrypt` 移至配置文件或环境变量，并通过依赖注入或配置项读取，符合安全合规要求。
### 🛠 后续重构与优化方向
- **架构分层**：当前 Model 承担了“数据查询 + 业务计算 + 分页逻辑 + JSON 序列化”多重职责。建议引入 **Service 层** 处理复杂计算与分页状态，Model 仅负责纯净的数据存取。
- **统一分页组件**：代码中多处手动计算 `offset`、`totalPage`、`pageStatus`。建议封装为独立的 `PaginationService` 或直接使用 CI 原生 `Pagination` 库，避免重复造轮子。
- **类型安全与现代化**：逐步引入 PHP 7.4+/8.0 类型声明（如 `int`, `string`, `array`, `?string`），利用 IDE 静态检查提前拦截类型错误。
- **数据库性能调优**：针对 `ahead_yc_order` 大表，建议对高频查询字段 `(_merchant_id, _shop_id, _timestamp, _status)` 建立复合索引。移除 `force index` 硬编码，依赖 MySQL 优化器动态选择。
- **清理历史债务**：移除所有 `//echo $this->db->last_query();die;`、`//edit by nan` 等调试注释，保持代码库整洁。
> 💡 **实施建议**：由于该类耦合度较高，建议采用**渐进式重构**。优先修复安全漏洞与语法错误，随后将高频查询方法抽离为独立 Service，并编写单元测试覆盖核心统计逻辑。若需针对 `phpci` 框架特定生命周期（如事件钩子、缓存驱动）进行深度适配，请提供框架官方文档或核心基类定义以便进一步审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779952521
|
1779952521
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
392
|
22
|
40
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - Merge branch 'app-260519 🔍 代码审查报告：app-260519 - Merge branch 'app-260519' of https://gitea.g-hi.co...
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `e2df10dd7 ## 自动代码审查报告
**分支**: app-260519
**提交**: `e2df10dd72c66637a0205bbb92aebc80b636c215`
**提交人**: zhangjunnan (121158035@qq.com)
**时间**: 2026-05-28 10:55:21
---
## 1. 审查摘要
- **代码质量评分**：4.5 / 10 分
- **总体评价**：代码库呈现典型的早期 CodeIgniter 3 架构特征（注：实际代码结构为 CI3，非 `phpci` 官方框架）。整体业务逻辑覆盖较广，但存在大量历史遗留问题。核心隐患集中在 **SQL 注入风险、硬编码敏感凭证、非原子锁操作、废弃语法兼容性及连接资源滥用**。代码规范性较弱，缺乏类型约束与统一设计模式，在高并发或现代 PHP 版本（≥7.4/8.0）下极易引发崩溃或安全事件。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `common_helper.php`<br>`alioss_deleteObject` / `alioss_addObject` | **硬编码云存储密钥**：OSS `AccessKey` 与 `SecretKey` 直接写死在代码中，极易通过版本库泄露，导致云存储数据被恶意读取、篡改或删除。 | 将密钥迁移至 `application/config/oss.php` 或环境变量，通过 CI 配置加载。禁止在代码中明文存储凭证。 | `$param = $CI->config->item('aliyun_oss');` |
| 🔴 严重 | `Ahead_yc_order_model.php`<br>所有报表查询方法 | **SQL 注入漏洞**：大量使用 `$addsql` 字符串直接拼接 SQL（如 `where a." . $addsql . " and...`），未使用预处理或查询构造器。若 `$addsql` 源自前端或外部接口，将导致严重注入。 | 全面废弃字符串拼接。改用 CI Query Builder (`$this->db->where()`, `$this->db->get()`) 或严格参数绑定。 | `$this->db->where($where_array)->get('ahead_yc_order');` |
| 🔴 严重 | `common_helper.php`<br>`passport_encrypt` / `passport_decrypt` | **弱加密算法**：使用 `srand(microtime())` 配合异或运算实现自定义加密，随机种子可预测，密码学强度为零，易被逆向破解。 | 废弃该函数。改用 PHP 原生 `openssl_encrypt()` / `openssl_decrypt()` 或 CI 内置 `Encryption` 库。 | `openssl_encrypt($str, 'AES-256-CBC', $key, 0, $iv);` |
| 🔴 严重 | `common_helper.php`<br>`decodeUnicode` | **使用已废弃函数**：`create_function()` 在 PHP 7.2 标记废弃，PHP 8.0 已彻底移除，直接导致 `Fatal Error`。 | 替换为匿名函数（闭包）。 | `preg_replace_callback('/\\\\u([0-9a-f]{4})/i', fn($m) => mb_convert_encoding(pack("H*", $m[1]), "UTF-8", "UCS-2BE"), $str);` |
| 🟠 警告 | `Ahead_shop_config_second_model.php`<br>`get_one()` | **并发竞态条件**：查询为空时直接 `insert` 再查询。高并发下多个请求同时判定为空，会插入重复记录，破坏数据唯一性。 | 使用数据库事务 + `SELECT ... FOR UPDATE`，或改用 `INSERT IGNORE` / `ON DUPLICATE KEY UPDATE` 保证幂等。 | `$this->db->trans_start(); ... $this->db->trans_complete();` |
| 🟠 警告 | `common_helper.php`<br>`doRedisLockRelease` | **分布式锁非原子释放**：`GET` 判断后 `DEL` 删除存在时间窗口，高并发下可能误删其他进程持有的锁，引发业务错乱。 | 使用 Lua 脚本保证 `GET` 与 `DEL` 的原子性。 | `eval("if redis.call('get',KEYS[1])==ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end", 1, $key, $value);` |
| 🟠 警告 | `common_helper.php`<br>所有 `rs_*` 函数 | **Redis 连接频繁创建/销毁**：每个函数独立调用 `get_aliyun_redis_conn()` 并 `$obj->close()`，TCP 握手开销极大，严重拖慢响应。 | 采用单例模式或连接池缓存 Redis 实例；或启用 `pconnect` 长连接。避免每次请求重复建连。 | `static $conn; if(!$conn) $conn = get_aliyun_redis_conn(); return $conn;` |
| 🟠 警告 | `common_helper.php`<br>`getTimeInfo` | **数组过滤逻辑失效**：`foreach` 中 `unset($item)` 仅销毁局部变量副本，无法从原数组中移除元素，导致过滤失败。 | 使用 `array_filter` 或正确传递键名进行 `unset`。 | `return array_values(array_filter($array, fn($i) => ($time1 >= $i['start_time'] && $time1 <= $i['end_time']) || ...));` |
| 🟠 警告 | `common_helper.php`<br>`business_time` | **边界条件处理不当**：`if ($business_time > 3600 * 24)` 当时间恰好等于 24 小时时，会错误显示为 `当天 24:00`。 | 改为 `>=` 判断，或使用 `DateTime` 对象进行标准化计算。 | `if ($business_time >= 86400) { ... }` |
| 🟡 建议 | `common_helper.php`<br>全局结构 | **安全校验位置错误 & 规范混乱**：`defined('BASEPATH') OR exit(...)` 放在文件中部；函数命名驼峰/下划线混用；注释大量重复。 | 将安全校验移至文件首行；统一遵循 PSR-12 命名规范；清理冗余/过期注释。 | `<?php defined('BASEPATH') OR exit('No direct script access allowed');` |
| 🟡 建议 | `Ahead_shop_config_second_model.php`<br>`$shop_config` | **静态缓存内存泄漏风险**：`public static $shop_config` 在 CLI 或长驻进程（如 Swoole/Workerman）中会无限增长，最终 OOM。 | 增加 TTL 过期机制，或改用 CI Cache 驱动（Redis/Memcached）替代静态数组。 | `if (!$this->cache->get($cache_key)) { $this->cache->save($cache_key, $data, 300); }` |
| 🟡 建议 | `common_helper.php`<br>`rs_set` / `rs_incrByFloat` | **逻辑与类型校验不匹配**：`rs_set` 注释为“设置值”，但代码 `!$obj->exists()` 实为 `SETNX`；`rs_incrByFloat` 使用 `is_float()` 会拦截字符串浮点数 `"0.5"`。 | 明确函数语义（改名 `rs_setnx`）；类型校验改用 `is_numeric()`。 | `if (!empty($keyName) && is_numeric($float)) { ... }` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即移除硬编码凭证**：将 OSS、Redis、短信平台等所有密钥/密码抽离至配置文件或 `.env`，并配置 Git 忽略规则。
2. **封堵 SQL 注入通道**：`Ahead_yc_order_model.php` 中的报表查询必须全面重构。停止使用 `$addsql` 拼接，统一迁移至 CI Query Builder 或 PDO 预处理。
3. **升级加密与废弃语法**：替换 `passport_encrypt` 为 `openssl` 方案；修复 `create_function` 以兼容 PHP 8+。
4. **修复分布式锁竞态**：使用 Lua 脚本重写 `doRedisLockRelease`，确保锁释放的原子性。
### 🛠 后续重构与优化方向
- **架构适配说明**：当前代码基于 **CodeIgniter 3** 架构（`get_instance()`, `$this->db->query()` 等），并非官方 `phpci` 框架。若项目确为 `phpci` 定制版，请确认其是否兼容 CI3 生命周期；若为独立框架，建议逐步迁移至现代 CI4 或 Laravel，以获得原生依赖注入、PSR 规范及更强安全基座。
- **数据库层重构**：废弃原生 SQL 拼接，全面采用 Query Builder。对高频查询表（如 `ahead_yc_order`）补充复合索引，避免全表扫描与 `GROUP BY` 性能瓶颈。
- **连接资源治理**：Redis 与 MySQL 连接应实现单例/连接池管理。在 `common_helper.php` 中封装统一的 `RedisClient` 与 `DbClient` 类，避免散落的 `connect/close`。
- **类型安全与现代化**：为所有 Helper 函数添加 PHP 7+ 类型声明（`string`, `int`, `array`, `bool`）及返回值类型。启用 `declare(strict_types=1);` 提升代码健壮性。
- **长驻进程兼容**：若系统运行于 Swoole/Workerman 等常驻内存环境，必须清理所有 `static` 缓存变量，改用外部缓存中间件，并实现请求级上下文隔离。
> 💡 **注**：由于 `common_helper.php` 末尾代码被截断（`import` 函数未闭合），本次审查基于已提供内容。建议补充完整文件后对 `import` 加载机制及全局作用域污染进行二次评估。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779936921
|
1779936921
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
181
|
22
|
9
|
1
|
|
0
|
🔍 代码审查报告：app-260519 - 1
|
## 自动代码审查报告
**分支**: app-260519
**提交**: `fc28a1961 ## 自动代码审查报告
**分支**: app-260519
**提交**: `fc28a1961ee774bff6f5ca865687e04f6002fe8f`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 13:34:18
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该 Model 承载了核心支付流水、退款、报表统计等关键业务逻辑，功能完整但架构耦合度较高。代码中存在明显的 SQL 注入风险、N+1 查询性能瓶颈、事务与外部 API 调用顺序导致的财务一致性隐患，且部分方法严重违反单一职责原则。整体可维护性与安全性亟待提升。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `update_refund_amount` / `refund` | **SQL 注入风险**：使用字符串拼接构造 `WHERE` 与 `UPDATE` 语句（如 `'_relation_id="' . $relation_id . '"...'`），未进行参数绑定或转义，若参数可控将导致严重数据泄露或篡改。 | 全面改用框架查询构造器（Query Builder）或数组条件传参，杜绝原生字符串拼接。 | `$this->db->where('_relation_id', $relation_id)->where('_type', $type)->where_in('_status', [1,4])->get()->row();`<br>`$this->db->set('_refund_amount', '_refund_amount+' . floatval($refund_amount), FALSE)->update($this->table_name, ['_id' => $pay_id]);` |
| 🔴 严重 | `refund` 方法末尾 | **事务与外部 API 顺序导致财务不一致**：`$this->db->trans_commit()` 执行后才调用 `mobile_refund()`。若支付网关退款失败，数据库已标记退款成功，造成资金账实不符。 | 引入异步消息队列处理网关退款；或改为同步调用并包裹 `try-catch`，失败时触发补偿逻辑/人工工单。 | `// 建议改为异步任务<br>$this->load->library('queue');<br>$this->queue->push('refund_gateway', ['pay_id' => $pay_id, 'amount' => $refund_amount]);` |
| 🟠 警告 | `get_bill_pay_log` / `get_refundable_pay_log` | **N+1 查询性能瓶颈**：在 `foreach` 循环内多次调用 `get_one()` 及 `get_custom_pay_platform()`，数据量超 50 条时将引发数百次 DB 请求，严重拖慢响应。 | 循环前批量查询，使用 `where_in` 获取数据并构建映射数组，循环内直接读取。 | `$ids = array_column($log_data, 'relation_id');<br>$extensions = $this->ahead_yc_order_extension_model->get_list(['where_in' => ['_order_id', $ids]]);<br>$extMap = array_column($extensions, null, '_order_id');<br>// 循环内直接 $extMap[$v['relation_id']] ?? null` |
| 🟠 警告 | `mobile_refund` | **硬编码敏感配置**：MD5 签名盐值 `'1441600902'`、`'2017040606573534'` 直接写死在代码中，违反安全规范且不利于多环境部署。 | 移至配置文件（如 `config/payment.php`），通过 `$this->config->item()` 读取。 | `$salt = $this->config->item('wx_refund_salt');<br>$data['refund_key'] = md5($order_info['_id'] . $order_info['_trade_no'] . $salt);` |
| 🟠 警告 | 文件顶部 | **全局实例化框架对象**：`$CI = &get_instance();` 在类外部全局调用。若文件在框架未完全初始化时被 `include`，将触发致命错误。 | 移除全局调用。依赖 CI 的自动加载机制，或在 `__construct()` 中按需加载。 | `// 删除顶部两行<br>public function __construct() {<br> parent::__construct();<br> $this->load->model('Simple_model');<br>}` |
| 🟠 警告 | `update_after_pay_call_back` | **回调逻辑缺乏事务保护**：连续更新多个关联模型（营收、用户消费、地图数据、销售日志），任一失败将导致数据不一致。 | 包裹在 `$this->db->trans_begin()` 中，或改为发布事件/消息队列异步解耦。 | `$this->db->trans_begin();<br>try { /* 更新逻辑 */ $this->db->trans_commit(); } catch(\Exception $e) { $this->db->trans_rollback(); throw $e; }` |
| 🟡 建议 | 全局方法命名 | **违反 PSR-12 命名规范**：方法名使用蛇形命名（`snake_case`），不符合现代 PHP 标准，降低 IDE 提示与团队协作效率。 | 统一改为驼峰命名（`camelCase`），如 `addOrderPayLog`、`updateAfterPayCallback`。 | `public function addOrderPayLog($merchantId, $adminUid, $type, $relationId, $params, $multPayIndexArr = [])` |
| 🟡 建议 | `refund` 方法 | **严重违反单一职责原则 (SRP)**：方法长达 300+ 行，混合了事务控制、VIP 余额计算、日志落库、网关调用、打印通知、跨日处理等逻辑。 | 拆分为独立私有方法或提取为 `RefundService` 服务类，主方法仅负责流程编排。 | `private function processVipRefund($payData, $amount) { ... }`<br>`private function callPaymentGateway($payData, $amount) { ... }` |
| 🟡 建议 | `add_by_vip_recharge_order` | **代码截断导致审查受限**：文件末尾 `$this-` 处被截断，无法评估完整逻辑。 | 请补充完整代码以便进行闭环审查。 | *(待补充)* |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即修复 SQL 注入漏洞**：`update_refund_amount` 与 `refund` 中的字符串拼接是最高危项。请全面替换为框架提供的参数化查询或数组条件构造方式。
2. **解决退款事务与网关调用不一致**：财务类操作必须保证最终一致性。建议将 `mobile_refund` 移至异步队列执行，或在同步调用失败时记录补偿任务并告警。
3. **消除 N+1 查询**：报表与流水列表接口是高频调用点，务必将循环内的单条查询改为批量 `WHERE IN` 查询，预计可提升 60%~80% 的接口响应速度。
### 🛠 后续重构与优化方向
- **架构解耦**：当前 Model 承担了过多业务逻辑。建议引入 **Service 层** 处理退款、报表聚合等复杂流程，Model 仅负责数据持久化。符合 `phpci`/CI 框架的 `MVC` 最佳实践。
- **配置集中化**：将支付平台映射、MD5 盐值、业务类型常量等硬编码内容统一收敛至 `config/` 目录，支持多商户/多环境动态加载。
- **规范与可维护性**：
- 逐步将方法名重构为 `camelCase`，属性名统一为 `protected/private` 并添加类型声明（PHP 7.4+ 支持）。
- 清理历史注释（如 `// 之前不知道为啥被注释掉...`），补充关键业务分支的 PHPDoc 说明。
- 对 `throwError()` 等全局异常函数进行统一封装，建议替换为 `throw new \RuntimeException()` 配合全局异常处理器，便于日志追踪与 API 标准化返回。
> 💡 **框架适配说明**：本代码高度符合 CodeIgniter 3 的语法特征。若 `phpci` 为基于 CI 深度定制的框架，上述 Query Builder 用法、事务控制及配置加载方式通常完全兼容。如遇特定生命周期钩子差异，建议查阅 `phpci` 官方文档中关于 `Database` 与 `Transaction` 的章节进行微调。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779168858
|
1779168858
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
639
|
22
|
78
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 需求 存取酒员工自存自取 16434
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `09c01c0bb ## 自动代码审查报告
**分支**: app-260616
**提交**: `09c01c0bb36b0f138829ca8465ba81ec4ba03103`
**提交人**: chenjunfeng (developer.jeff.c@gmail.com)
**时间**: 2026-06-09 16:03:54
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：代码实现了较为完整的寄存单业务闭环（创建、打印、列表查询、状态流转），具备一定的防 N+1 查询优化意识。但整体架构偏向“上帝类”模式，核心方法职责过重；存在明显的 SQL 注入隐患与全局变量滥用问题；未遵循现代 PHP 类型声明与 PSR-12 规范。代码末尾被截断，导致 `update_deposit` 方法后半部分无法评估。
- **风险等级**：🔴 高（主要源于 SQL 注入风险、事务与异常处理耦合不当、全局实例污染）
> 📌 **框架适配说明**：代码结构、`$CI = &get_instance()`、`$this->load->model()` 及事务调用方式高度符合 **CodeIgniter 3 (CI3)** 规范。若 `phpci` 为基于 CI3 的定制框架，请确认其底层 Query Builder 与事务管理器是否完全兼容。以下建议以 CI3 最佳实践为基准。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `search_deposit_list` 约第 280 行 | **SQL 注入漏洞**：直接拼接 `$uid` 到 WHERE 条件字符串中，若 `$uid` 未严格校验类型，可导致注入。 | 强制类型转换或使用 Query Builder 的 `where()` 方法构建安全条件。 | `$where['where'][] = '(deposit._admin_id = ' . (int)$uid . ' OR deposit._admin_id = 0)';` |
| 🔴 严重 | 文件顶部第 2 行 | **全局实例污染**：`$CI = &get_instance();` 在类外部声明，破坏封装性，且在 CLI/多请求环境下可能引发状态混乱。 | 移除文件级 `$CI` 声明。在模型内部统一使用 `$this->load` 或构造函数加载依赖。 | `// 删除文件顶部的 $CI = &get_instance();`<br>`// 在方法内使用 $this->load->model('xxx');` |
| 🟠 警告 | `add_deposit` 方法 | **违反单一职责原则 (SRP)**：单方法超 200 行，混合了参数校验、DB 事务、关联表写入、短信/微信推送、打印逻辑。任一环节失败都会导致调试困难。 | 拆分为独立服务类（如 `DepositCreateService`、`DepositNotifyService`、`DepositPrintService`），Model 仅负责数据持久化。 | `// 建议重构为：<br>$service = new DepositCreateService();<br>$result = $service->handle($merchantId, $adminId, $data);` |
| 🟠 警告 | `add_deposit` / `update_deposit` | **事务与异常处理不规范**：`trans_start()` 配合手动 `trans_rollback()` 与 `trans_complete()` 混用，CI3 中 `trans_complete()` 已内置自动回滚机制，手动回滚可能导致事务状态机异常。 | 统一使用 CI3 推荐的事务流，或改用 `trans_begin()` + `trans_commit()` + `trans_rollback()`。 | `try {<br> $this->db->trans_begin();<br> // ... 业务逻辑 ...<br> if ($this->db->trans_status() === FALSE) {<br> $this->db->trans_rollback();<br> return ['success'=>false, 'msg'=>'...'];<br> }<br> $this->db->trans_commit();<br>} catch (\Exception $e) { ... }` |
| 🟠 警告 | `search_deposit_list` 约第 260 行 | **动态 IN 查询未严格过滤**：`implode(',', array_unique($aheadUserIds))` 直接拼入 SQL，若数组元素含非数字字符将引发语法错误或注入。 | 使用 `array_map('intval', $ids)` 清洗数据，或交由框架 Query Builder 的 `where_in()` 处理。 | `$cleanIds = array_map('intval', array_unique($aheadUserIds));`<br>`$this->db->where_in('_ahead_user_id', $cleanIds);` |
| 🟡 建议 | 全局 | **命名规范与拼写错误**：`deposit_printer_opreating` 拼写错误；类名 `Ahead_deposit_model` 大小写混用；数组语法混用 `array()` 与 `[]`。 | 遵循 PSR-12：类名 `AheadDepositModel`，方法名 `depositPrinterOperating`，统一使用短数组语法 `[]`。 | `public function depositPrinterOperating(...)` |
| 🟡 建议 | 全局 | **缺失类型声明与返回值约束**：所有方法无参数类型、无返回值类型声明，降低 IDE 提示与静态分析能力。 | 逐步补充 PHP 7.4+ 类型声明（如 `public function add_deposit(int $merchantId, int $adminId, array $data): array`）。 | `public function add_deposit(int $merchantId, int $adminId, array $data): array` |
| 🟡 建议 | `add_deposit` / `search_deposit_list` | **重复加载模型**：多次调用 `$this->load->model()`，虽 CI3 有缓存机制，但影响可读性。 | 在 `__construct()` 中统一加载高频模型，或使用依赖注入容器。 | `public function __construct() {<br> parent::__construct();<br> $this->load->model(['ahead_yc_merchant_user_model', 'ahead_store_model', ...]);<br>}` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即修复 SQL 注入**：`search_deposit_list` 中的 `$uid` 拼接与 `IN` 查询数组必须经过 `(int)` 强转或使用 Query Builder 安全方法。
2. **清理全局 `$CI` 实例**：移除文件顶部的 `&get_instance()`，避免多进程/CLI 环境下的内存泄漏与状态污染。
3. **规范事务控制流**：统一采用 CI3 标准事务写法，避免 `trans_start()` 与手动 `trans_rollback()` 交叉使用导致的事务状态不一致。
### 🛠 后续重构与优化方向
- **架构分层**：将 `add_deposit` 拆分为 `Validator`（校验）→ `Repository`（数据操作）→ `Notifier`（消息推送）→ `Printer`（打印）。Model 层仅保留 `insert`/`update`/`query` 等纯数据操作。
- **引入 DTO/VO**：使用数组或轻量级对象封装 `$data` 与返回结果，替代魔法数组键名，提升类型安全与可维护性。
- **统一错误处理**：当前混用 `throwError()`（自定义全局函数）与 `try-catch`。建议统一抛出 `\RuntimeException` 或自定义业务异常，由全局异常处理器捕获并格式化返回。
- **补充单元测试**：针对 `search_deposit_list` 的复杂 WHERE 条件拼接、状态流转逻辑编写 PHPUnit 测试用例，覆盖边界条件（如空数组、非法类型、跨店权限）。
- **注意代码截断**：提供的 `update_deposit` 方法在 `$lastTa` 处中断，请补充完整代码以便审查状态机流转、库存扣减逻辑及事务回滚路径。
> 💡 **专家提示**：若 `phpci` 框架已支持 PHP 8+，强烈建议启用 `declare(strict_types=1);` 并全面引入类型声明。对于高频查询的 `search_deposit_list`，可考虑将 `listinfos` 替换为原生 Query Builder 链式调用，并针对 `_merchant_id`, `_shop_id`, `_status`, `_end_time` 建立复合索引以提升分页性能。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780992234
|
1780992234
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
435
|
22
|
48
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 1
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `13307d5ff ## 自动代码审查报告
**分支**: app-260616
**提交**: `13307d5ffe87f702f2bada4dc34c0d48716ff419`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 17:34:22
---
## 1. 审查摘要
- **代码质量评分**：4 / 10 分
- **总体评价**：代码整体具备基础的业务实现能力，但存在严重的架构缺陷与安全隐患。模型层大量使用字符串拼接 SQL、类外部直接执行加载逻辑、控制器直接操作超全局变量，严重违背 MVC 分层原则与 CI 框架最佳实践。部分 SQL 语法存在明显错误，且输出缓冲与 JSON 响应处理不规范，易引发运行时异常。
- **风险等级**：🔴 高（存在 SQL 注入、硬编码密钥、未定义函数调用及语法错误）
> 📌 **框架说明**：根据目录结构（`system/`、`CI_Controller`、`$this->load->` 等）判定为 **CodeIgniter 3.x** 架构。若 `phpci` 为内部定制框架，请对照其官方文档调整组件调用方式，以下建议基于 CI3 标准规范。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_yc_order_model.php` 全局/多处 | `$addsql` 参数直接拼接至 SQL 字符串中，未做参数化或白名单过滤，存在 **高危 SQL 注入漏洞**。 | 废弃 `$addsql` 拼接模式，全面改用 CI Query Builder 或 `$this->db->query($sql, $binds)` 参数化查询。 | `$this->db->where($conditions)->get('ahead_yc_order')->result_array();` |
| 🔴 严重 | `Ahead_yc_order_model.php` 文件顶部 (L3-L5) | 在类外部执行 `$CI =& get_instance();` 及加载模型。PHP 每次 `include` 该文件都会执行，导致状态污染、重复加载或致命错误。 | 移除全局代码，将依赖加载移至 `__construct()` 或通过 CI `autoload.php` 配置。 | `public function __construct() { parent::__construct(); $this->load->model('Simple_model'); }` |
| 🔴 严重 | `Ahead_yc_order_model.php` ~L238 | `get_new_add_people_trend_data` 子查询语法错误：`NOT IN (select DISTINCT(_ahead_user_id))` 缺少 `FROM` 表名，执行必报 SQL 语法错误。 | 补全子查询表名，并明确业务逻辑（如对比历史用户表）。 | `NOT IN (SELECT _ahead_user_id FROM ahead_user WHERE _status=1)` |
| 🟠 警告 | `Api.php` L28-L32 | `jsonEcho` 滥用输出缓冲 (`ob_end_clean`, `ob_start`, `flush`)。若无活跃缓冲会触发 Notice，且 `flush()` 在 CLI/部分 SAPI 下无效，易导致 Headers 冲突。 | 移除缓冲操作，直接设置响应头并输出 JSON，保持控制器职责单一。 | `header('Content-Type: application/json; charset=utf-8'); echo json_encode($result, JSON_UNESCAPED_UNICODE); exit;` |
| 🟠 警告 | `Api.php` L15-L16 | 直接读取 `$_POST` 与 `php://input`，绕过 CI `Input` 类的全局 XSS 过滤与路由安全机制。 | 使用 CI 提供的 `$this->input->raw_input_stream` 或 `$this->input->post()`。 | `$raw = $this->input->raw_input_stream; $this->params = json_decode($raw, true) ?: [];` |
| 🟠 警告 | `Ahead_yc_order_model.php` L30 | 硬编码加密串 `$encrypt = "Vs!Fs7VT";`，违反安全规范，源码泄露即导致密钥暴露。 | 移至 `config/config.php` 或 `.env` 环境变量中，通过 `$this->config->item()` 读取。 | `protected $encrypt_key; public function __construct() { $this->encrypt_key = $this->config->item('encryption_key'); }` |
| 🟠 警告 | `Api.php` L63 | `throwError('参数异常')` 为未定义函数，非 CI 标准方法，若未全局声明将触发 Fatal Error。 | 改用控制器内置的 `$this->error_response()` 或 CI 的 `show_error()`。 | `if (empty($_GET['state']) || empty($_GET['code'])) { $this->error_response('参数异常'); }` |
| 🟡 建议 | `Ahead_yc_order_model.php` 多处 | 模型层直接调用 `json_encode()` 返回数据，违反 MVC 分层原则，降低模型复用性。 | 模型仅返回数组/对象，由 Controller 统一负责序列化与响应格式化。 | `return $result['data'];` (在 Controller 中 `echo json_encode(...)`) |
| 🟡 建议 | `Ahead_yc_order_model.php` L267 | `force index(_merchant_id)` 通过 `strpos` 硬编码触发，缺乏索引评估依据，可能导致查询计划退化。 | 移除硬编码 `FORCE INDEX`，通过 `EXPLAIN` 分析实际执行计划，依赖数据库优化器或添加复合索引。 | 建议添加索引：`ALTER TABLE ahead_yc_order ADD INDEX idx_merchant_shop_time (_merchant_id, _shop_id, _timestamp);` |
| 🟡 建议 | `Api.php` & Model 多处 | 命名风格不统一（如 `getBillDetail` 驼峰 vs CI 常用下划线），注释含冗余/过期信息（如 `caiwl`、`20161013修改`）。 | 遵循 PSR-12 与 CI 规范统一方法命名，清理无效注释，补充 PHPDoc 类型声明。 | `public function get_bill_detail(): void` |
## 3. 总结与行动建议
### 🚨 优先修复项（P0）
1. **彻底修复 SQL 注入风险**：全局排查 `$addsql` 拼接逻辑，替换为 CI Query Builder (`$this->db->where()`, `$this->db->select()`) 或严格参数化查询。
2. **移除模型顶层执行代码**：将 `get_instance()` 和 `load->model()` 移入 `__construct()`，避免文件包含时的副作用。
3. **修复语法错误**：修正 `get_new_add_people_trend_data` 中缺失 `FROM` 的子查询，确保 SQL 可执行。
4. **规范输入输出**：替换 `$_POST/$_GET` 为 `$this->input->`，移除 `ob_*` 缓冲操作，统一使用 `$this->error_response()` 处理异常。
### 🛠 后续重构方向
1. **架构分层优化**：
- **Model**：仅负责数据查询与组装，禁止 `json_encode`、`exit`、`redirect` 等表现层逻辑。
- **Controller**：负责参数校验、调用 Model、格式化响应。建议引入 `Form_validation` 或自定义 DTO 进行入参校验。
- **Service/Repository**：当前 Model 过于臃肿（超 500 行），建议按业务域拆分（如 `OrderQueryService`, `ReportService`），提升可测试性。
2. **性能与数据库优化**：
- 移除硬编码 `FORCE INDEX`，通过慢查询日志定位瓶颈，合理设计复合索引。
- 分页逻辑高度重复，建议封装为 `BaseModel::paginate($builder, $page, $limit)` 或集成 CI `Pagination` 库。
- 避免在循环或高频查询中重复调用 `strtotime()`，可在入口处统一转换为时间戳。
3. **安全与规范落地**：
- 敏感配置（加密串、支付密钥）全部迁移至环境变量或加密配置文件。
- 启用 CI 的 `csrf_protection`（若为 Web 端）或实现 API Token 鉴权机制。
- 统一代码风格：使用 `php-cs-fixer` 或 `PHP_CodeSniffer` 强制对齐 PSR-12，清理历史注释。
> 💡 **提示**：若需进一步审查 `Simple_model` 基类实现、数据库索引结构或支付回调逻辑，请提供对应文件。当前审查基于已提交片段，部分业务上下文可能存在未暴露的依赖。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780306462
|
1780306462
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
480
|
22
|
59
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 1
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `16e0ec6e3 ## 自动代码审查报告
**分支**: app-260616
**提交**: `16e0ec6e3e25170a5a84b90be2523bb5f302c81b`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 19:04:29
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：代码整体业务逻辑清晰，覆盖了多种营收场景的日志记录与报表查询。但存在**静态缓存未区分门店导致的数据错乱**、**手动拼接 SQL 条件引发注入风险**、**循环内执行数据库查询**等严重问题。同时，模型加载分散、重复代码较多，未充分利用框架特性，可维护性与性能有较大优化空间。
- **风险等级**：🔴 高
> 📌 **框架说明**：根据目录结构（`system/`, `application/models/`）及 `$CI = &get_instance()`、`$this->load->model()` 等语法特征，判定为 **CodeIgniter 3.x** 架构。若 `phpci` 为内部定制框架，请结合其底层实现酌情调整框架适配建议。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_date_type_info` (~L405) | **静态缓存未区分 `$shop_id`**。`self::$date_type_info` 仅在首次调用时初始化，后续传入不同门店 ID 时仍返回首个门店的时间范围，导致报表数据严重错乱。 | 移除静态缓存，或改为以 `$shop_id` 为键的多维缓存数组；建议直接使用 CI Cache 驱动或按需计算。 | `if (!isset(self::$date_type_info[$shop_id])) { /* 初始化逻辑 */ } return self::$date_type_info[$shop_id];` |
| 🔴 严重 | `get_community_revenues_sum_data` / `detail_data` (~L235, L335) | **SQL 注入风险**。手动拼接字符串 `'(a._pay_platform=' . $pay_platform . ' ...)'` 并传入查询条件，绕过框架参数绑定与转义机制。若 `$params` 来自用户输入，极易被注入。 | 使用 CI 查询构造器的分组条件方法，或确保输入严格白名单过滤。 | `$this->db->group_start()->where('a._pay_platform', $p1)->where('a._second_pay_platform', $p2)->group_end();` |
| 🟠 警告 | `get_community_revenues_trend` (~L385) | **循环内执行 DB 查询**。在 `foreach ($result as &$v)` 中反复调用 `$this->select()`，若时间维度较多或并发高，将引发严重的 N+1 查询性能瓶颈。 | 改为单次范围查询拉取所有数据，在 PHP 层按时间键聚合映射；或使用 `WHERE IN` / 范围条件一次性获取。 | 一次性查询 `_business_date` 在起止范围内的数据，使用 `array_reduce` 或哈希表在内存中分组累加。 |
| 🟠 警告 | 多处方法内部 (`_add_log`, `get_room_info_by_order` 等) | **频繁动态加载模型**。在业务方法中反复调用 `$this->load->model()`，增加文件 I/O 与内存开销，违反 CI 最佳实践。 | 将依赖模型统一移至 `__construct()` 中加载，或通过 CI `autoload.php` 配置预加载。 | `public function __construct() { parent::__construct(); $this->load->model(['ahead_yc_merchant_model', 'ahead_family_servers_model']); }` |
| 🟠 警告 | `get_community_revenues_data` vs `sum_data` (~L160 vs L200) | **高度重复的聚合逻辑**。两个方法 80% 以上的数据计算与格式化代码完全一致，违反 DRY 原则，后期维护成本高。 | 提取私有聚合方法 `private function format_revenue_stats(array $data): array`，统一处理计算与格式化。 | 将 `foreach` 累加与 `change_number_format` 逻辑抽离，主方法仅负责构建 `$where` 并调用聚合器。 |
| 🟡 建议 | 全局类定义 (~L10) | **类名不符合 PSR-12 规范**。当前为蛇形命名 `Jh_community_shop_revenues_detail_model`，应使用大驼峰（PascalCase）。 | 重命名为 `JhCommunityShopRevenuesDetailModel`，并同步更新所有引用处。 | `class JhCommunityShopRevenuesDetailModel extends Report_model` |
| 🟡 建议 | `add_by_vip_recharge_refund` 等 (~L480) | **循环逐条插入**。在 `foreach` 中调用 `_add_log` 执行单条 `INSERT`，数据量大时数据库交互频繁，性能低下。 | 收集完整数据数组后，使用 `$this->db->insert_batch()` 批量写入。 | `$this->db->insert_batch($this->table_name, $batch_insert_data);` |
| 🟡 建议 | 全局 PHPDoc | **类型声明不准确**。多处 `@return true` 不符合 PHPDoc 规范，应使用 `bool`；魔法数字（如 `1,2,8,9`）硬编码降低可读性。 | 修正注释类型；将业务状态码定义为类常量（如 `const TYPE_INCOME = 1;`）。 | `/** @return bool */` <br> `const PAY_PLATFORM_WX = '1';` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复静态缓存门店隔离问题**：立即调整 `get_date_type_info` 的缓存策略，避免跨门店数据污染。这是当前最可能导致线上报表数据错误的逻辑缺陷。
2. **消除 SQL 注入隐患**：全面审查 `$where` 数组中手动拼接字符串的逻辑，替换为 CI 查询构造器的 `group_start()` / `group_end()` 或 `or_where()` 链式调用，确保参数自动转义。
3. **优化趋势图查询性能**：将 `get_community_revenues_trend` 中的循环查询重构为**单次范围查询 + 内存聚合**。可大幅降低数据库连接压力与响应延迟。
### 🛠 后续重构与优化方向
- **统一模型加载策略**：在 `__construct()` 中集中加载所有依赖模型，或使用 CI 的自动加载机制。避免在高频调用的业务方法中重复 `load->model()`。
- **抽离公共聚合逻辑**：`get_community_revenues_data` 与 `get_community_revenues_sum_data` 的统计逻辑高度重合，建议封装为独立的私有方法，通过参数控制返回结构，提升代码复用率。
- **引入批量操作与事务控制**：对于 `_add_log` 相关的写入场景，若存在批量调用，应改用 `insert_batch()`。同时，建议在 `enforce_con_db()` 切换连接时包裹 `try...finally` 块，确保异常发生时数据库连接状态能正确恢复，防止连接泄漏。
- **规范化与常量管理**：逐步将硬编码的订单类型、支付平台标识提取为类常量，并统一类名与方法命名风格。修正 PHPDoc 类型声明，为后续接入静态分析工具（如 PHPStan/Psalm）打下基础。
> 💡 **提示**：若 `enforce_con_db()` 为自定义多数据源切换方法，请确保其底层已处理连接池复用与异常回滚。建议在核心写入路径添加基础的事务包裹（`$this->db->trans_start()` / `trans_complete()`）以保障财务数据一致性。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780398269
|
1780398269
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
243
|
22
|
19
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 需求 聚旺设备先软关机 16371
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `17ad716cd ## 自动代码审查报告
**分支**: app-260616
**提交**: `17ad716cdae26f841ea9d2c837550eab31b387c8`
**提交人**: chenjunfeng (developer.jeff.c@gmail.com)
**时间**: 2026-05-20 16:10:40
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10
- **总体评价**：代码实现了复杂的 IoT 设备联动控制逻辑，业务覆盖较全。但存在严重的代码重复、死代码残留、同步阻塞调用及框架误用问题。数据库交互未充分利用批量操作，网络请求缺乏容错机制，整体可维护性与生产稳定性存在较大隐患。
- **风险等级**：🟠 中高（存在逻辑死区、Web 进程阻塞风险、高频单条写入导致的性能瓶颈）
> 📌 **框架说明**：根据目录结构（`system/`、`application/`）、`get_instance()`、`$this->load->model()` 等特征，判定该项目实际基于 **CodeIgniter 3 (CI3)** 架构。若确为内部自研 `phpci` 框架，请对照其官方文档调整模型加载与生命周期管理。以下审查基于 CI3/PHP 现代规范进行。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 文件顶部 (1-3行) | 在模型文件顶层直接调用 `$CI = &get_instance();` 加载模型。CI 核心在模型实例化前可能未完全初始化，易引发 `Call to a member function on null` 致命错误。 | 移除顶部全局代码。依赖 CI 的自动加载机制，或在 `__construct()` 中按需加载。 | `// 删除顶部两行<br>class Ahead_intelligent_control_log_model extends Simple_model { ... }` |
| 🔴 严重 | `do_after_sequencer()` | 方法首行直接 `return true;`，导致后续 80+ 行业务逻辑全部成为**死代码**。若为临时调试遗留，将导致回调逻辑永久失效。 | 确认需求后彻底清理死代码，或恢复完整逻辑。建议配合版本控制回滚。 | `public function do_after_sequencer($params) {<br> // 删除 return true;<br> $family_server_id = $params['family_server_id'] ?? ''; ...` |
| 🟠 警告 | `action_data()` & `action_data_power_fist()` | 两个方法代码重复率 >90%，仅设备执行顺序不同。严重违反 DRY 原则，后续新增设备类型需修改两处，极易遗漏。 | 提取公共数据获取逻辑，通过传入**执行顺序数组**或**策略回调**控制流程。 | 见下方重构示例 |
| 🟠 警告 | `power_operate_new()` | `foreach ($types as $tv)` 循环内每次重置 `$line_status = [2,2,2,2,2,2]`。若多房态同时触发，仅最后一次循环的指令生效，状态覆盖存在逻辑隐患。 | 明确多房态优先级，或合并 `$switch_actions` 后统一计算最终线路状态再下发。 | `$final_status = array_fill(0, 6, 2);<br>foreach ($types as $tv) { ... // 累加状态 }` |
| 🟠 警告 | `sequencer_operate()` / `power_operate()` | 循环内调用 `$this->insert($arr)` 执行单条 INSERT；且 `sequencer_operate` 中使用 `usleep(200000)` 阻塞 Web 进程，高并发下易导致 PHP-FPM 超时。 | 收集日志数组后统一使用 `$this->db->insert_batch()`；将 `usleep` 移至消息队列/CLI 异步任务。 | `$logs[] = $arr; // 循环外<br>$this->db->insert_batch($this->table_name, $logs);` |
| 🟠 警告 | `sequencer_operate()` | `json_decode($v['_box_notify_config'], 1)` 未校验 JSON 合法性。若数据库存入非法字符串，将返回 `null` 并触发后续数组访问警告。 | 增加安全解码校验，或使用 PHP 8.3+ `json_validate()`。 | `$config = json_decode($v['_box_notify_config'], true);<br>if (json_last_error() !== JSON_ERROR_NONE) { continue; }` |
| 🟡 建议 | 全局方法命名 | 命名不规范且含拼写错误：`type_to_type_fun`、`action_data_power_fist`（应为 first）、大量魔法数字（如 `1,2,3,06,EDF2`）。 | 遵循 PSR-12，使用语义化命名；提取协议常量；补充类型声明。 | `const DEVICE_PROTOCOL_HEADER = 'EDF2';<br>public function mapControlType(int $control, int $type): int` |
| 🟡 建议 | 全局模型加载 | 频繁在业务方法内 `$this->load->model()`。CI 虽会缓存，但增加解析开销且降低可读性。 | 将高频依赖模型统一移至 `__construct()` 或配置 `autoload.php`。 | `public function __construct() {<br> parent::__construct();<br> $this->load->model(['Ahead_intelligent_power_control_model', 'Ahead_family_servers_model']);<br>}` |
### 💡 核心重复代码重构示例 (`action_data` 与 `action_data_power_fist` 合并)
```php
/**
* 统一设备控制入口
* @param string $execution_order 执行顺序：'power_first' 或 'sequencer_first'
*/
public function execute_device_control($merchant_id, $params, $type = 1, string $execution_order = 'sequencer_first')
{
// 1. 提取公共前置逻辑（获取 room_data, shop_data, control_data 等）...
// 2. 分类设备动作 $breaker_actions, $ttlock_actions, $xinfeng_actions, $sequencer_actions, $switch_actions ...
// 3. 根据顺序执行
$sequence = $execution_order === 'power_first'
? ['power', 'breaker', 'ttlock', 'xinfeng', 'sequencer']
: ['sequencer', 'power', 'breaker', 'ttlock', 'xinfeng'];
foreach ($sequence as $step) {
switch ($step) {
case 'power':
$this->power_operate($merchant_id, $room_data, $shop_data, $data, $types, $type, $switch_actions);
break;
case 'sequencer':
$this->sequencer_operate($sequencer_actions, $merchant_id, $shop_data, $room_data, $data, $type);
break;
// ... 其他步骤
}
}
return true;
}
```
## 3. 总结与行动建议
### 🚀 优先修复的关键问题
1. **清理死代码与错误加载**：立即移除 `do_after_sequencer` 首行的 `return true;` 及文件顶部的 `$CI = &get_instance();`，避免生产环境隐性崩溃。
2. **消除核心重复逻辑**：将 `action_data` 与 `action_data_power_fist` 合并为单一入口，通过参数控制执行顺序，降低后续维护成本。
3. **解除 Web 进程阻塞**：将 `usleep(200000)` 及耗时网络请求（MQTT/HTTP）剥离至异步队列（如 Redis + Supervisor 或 CI CLI 脚本），保障 HTTP 接口响应时间 `< 2s`。
4. **批量写入优化**：将循环内的 `$this->insert()` 替换为 `$this->db->insert_batch()`，单次请求可减少 90% 以上的数据库连接开销。
### 🛠 后续重构与优化方向
- **架构分层**：当前 Model 承担了过多业务编排、协议组装、外部 API 调用职责。建议引入 `Service` 层处理业务流，Model 仅负责数据存取，符合单一职责原则（SRP）。
- **容错与重试机制**：`Mqttapi`、`curlWebsocketApi`、`TtlockApi` 调用均无异常捕获与重试逻辑。建议封装统一的外部服务客户端，集成指数退避重试与失败降级策略。
- **配置与协议管理**：硬编码的协议头（`EDF2`）、线路状态（`2222222222`）、魔法数字应提取至配置文件或常量类，便于后续协议升级。
- **类型安全**：逐步引入 PHP 7.4+ 类型声明（`declare(strict_types=1);`、参数类型、返回值类型），配合静态分析工具（PHPStan/Psalm）提前拦截类型错误。
> ⚠️ **局限性说明**：本次审查基于提供的单一 Model 文件。若 `Simple_model`、`Mqttapi`、`TtlockApi` 等底层组件存在未暴露的缺陷（如 SQL 注入过滤不严、连接池泄漏），可能影响整体安全性。建议结合全链路压测与日志监控进行验证。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779264640
|
1779264640
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
427
|
22
|
44
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 自助转房接口
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `17f28d49e ## 自动代码审查报告
**分支**: app-260616
**提交**: `17f28d49efaa709d5f32331b5ffaca71425346f7`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 16:26:49
---
## 1. 审查摘要
- **代码质量评分**：4 / 10 分
- **总体评价**：代码呈现明显的遗留系统特征，大量使用原生 SQL 拼接、直接访问超全局变量（`$_GET`/`$_POST`）、手动管理输出缓冲及分页逻辑。存在严重的 SQL 注入风险与 N+1 查询性能瓶颈，且未遵循现代 PHP 编码规范与框架生命周期管理。
- **风险等级**：🔴 高
> 📌 **框架说明**：根据代码特征（`CI_Controller`、`defined('BASEPATH')`、`$this->load->`、`$this->db->` 等），判断该项目基于 **CodeIgniter 3.x** 架构（或 `phpci` 为其内部定制分支）。以下审查建议均基于 CI3 官方最佳实践与 PHP 7+ 现代标准。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_yc_order_model.php` (多处方法) | **SQL 注入高危漏洞**：大量方法接收 `$addsql` 参数并直接拼接到 SQL 字符串中（如 `where a." . $addsql`）。若该参数由外部传入或动态生成，将导致严重注入。日期条件也使用字符串拼接绕过查询构造器转义。 | 彻底移除 `$addsql` 拼接模式。统一使用 CI 查询构造器（Query Builder）或严格参数绑定（`$this->db->query($sql, $binds)`）。 | `$this->db->where($where)->get('ahead_yc_order');`<br>替代 `where a." . $addsql` |
| 🔴 严重 | `Api.php::binding()` | **未校验的输入与未定义函数**：直接读取 `$_GET` 且未做类型/存在性校验；调用全局函数 `throwError()` 但未确认是否已加载，若不存在将触发 Fatal Error 中断请求。 | 使用 `$this->input->get()` 获取参数；增加严格校验；统一使用控制器内置的 `error_response()` 替代未定义的全局函数。 | `if (!$this->input->get('state') || !$this->input->get('code')) { return $this->error_response('参数异常'); }` |
| 🟠 警告 | `Api.php::jsonEcho()` | **输出缓冲与生命周期破坏**：滥用 `ob_end_clean()`、`ob_start()`、`die()`。若缓冲区未开启会触发 Warning；`die()` 会跳过 CI 的 `post_controller` 钩子与日志记录。 | 使用 CI 标准输出机制，交由框架处理响应头与缓冲区。 | `$this->output->set_content_type('application/json')->set_output(json_encode($result, JSON_UNESCAPED_UNICODE));` |
| 🟠 警告 | `Ahead_room_change_model.php::get_change_room_info()` | **N+1 查询性能瓶颈**：在 `foreach` 循环中反复调用 `get_one()` 查询数据库。数据量稍大时将导致数据库连接耗尽与响应延迟。 | 使用 `where_in` 一次性获取所有房间数据，在 PHP 内存中构建 ID 映射表后组装字符串。 | `$rooms = $this->ahead_family_servers_model->get_list(['_id' => $all_room_ids], '_id,_name,_room_type_name');`<br>`$map = array_column($rooms, null, '_id');` |
| 🟠 警告 | `Ahead_room_change_model.php` 顶部 | **全局实例化反模式**：在类文件顶部直接执行 `$CI =& get_instance();` 并加载模型。该代码在每次请求（无论是否调用该模型）时都会执行，浪费内存且违反 CI 加载规范。 | 将依赖加载移至 `__construct()` 方法中，或通过 `config/autoload.php` 预加载。 | `public function __construct() { parent::__construct(); $this->load->model('Simple_model'); }` |
| 🟡 建议 | 全局文件 | **PSR-12 规范缺失**：命名风格混乱（驼峰/下划线混用）、缺乏类型声明、魔法数字/字符串泛滥、注释过时。未使用现代 PHP 特性（如 `??`、`??=`、类型提示）。 | 引入 `PHP-CS-Fixer` 统一格式化；为方法参数与返回值添加类型声明；提取硬编码常量至配置或类常量。 | `public function getBillDetail(): void`<br>`const ORDER_STATUS_ACTIVE = 1;` |
| 🟡 建议 | `Ahead_yc_order_model.php` | **分页逻辑重复造轮子**：多处手动计算 `offset`、`totalPage`、`pageStatus`，未复用 CI 内置 `Pagination` 库或统一基类。 | 封装独立的分页服务类（`PaginationService`）或使用框架组件，保持 Model 职责单一。 | 使用 `$this->load->library('pagination');` 或统一返回 `['data' => $list, 'meta' => $pagination]` |
---
## 3. 总结与行动建议
### 🔑 优先修复项（P0/P1）
1. **消除 SQL 注入风险**：立即审查所有包含 `$addsql`、`$_order_id`、日期拼接的查询方法。强制使用 `$this->db->where()`、`$this->db->where_in()` 或参数绑定 `$this->db->query($sql, $params)`。禁止任何未经过滤的字符串拼接。
2. **规范 API 响应与输入处理**：移除 `Api.php` 中的 `ob_*` 与 `die()` 操作，全面改用 `$this->output->set_output()`。所有外部输入必须通过 `$this->input->post()` / `$this->input->get()` 获取，并配合 `form_validation` 或手动类型强转。
3. **修复 N+1 查询**：将 `Ahead_room_change_model::get_change_room_info()` 中的循环查询重构为批量查询+内存映射，预计可降低 70% 以上的数据库交互耗时。
### 🛠 后续重构方向
1. **架构分层与职责分离**：当前 `Ahead_yc_order_model` 承担了大量报表统计、分页计算、数据格式化职责，严重违反单一职责原则（SRP）。建议拆分为：
- `OrderRepository`（数据访问）
- `ReportService`（统计逻辑）
- `PaginationHelper`（分页封装）
2. **引入现代 PHP 特性**：若运行环境支持 PHP 7.4+，建议全面启用类型声明（`declare(strict_types=1);`）、属性类型提示、空合并运算符，并逐步替换老旧的 `array()` 为 `[]`。
3. **安全基线建设**：
- 为所有 API 接口增加统一的鉴权中间件/钩子（Token 校验、权限路由）。
- 敏感操作（如退款、绑定）需补充 CSRF 防护或签名验证机制。
- 移除代码中硬编码的加密串（如 `$encrypt = "Vs!Fs7VT";`），迁移至环境变量或 CI 配置文件中。
> 💡 **局限性说明**：本次审查基于提供的代码片段。由于未提供 `Simple_model` 基类实现、`throwError` 全局函数定义及路由/中间件配置，部分框架适配建议需结合完整项目上下文微调。建议后续提交时附带关键依赖文件以便进行更精准的架构级评估。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780302409
|
1780302409
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
154
|
22
|
7
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - Merge pull request '合并05 🔍 代码审查报告：app-260616 - Merge pull request '合并0519' (#5) from app into app...
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `234bbc930 ## 自动代码审查报告
**分支**: app-260616
**提交**: `234bbc930020fa11e114dd4f1fd5fa7202f11281`
**提交人**: zhangjunnan (121158035@qq.com)
**时间**: 2026-05-19 09:35:01
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了较为完整的业务路由与支付回调逻辑，但存在**严重的安全隐患**（硬编码敏感密钥、CORS 通配、支付回调缺乏幂等性）、**架构设计缺陷**（基类职责严重过载、Helper 耦合数据库查询）以及**规范问题**（拼写错误、调试代码未清理、文件截断）。整体可维护性与安全性亟待提升。
- **风险等级**：🔴 高
> 📌 **框架说明**：提交代码实际基于 **CodeIgniter 3.x** 架构（特征：`defined('BASEPATH')`、`$this->load->model()`、`$this->db->` 等）。以下审查将基于 CI 最佳实践与通用 PHP 规范进行。若项目为 `phpci` 定制分支，请同步对照其官方文档调整。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `MerchantAppServer.php` (约 L430-L435) | 登录接口响应中**硬编码并明文返回**科大讯飞 TTS 密钥（`APPID`, `APISecret`, `APIKey`），极易导致云服务被盗刷及敏感数据泄露。 | 移除前端直传密钥逻辑。改为服务端代理调用，或下发临时签名/Token。若必须下发，需加密传输并配合 IP 白名单。 | `// ❌ 错误：直接暴露密钥<br>'xfyun_tts_config' => ["APPID"=>"5bea616f", "APISecret"=>"...", "APIKey"=>"..."]<br><br>// ✅ 建议：移除或改为服务端代理接口` |
| 🔴 严重 | `WxNotify.php` (L118) | 支付宝回调验签使用硬编码测试公钥 `"test"`，生产环境将导致验签失败或恶意伪造请求绕过。 | 从配置文件读取真实公钥，并严格校验签名与金额。 | `$aopClient->alipayPublicKey = $this->config->item('alipay_public_key');` |
| 🔴 严重 | `WxNotify.php` (全文件) | 支付回调接口**缺乏幂等性控制**。微信/支付宝在网络超时会重试回调，可能导致重复发货、重复充值或状态覆盖。 | 处理前校验订单状态，结合数据库唯一索引或 Redis 分布式锁保证幂等。 | `if ($order['status'] === 'PAID') { exit('SUCCESS'); }` |
| 🟠 警告 | `MerchantAppServer.php` (L38-L40) | 全局设置 `Access-Control-Allow-Origin: *`，存在 CSRF 攻击与数据越权读取风险。 | 限制为可信域名白名单，或根据 `Origin` 请求头动态匹配。 | `header("Access-Control-Allow-Origin: " . ($allowed_origin ?: 'https://yourdomain.com'));` |
| 🟠 警告 | `MerchantAppServer.php` (L60-L150) | 构造函数承担路由解析、鉴权、权限校验、配置加载、日志记录等过多职责，违反单一职责原则，难以单元测试与维护。 | 拆分为独立中间件/钩子（如 `AuthMiddleware`、`PermissionMiddleware`），控制器仅保留业务分发逻辑。 | `// 架构建议：使用 CI Hooks 或自定义 Middleware 处理鉴权与权限` |
| 🟠 警告 | `common_helper.php` (L1-L80) | `get_mac_by_url` 辅助函数中直接 `load->model()` 并执行多次 DB 查询。Helper 应保持轻量无状态，耦合 DB 会导致性能下降与循环依赖。 | 将 DB 查询移至 Model/Service 层，Helper 仅负责 URL 字符串解析并返回结构化参数。 | `// Helper 仅返回解析后的 room_id 或 qrcode_type<br>return ['type' => 'weixin', 'raw' => $family_server_id];` |
| 🟠 警告 | `common_helper.php` (L150+) | Redis 封装函数每次调用都新建连接并 `close()`，高并发下会导致连接池耗尽、TCP 握手延迟及性能瓶颈。 | 使用 CI 内置 Cache 驱动或单例模式复用连接，避免频繁创建/销毁。 | `$this->load->driver('cache', ['adapter' => 'redis', 'backup' => 'file']);` |
| 🟡 建议 | `routes_method.php` (多处 & 末尾) | 1. 多处键名 `'renark'` 拼写错误（应为 `'remark'`）<br>2. 文件末尾截断，缺失闭合括号 `],` 与 `];`，将直接导致 `Parse Error`。 | 全局替换拼写错误，补全数组结构。建议将路由配置迁移至数据库或独立 JSON/YAML 管理。 | `'a617' => ['class' => 'Vip', 'method' => 'changeVipCardPoints', 'remark' => '修改会员积分'],` |
| 🟡 建议 | `WxNotify.php` (L145-L175) | 遗留调试方法 `aliHallNativeNotifytest` 未清理，可能干扰路由分发或暴露测试逻辑。 | 彻底删除或移至独立的 `tests/` 目录，生产代码严禁保留调试入口。 | `// 删除整个 aliHallNativeNotifytest 方法` |
| 🟡 建议 | `common_helper.php` (L138) | `is_float($float)` 类型检查过于严格，传入字符串数字（如 `'1.5'` 或 `$_GET` 参数）会返回 `false` 导致逻辑中断。 | 改用 `is_numeric()` 兼容字符串数字格式。 | `if (!empty($keyName) && is_numeric($float))` |
## 3. 总结与行动建议
### 🚨 优先修复（P0）
1. **移除硬编码敏感信息**：立即下线 `MerchantAppServer.php` 中的讯飞 TTS 密钥，替换为服务端代理或动态签名机制。
2. **修复支付验签与幂等**：修正 `WxNotify.php` 支付宝公钥配置，并在所有支付回调入口增加订单状态校验与防重放锁（如 `Redis SETNX` 或 DB `UPDATE ... WHERE status = 'PENDING'`）。
3. **修复语法错误**：补全 `routes_method.php` 末尾截断的数组结构，全局修正 `'renark'` 拼写错误，避免部署时直接崩溃。
### 🛠 架构与规范优化（P1）
1. **基类瘦身**：`MerchantAppServer` 构造函数代码已超 200 行，建议将 Token 解析、权限校验、日志记录抽离为 CI `Hooks` 或独立 `Middleware` 类，控制器仅保留 `switch` 路由分发。
2. **Helper 职责净化**：`common_helper.php` 中的 Redis 与 DB 操作应迁移至 `libraries/` 或 `models/`。Helper 仅保留纯函数（如字符串处理、格式转换）。
3. **CORS 安全收敛**：将 `Access-Control-Allow-Origin: *` 替换为白名单机制，防止恶意站点跨域调用商家接口。
### 📈 后续重构方向
- **配置外置化**：路由映射、微信模板 ID、支付公钥等配置建议迁移至数据库或 `.env`/`config` 文件，避免硬编码与频繁发版。
- **统一响应与异常处理**：当前 `throwError`、`error_response`、`success_response` 散落在各处，建议封装为统一的 `ApiResponse` 类，结合 CI 的 `Exceptions` 机制实现全局异常拦截。
- **引入静态分析工具**：建议接入 `PHPStan` 或 `Psalm` 进行类型检查，配合 `PHP_CodeSniffer` 强制落地 PSR-12 规范，提升代码可维护性。
> 💡 **局限性说明**：`routes_method.php` 文件末尾存在明显截断，本次审查仅基于已提供片段。若实际文件包含更多逻辑或依赖未提供的 Model/Helper，建议补充完整上下文以便进行更精准的调用链分析。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779154501
|
1779154501
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
322
|
22
|
33
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 需求 赠时报表记录 16382
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `264128049 ## 自动代码审查报告
**分支**: app-260616
**提交**: `2641280494f07cc9cd1c2e260898c2107b7d80ee`
**提交人**: chenjunfeng (developer.jeff.c@gmail.com)
**时间**: 2026-05-26 14:02:06
---
## 1. 审查摘要
- **代码质量评分**：4 / 10 分
- **总体评价**：代码承载了较复杂的订单、支付、交接班及退款业务逻辑，但存在**高危 SQL 注入风险**、**关键逻辑判断错误**、**事务管理不规范**及**严重性能瓶颈**。代码结构特征（如 `$CI = &get_instance()`、`$this->load->model()`、`system/` 目录规范）明确指向 **CodeIgniter 3 (CI3)** 框架，而非 `phpci`（注：`phpci` 为 CI 服务，非框架）。以下审查基于 CI3 最佳实践进行。文件末尾代码截断，影响对 `add_exchange_order` 方法的完整评估。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_sales_record_v2` / `shifting_turnover_v2` | **SQL 注入风险**：多处直接使用字符串拼接构造 SQL 条件（如 `"a._merchant_id=" . $param['merchant_id']`），未使用参数绑定或查询构造器。即使部分使用 `intval()`，仍无法覆盖所有输入路径。 | 全面替换为 CI3 Query Builder 或 `$this->db->escape()`。复杂条件建议使用预处理或严格类型转换。 | `$this->db->where('a._merchant_id', (int)$param['merchant_id']);` |
| 🔴 严重 | `repay_order` (~L340) | **逻辑判断错误**：`if (!$orderInfo['_pay_scene'] != 5)` 为双重否定，实际等价于 `if ($orderInfo['_pay_scene'] == 5)`，极大概率违背业务原意（应为 `!= 5`）。 | 修正为单层判断，或明确注释业务意图。建议开启 PHP 静态分析工具（如 PHPStan）拦截此类错误。 | `if ($orderInfo['_pay_scene'] != 5) { ... }` |
| 🔴 严重 | `cancel_present` (~L450) | **事务管理不规范**：使用 `trans_begin()` 但未配合 `trans_status()` 检查。若中间 `throwError()` 抛出异常中断执行，事务将无法自动回滚，导致数据不一致。 | 改用 CI3 推荐的自动事务 `trans_start()` / `trans_complete()`，或手动校验状态。 | `$this->db->trans_start(); ... if ($this->db->trans_status() === FALSE) { $this->db->trans_rollback(); throwError('...'); }` |
| 🔴 严重 | `correct_order_params` (~L105) | **隐式依赖未初始化**：直接读取 `$this->_openRoomData['_order_id']`，该属性仅在 `timing_to_package()` 中赋值。若外部独立调用本方法将触发 `Undefined property` 致命错误。 | 增加前置状态校验，或改为通过参数显式传入依赖数据。 | `if (empty($this->_openRoomData)) { throwError('开房日志数据未初始化，请先调用 timing_to_package'); }` |
| 🟠 警告 | `get_sales_record_v2` (~L150) | **严重性能瓶颈**：使用 `UNION` 拼接三张大表查询，外层嵌套 `GROUP BY` 与 `LIMIT`。同时执行 4 次独立查询统计金额，全表扫描与临时表排序风险极高。 | 1. 优化为单次查询+窗口函数或临时表。2. 使用 `SQL_CALC_FOUND_ROWS` 替代重复 `COUNT`。3. 确保 `_merchant_id`, `_order_id` 等关联字段建立复合索引。 | 建议拆分统计逻辑，或改用 CI3 分页类配合 `select()`/`get()` 优化。 |
| 🟠 警告 | `shifting_turnover_v2` (~L230) | **PHP 8+ 兼容性隐患**：`do_log($res . '--' . $this->db->last_query()...)` 中 `$res` 为布尔值/对象，PHP 8+ 会触发 `Implicit conversion` 弃用警告。 | 显式转换类型后再拼接。 | `do_log((int)$res . '--' . $this->db->last_query(), 'hljceshi');` |
| 🟠 警告 | 全局多处 | **魔法数字泛滥**：`2, 3, 4, 10, 11, 14, 15, 669` 等硬编码散落在业务逻辑中，严重降低可读性与后期维护成本。 | 提取为类常量或独立配置类，如 `const PAY_PLATFORM_WECHAT = 4;`。 | `const ORDER_TYPE_PACKAGE = 2; const PERM_REPAY = 669;` |
| 🟡 建议 | 全局 | **模型重复加载**：多个方法内重复调用 `$this->load->model()`。CI3 虽会缓存实例，但影响代码整洁度与执行效率。 | 统一移至构造函数 `__construct()` 中加载。 | `public function __construct() { parent::__construct(); $this->load->model(['model_a', 'model_b']); }` |
| 🟡 建议 | `get_multi_pay_sales_count` (~L290) | **疑似占位/废弃代码**：直接返回 `['total' => 0, ...]`，未执行实际查询逻辑，可能导致上层报表数据缺失。 | 确认业务状态。若已废弃请添加 `@deprecated` 注释并清理；若需保留请补全逻辑。 | `// @deprecated 该方法已废弃，请使用 get_multi_pay_sales_count_v2` |
| 🟡 建议 | `add_exchange_order` (末尾) | **代码截断**：文件末尾数组定义未闭合，存在语法错误，无法通过 PHP 解析。 | 补全代码并确保语法正确。受限于当前片段，无法评估该方法完整逻辑。 | `... '_amount' => $value['cost_price'], ); } }` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **彻底消除 SQL 注入风险**：立即将 `get_sales_record_v2`、`shifting_turnover_v2` 等所有原生 SQL 拼接替换为 CI3 Query Builder (`$this->db->where()`, `$this->db->join()`, `$this->db->update()`) 或预处理语句。
2. **修复双重否定逻辑漏洞**：修正 `repay_order` 中的 `!$orderInfo['_pay_scene'] != 5`，避免支付场景校验失效导致资损。
3. **规范事务生命周期**：全局统一使用 `$this->db->trans_start()` 与 `$this->db->trans_complete()`，确保任何异常或中断都能安全回滚。
4. **解除隐式属性依赖**：为 `correct_order_params` 增加数据初始化校验，或重构为纯函数式传参，避免状态污染。
### 🛠 后续重构与优化方向
- **查询性能重构**：`get_sales_record_v2` 的 `UNION + GROUP BY + LIMIT` 结构在数据量增长后将迅速拖垮数据库。建议：
- 将统计逻辑下沉至数据库视图或物化表。
- 使用 `EXPLAIN` 分析执行计划，补充缺失的联合索引（如 `(_merchant_id, _shop_id, _status, _order_type)`）。
- **架构规范化**：
- 提取所有业务状态码、支付方式、权限 ID 至独立配置类或枚举（PHP 8.1+ 推荐 `enum`）。
- 统一错误处理机制：建议将全局 `throwError()` 替换为自定义异常类（如 `BusinessException`），配合全局异常处理器记录堆栈，避免 `try...catch` 吞没原始错误信息。
- **框架适配说明**：当前代码完全遵循 **CodeIgniter 3** 规范。若项目确需迁移至其他框架或升级至 CI4，请优先完成 SQL 注入修复与 Query Builder 替换，CI4 已移除 `$this->db->query()` 的隐式转义，直接拼接将导致致命错误。建议查阅 [CodeIgniter 3 官方文档 - Database Class](https://codeigniter.com/userguide3/database/query_builder.html) 进行平滑过渡。
> ⚠️ **局限性说明**：由于 `add_exchange_order` 方法在文件末尾被截断，本次审查无法评估其事务完整性、数据校验逻辑及潜在的安全风险。请提供完整代码以便进行二次深度审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779775326
|
1779775326
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
436
|
22
|
49
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 1
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `2862c341e ## 自动代码审查报告
**分支**: app-260616
**提交**: `2862c341e1b1477c2b8b263a94dce3580c17cfc2`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 17:34:41
---
## 1. 审查摘要
- **代码质量评分**：`待评估` (0-10 分)
- **总体评价**：当前输入仅提供了项目目录结构，**未包含具体的变更代码内容**。该目录结构高度符合传统 CodeIgniter 3 架构特征。受限于缺失实际代码，暂无法执行逻辑、安全、性能及规范维度的深度审查。
- **风险等级**：`未知` (需补充代码后判定)
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 全局/未提供 | **缺失变更代码**：未提供 `## 变更文件内容` 的具体实现，无法进行实质性审查。 | 请补充具体的代码变更片段（推荐使用 Git Diff 格式，或明确标注 `文件路径:行号` 及完整上下文）。 | 无 |
| 🟠 警告 | `system/` 目录下任意文件 | **直接修改框架核心文件**：若变更直接修改了 `system/helpers/` 或 `system/libraries/` 等核心文件，将导致框架升级冲突、全局副作用及难以追踪的 Bug。 | 采用框架扩展机制：通过 `application/core/` 或 `app/` 目录创建前缀类（如 `MY_`），或使用 Hooks/Events 拦截，避免覆盖源码。 | `class MY_Email extends CI_Email { public function __construct() { parent::__construct(); } }` |
| 🟡 建议 | `system/database/` & `system/helpers/` | **编码规范与现代化适配**：目录结构呈现传统 PHP 风格（无命名空间、下划线命名）。若为现代项目，建议逐步对齐 PSR-12 与 PSR-4。 | 新增代码请严格遵循 PSR-12；若为遗留系统维护，请保持内部命名一致性，避免新旧规范混用导致可读性下降。 | 无 |
## 3. 总结与行动建议
- **优先修复的关键问题**：
1. **补充代码上下文**：请提供具体的变更文件内容（Diff 或完整代码块），以便我按照逻辑、安全、性能、规范、框架适配五个维度输出精准审查。
2. **规避核心目录修改**：若您的变更涉及 `system/` 目录，请立即评估是否可通过继承、钩子或配置覆盖实现，以保障系统可维护性。
- **后续重构或优化方向**：
- **安全基线**：针对数据库操作，确保全面使用查询构建器（Query Builder）或 PDO 预处理语句；针对用户输入输出，严格使用 `htmlspecialchars()` 或框架内置的 XSS 过滤；敏感操作需校验 CSRF Token 与权限中间件。
- **性能优化**：重点排查循环内的数据库查询（N+1 问题）、大数组/对象的内存泄漏、未合理使用的缓存驱动（Redis/Memcached），以及重复的 I/O 操作。
- **框架适配说明**：您提及的 `phpci` 框架在公开生态中较少见，当前目录结构与 **CodeIgniter 3** 完全一致。若确为 CI3，请确保遵循其生命周期规范（如构造函数中加载资源、使用 `$this->load->`、正确调用 `$this->db->` 等）；若为自研/定制框架，请补充其核心加载机制、路由规则与生命周期钩子说明，以便我进行更精准的架构级审查。
- **下一步**：请粘贴具体的代码变更内容，我将立即基于上述维度输出完整的深度审查报告与可直接落地的优化代码。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780306481
|
1780306481
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
399
|
22
|
42
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 需求 包厢停用报表记录维修 16437
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `2babef389 ## 自动代码审查报告
**分支**: app-260616
**提交**: `2babef3899284f6a8961257ab999996cebce6e4b`
**提交人**: chenjunfeng (developer.jeff.c@gmail.com)
**时间**: 2026-05-28 13:34:20
---
## 1. 审查摘要
- **代码质量评分**：4.5 / 10 分
- **总体评价**：该模型承载了大量核心业务逻辑（房态管理、计费、VIP折扣、转房等），但实现方式偏向“脚本化”，存在严重的 SQL 注入风险、全局变量滥用、方法职责过重（God Method）及返回值不一致等问题。代码风格与 PSR-12 规范存在较大差距，且部分逻辑未充分利用框架提供的查询构建器与生命周期机制。
- **风险等级**：🔴 高
- **⚠️ 局限性说明**：您提供的代码在末尾处被截断（`$priv_where['_role_i`），本次审查基于已提供的完整方法进行分析。若截断部分包含关键鉴权或事务逻辑，请补充后二次审查。
- **📌 框架说明**：根据目录结构、`get_instance()`、`$this->load->` 及 `$this->db->` 等特征，判定该代码基于 **CodeIgniter 3** 架构。若 `phpci` 为内部定制分支，请结合其官方文档核对生命周期与组件加载差异。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `list_rooms_info`<br>`list_nearby_family_servers_info`<br>`get_nearby_ids`<br>`get_family_server_ids_by_shop_ids` | **SQL 注入漏洞**：多处直接将外部传入的 `$addsql`、`$shop_ids` 拼接至 SQL 语句中，未进行任何转义或参数绑定，攻击者可构造恶意输入执行任意 SQL。 | 1. 优先使用 CI3 Query Builder 构建查询。<br>2. 若必须拼接，使用 `$this->db->escape_str()` 或严格白名单校验。<br>3. `IN` 查询使用 `$this->db->where_in()`。 | ```php<br>// 原危险写法<br>$sql = "... WHERE _shop_id in " . $shop_ids;<br><br>// 安全写法<br>$ids = array_filter(explode(',', $shop_ids), 'is_numeric');<br>$this->db->where_in('_shop_id', $ids)<br> ->order_by('_id', 'DESC')<br> ->get('ahead_family_servers')<br> ->result_array();<br>``` |
| 🔴 严重 | 文件顶部 (第 9-10 行) | **全局 `$CI` 实例滥用**：在类外部执行 `$CI =& get_instance();` 会在文件被 `require` 时立即触发，破坏框架路由与生命周期，易导致内存泄漏或上下文污染。 | 删除类外部的 `$CI` 声明。CI 框架会自动处理模型继承与加载。如需在方法内使用，应在方法内部按需 `$this->load->helper()`。 | ```php<br>// ❌ 删除文件顶部的这两行<br>$CI =& get_instance();<br>$CI->load->model('Simple_model');<br><br>// ✅ 在构造函数或具体方法中按需加载<br>public function __construct() {<br> parent::__construct();<br> $this->load->helper('common');<br>}<br>``` |
| 🟠 警告 | `get_count_status_room`<br>`get_count_room_by_shop` | **Token 解析未做边界校验**：`list($merchant_id, $uid, $utype, $sign) = explode("_", $token);` 若 token 格式不符（如缺少 `_` 或数量不对），将直接触发 `Warning` 并导致变量未定义，后续逻辑崩溃。 | 解析前校验数组长度，或使用 `sscanf`/正则匹配。建议将 Token 解析逻辑抽离至统一的鉴权中间件/Helper。 | ```php<br>$parts = explode('_', $token);<br>if (count($parts) !== 4) {<br> return ['status' => -1, 'msg' => 'Token格式非法'];<br>}<br>[$merchant_id, $uid, $utype, $sign] = $parts;<br>``` |
| 🟠 警告 | `update_status` vs `update_room_status` | **逻辑重复与状态机不一致**：两个方法功能高度重叠，但一个校验前置状态，一个不校验；且 Redis 更新逻辑分散。易导致并发场景下房态不一致。 | 合并为单一入口方法，通过参数 `$check_prev_status = true/false` 控制校验逻辑。将 Redis 状态同步封装为独立私有方法 `syncRoomStatusToRedis()`。 | ```php<br>public function updateRoomStatus($family_server_id, $status, $pre_status = null, $msg = '', $add_up = []) {<br> if ($pre_status !== null && $pre_status != $this->getCurrentStatus($family_server_id)) {<br> return ['status' => -2, 'msg' => '状态已变更'];<br> }<br> // 统一执行 DB 更新 -> 日志记录 -> Redis 同步<br>}<br>``` |
| 🟠 警告 | `get_change_new_room_info`<br>`get_room_detail` | **方法职责过重（God Method）**：单方法超 150 行，混合了订单查询、VIP折扣计算、低消逻辑、权限校验、按钮权限拼接等。违反单一职责原则，极难测试与维护。 | 引入 **Service 层**（如 `RoomChangeService`, `BillingCalculator`）。Model 仅负责数据存取，业务规则与计算逻辑下沉至 Service。 | 建议重构结构：<br>`Model` -> 数据查询<br>`Service` -> 业务编排、价格计算、状态流转<br>`Controller` -> 参数校验、调用 Service、返回响应 |
| 🟡 建议 | 全局多处 | **返回值类型不一致**：部分返回 `['status' => -1, 'msg' => '...']`，部分返回 `['status' => false]`，部分直接返回 `true`/`array()`。上游调用方需编写大量兼容逻辑。 | 统一响应结构，建议遵循：`['code' => int, 'msg' => string, 'data' => mixed]`。成功统一返回 `code: 0` 或 `code: 1`。 | ```php<br>// 统一规范<br>return ['code' => 0, 'msg' => 'success', 'data' => $result];<br>return ['code' => 1001, 'msg' => '包厢不存在', 'data' => null];<br>``` |
| 🟡 建议 | `self::$room_status`<br>`$function_list` 数组 | **魔法数字与硬编码**：大量使用 `-1, 0, 1, 2, 3` 表示状态，`$function_list` 映射关系冗长且无注释。可读性差，后期扩展易出错。 | 使用 `const` 或 `Enum`（PHP 8.1+）定义状态常量。将功能映射表移至配置文件或独立策略类。 | ```php<br>class RoomStatus {<br> const UNCONNECTED = -1;<br> const FREE = 0;<br> const CONSUMING = 1;<br> const REPAIRING = 2;<br> const CLEANING = 3;<br>}<br>// 使用时：if ($status === RoomStatus::REPAIRING) { ... }<br>``` |
| 🟡 建议 | 全局 | **PSR-12 规范与代码整洁度**：混用 `array()` 与 `[]`；变量命名不规范（`$addsql`, `$_id`）；存在大量注释掉的代码块；包含非专业注释（如 `//无敌了简直`）。 | 1. 统一使用短数组语法 `[]`。<br>2. 遵循 `snake_case` 命名，移除前缀 `_`（除非框架强制）。<br>3. 清理废弃代码，使用 Git 管理历史。<br>4. 移除情绪化/非技术注释。 | 使用 `PHP_CodeSniffer` 或 `PHP-CS-Fixer` 配置 PSR-12 规则进行自动化格式化。 |
## 3. 总结与行动建议
### 🚨 优先修复项（P0）
1. **彻底修复 SQL 注入**：立即替换所有字符串拼接 SQL，全面启用 `$this->db->query_builder()` 或 `$this->db->query($sql, $bindings)`。这是当前最高危的安全漏洞。
2. **移除类外 `$CI =& get_instance();`**：避免框架初始化阶段产生不可预知的副作用。
3. **Token 解析防御**：增加格式校验，防止 `explode` 导致数组越界或变量未定义错误。
### 🛠 后续重构方向
1. **架构分层（Model-Service-Controller）**：
- `Model` 仅保留 CRUD、基础查询与数据映射。
- 将 `get_change_new_room_info`、`get_room_detail` 中的计费、折扣、权限按钮生成逻辑抽离至 `RoomBusinessService`。
- 降低模型耦合度，提升单元测试覆盖率。
2. **统一状态机与响应规范**：
- 定义全局状态常量类，消除魔法数字。
- 制定统一的 API 返回结构，配合全局异常处理器（`show_error` / `show_404` 或自定义 `ApiResponse` 类）。
3. **性能与缓存优化**：
- `get_count_status_room` 等高频统计接口建议引入 Redis 缓存或物化视图，避免每次请求执行 `COUNT` + `GROUP BY`。
- 批量加载模型：在构造函数或初始化方法中统一 `load` 常用模型，避免在循环或条件分支中重复 `$this->load->model()`。
4. **代码规范治理**：
- 接入 CI/CD 静态扫描（PHPStan / Psalm + PHP-CS-Fixer），强制 PSR-12 规范。
- 清理所有注释代码，使用 Git 提交历史替代。
> 💡 **专家提示**：该文件已演变为典型的“大泥球（Big Ball of Mud）”架构。建议在下一个迭代周期中，**以业务域为边界进行垂直拆分**（如 `RoomStatusModel`, `BillingModel`, `PermissionModel`），并配合 Service 层进行逻辑收敛。若需针对截断部分的权限校验逻辑（`$priv_where['_role_i...`）进行专项安全审查，请提供完整代码片段。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779946460
|
1779946460
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
432
|
22
|
46
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 1
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `2cbeb8c33 ## 自动代码审查报告
**分支**: 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 内部构建白名单过滤逻辑。 | `// ❌ 危险<br>$sql = "... WHERE a." . $addsql . " ...";`<br>`// ✅ 安全<br>$this->db->where($addsql_array);` |
| 🔴 严重 | `refund()` 方法 | **硬编码密钥与弱加密**：退款签名使用硬编码字符串 `'1441600902'` 等结合 `md5()` 生成。MD5 已不具备抗碰撞性，且密钥硬编码极易泄露，导致伪造退款请求。 | 将密钥迁移至 `config.php` 或环境变量。使用 `hash_hmac('sha256', ...)` 替代 `md5()`。 | `$secret = config_item('refund_sign_key');`<br>`$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));`<br>`$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 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780305950
|
1780305950
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
568
|
22
|
68
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 用户续费二维码
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `387674004 ## 自动代码审查报告
**分支**: app-260616
**提交**: `387674004b33a862e7a9cd60a048c980faab1d6a`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-05 16:10:58
---
## 1. 审查摘要
- **代码质量评分**：4/10 分
- **总体评价**：代码实现了较为复杂的包厢状态管理、计费转房及权限控制逻辑，但存在多处严重的安全隐患（SQL注入）、架构反模式（全局实例滥用、职责混杂）及类型安全缺陷。整体技术债务较重，需优先修复安全漏洞并重构核心业务流。
- **风险等级**：🔴 高
> 📌 **框架说明**：代码中大量使用 `$CI =& get_instance()`、`$this->load->model()`、`$this->db` 链式调用，语法特征高度符合 **CodeIgniter 3** 架构。若 `phpci` 为贵司内部定制或衍生框架，请以官方文档为准，以下建议基于通用 PHP 规范及 CI 生态最佳实践。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `list_rooms_info`<br>`list_nearby_family_servers_info`<br>`get_nearby_ids`<br>`get_family_server_ids_by_shop_ids` | **SQL 注入漏洞**：多处直接使用字符串拼接构造 SQL 条件（如 `WHERE " . $addsql`、`in " . $shop_ids`），未进行参数绑定或过滤。若参数来自前端或外部接口，将导致数据库被恶意篡改或拖库。 | 全面废弃原生 SQL 拼接，改用 CI Query Builder 或参数化查询。禁止将外部输入直接拼接入 SQL 字符串。 | `$this->db->select('_family_server_id')->where_in('_shop_id', explode(',', $shop_ids))->get('ahead_family_servers')->result_array();` |
| 🔴 严重 | 文件头部 (第 8-9 行) | **全局实例滥用**：在类外部声明 `$CI =& get_instance();` 并加载 Model。CI 框架中 Model 已继承 `$this->load`，此写法会破坏框架生命周期，易引发内存泄漏或上下文污染。 | 删除文件头部的 `$CI` 声明。在类内部直接使用 `$this->load->model()` 或 `$this->db`。若需在非 CI 类中调用，应在方法内部按需获取。 | `// 删除文件开头的：<br>$CI =& get_instance();<br>$CI->load->model('Simple_model');` |
| 🔴 严重 | `get_count_status_room`<br>`get_count_room_by_shop` | **Token 解析越权风险**：`list($merchant_id, $uid, $utype, $sign) = explode("_", $token);` 未校验 Token 分段数量。若格式不符，PHP 8+ 会抛出 Warning，且变量错位将导致商户/用户身份混淆，引发严重越权。 | 增加结构校验，失败时直接拦截。建议使用 `sscanf` 或严格数组解构。 | `$parts = explode('_', $token);<br>if (count($parts) !== 4) return ['status' => -1, 'msg' => 'Token格式非法'];<br>[$merchant_id, $uid, $utype, $sign] = $parts;` |
| 🟠 警告 | `update_status`<br>`update_room_status` | **缺乏事务保护**：状态更新涉及 DB 写入、操作日志记录、Redis/MQTT 通知。若 DB 成功但后续环节失败，将导致“房态与日志/缓存不一致”。 | 使用 `$this->db->trans_start()` 包裹核心逻辑，并校验 `$this->db->trans_status()`。失败时自动回滚。 | `$this->db->trans_start();<br>$re = $this->update(...);<br>$this->load->model(...)->change_room_status(...);<br>$this->db->trans_complete();<br>return $this->db->trans_status() ? ['status'=>1] : ['status'=>-5];` |
| 🟠 警告 | `update_status` 第 78 行 | **松散比较导致逻辑漏洞**：`if ($pre_status == $status)` 使用 `==`。在 PHP 中 `0 == ""` 为 `true`，若传入空字符串或 `0` 将错误拦截合法状态变更。 | 统一使用严格比较 `===`，并在入口处强制类型转换。 | `if ((int)$pre_status === (int)$status) { return ['status' => -3, 'msg' => '当前状态与要修改的状态一致']; }` |
| 🟠 警告 | `update_room_status` 第 108 行 | **死代码/资源浪费**：`$redis_conn = get_aliyun_redis_conn();` 赋值后全程未调用任何 Redis 方法，白白占用连接池资源。 | 移除未使用的变量，或补充实际的 Redis 状态同步逻辑。 | `// 删除 $redis_conn = get_aliyun_redis_conn();` |
| 🟡 建议 | 全局多处 | **魔术数字与类型混杂**：状态值 `-1,0,1,2,3` 硬编码且类型不统一（字符串/整型混用），`in_array` 未开启严格模式，降低可读性且易引发隐式类型转换 Bug。 | 定义类常量，统一输入类型，`in_array` 启用第三个参数 `true`。 | `const STATUS_FREE = 0; const STATUS_CONSUMING = 1; ...<br>if (!in_array((int)$status, self::$room_status, true))` |
| 🟡 建议 | `get_change_room_info` 第 268 行 | **错误抑制符滥用**：`$openRoomFlags = @json_decode($openRoomFlags, true);` 使用 `@` 掩盖解析错误，导致后续逻辑在非法 JSON 时静默失败。 | 移除 `@`，使用 `json_last_error()` 校验，或封装安全解析方法。 | `$openRoomFlags = json_decode($openRoomFlags, true);<br>if (json_last_error() !== JSON_ERROR_NONE) { $openRoomFlags = []; }` |
| 🟡 建议 | `get_room_detail` 等 | **单一职责违背**：`get_room_detail` 超 300 行，混合了权限校验、价格计算、状态映射、视图数据组装。Model 层不应承载复杂业务编排。 | 将计费逻辑、权限过滤、状态机映射抽离至独立的 `RoomService` 或 `BillingCalculator` 类。Model 仅负责 CRUD。 | (架构级重构建议) |
| 🟡 建议 | 文件末尾 | **代码截断**：代码在 `$priv_where['_role_i` 处突然中断，无法审查 `get_room_detail` 的完整权限校验与功能列表生成逻辑。 | 请补充完整代码以便进行闭环审查。 | N/A |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **彻底消除 SQL 注入风险**：立即替换所有字符串拼接的 SQL 语句。使用 `$this->db->where()`、`$this->db->where_in()` 或 `$this->db->query($sql, $bindings)`。
2. **修复 Token 解析与状态比较漏洞**：增加 Token 分段数量校验；将 `==` 替换为 `===` 并统一类型转换，防止越权与状态机错乱。
3. **引入数据库事务**：为 `update_status`、`update_room_status` 等涉及多表/多系统（DB+Redis+MQTT）的状态变更操作包裹事务，确保数据最终一致性。
### 🛠 后续重构与优化方向
1. **架构分层**：当前 Model 承担了过多业务逻辑（计费、权限、状态机、MQTT通知）。建议遵循 **MVC + Service 层** 架构：
- `Model`：仅负责数据持久化与基础查询。
- `Service`：处理转房差价计算、状态流转校验、权限过滤。
- `Helper/Library`：封装 Redis 操作、MQTT 推送、金额格式化（如 `smallChangeFormat`）。
2. **规范框架用法**：
- 移除全局 `$CI =& get_instance()`，依赖 CI 内置的 `$this` 上下文。
- 将频繁调用的 `$this->load->model()` 移至构造函数或采用懒加载，避免重复初始化开销。
- 公开属性 (`public $tableName` 等) 改为 `protected`，遵循封装原则。
3. **类型安全与常量管理**：
- 使用 `const` 或 PHP 8.1+ `enum` 统一管理房态、开房类型、操作码。
- 统一 API 返回结构（如始终返回 `['code' => int, 'msg' => string, 'data' => mixed]`），避免混用 `status`、`success`、布尔值。
4. **性能优化**：
- `get_nearby_ids` 中的字符串拼接可替换为 `implode(',', array_column(...))` 或直接使用 `where_in`。
- 对高频查询（如包厢列表、状态统计）增加 Redis 缓存层，并设置合理的过期策略与缓存击穿防护。
> ⚠️ **局限性说明**：由于提供的代码在 `get_room_detail` 方法末尾被截断，权限校验逻辑、功能按钮动态生成及后续业务流未能完整审查。建议补充完整文件后，可进一步针对权限越权、并发状态冲突及缓存一致性进行深度审计。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780647059
|
1780647059
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
316
|
22
|
32
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 计时开房不需要定时消息
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `390d057d9 ## 自动代码审查报告
**分支**: app-260616
**提交**: `390d057d9ce0881b930cae57cefb0d148883de9c`
**提交人**: zhangjunnan (121158035@qq.com)
**时间**: 2026-05-26 10:21:54
---
## 1. 审查摘要
- **代码质量评分**：4.5 / 10 分
- **总体评价**：该 Helper 文件承载了大量业务工具函数，但存在明显的“上帝文件”特征。代码中混杂了硬编码凭证、已废弃的 PHP 语法、非原子操作、低效的数据库/Redis 调用模式以及不严谨的安全校验。整体架构偏向 PHP 5.x/早期 7.x 时代，未适配现代 PHP 特性与 PSR 规范，存在较高的安全与性能风险。
- **风险等级**：🔴 高
> 📌 **框架说明**：从目录结构（`system/`, `application/helpers/`）及 `get_instance()`、`BASEPATH` 等特征判断，该项目实际基于 **CodeIgniter 3** 架构。以下审查将基于 CI3 最佳实践与现代 PHP (7.4+/8.x) 标准进行。若 `phpci` 为内部定制框架，请结合其官方文档调整组件加载方式。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `alioss_deleteObject` / `alioss_addObject` | **硬编码云厂商密钥**。AccessKey/SecretKey 直接写死在代码中，极易通过版本库泄露导致 OSS 数据被恶意删除或盗刷。 | 将密钥移至 `application/config/oss.php` 或环境变量，通过 CI 配置加载。 | `'accessId' => $CI->config->item('oss_access_id')` |
| 🔴 严重 | `decodeUnicode` | 使用已废弃的 `create_function()`。PHP 7.2 标记废弃，8.0 已彻底移除，且存在 `eval` 级代码注入风险。 | 替换为匿名函数（Closure）。 | `preg_replace_callback('/\\\\u([0-9a-f]{4})/i', function($m){ return mb_convert_encoding(pack("H*", $m[1]), "UTF-8", "UCS-2BE"); }, $str);` |
| 🔴 严重 | `checkDateFormate` | 日期校验逻辑脆弱。`strtotime()` 会自动修正非法日期（如 `2023-02-30` 转为 `2023-03-02`），导致格式比对失效或产生隐蔽 Bug。 | 使用 `DateTime::createFromFormat` 进行严格解析。 | `return DateTime::createFromFormat($formate, $str) !== false;` |
| 🟠 警告 | Redis 系列函数 (`rs_sMembers`, `rs_sAdd` 等) | **频繁创建/销毁连接**。每个函数独立调用 `get_aliyun_redis_conn()` 并 `$obj->close()`，高并发下将耗尽连接池并引发 TCP 握手风暴。 | 采用单例模式缓存连接，或直接使用 CI 内置的 Cache/Redis 驱动。 | `static $redis = null; if(!$redis) $redis = get_aliyun_redis_conn(); return $redis;` |
| 🟠 警告 | `passport_encrypt` / `decrypt` | **弱加密算法**。依赖 `rand()` 与 XOR 异或，非密码学安全，易被频率分析或已知明文攻击破解。 | 替换为 `openssl_encrypt` 或 `sodium_crypto_secretbox`。 | `openssl_encrypt($str, 'AES-256-CBC', $key, 0, $iv);` |
| 🟠 警告 | `doRedisLockRelease` | **非原子性解锁**。先 `GET` 判断再 `DEL`，在并发场景下可能被其他进程抢先删除，导致锁失效或误删他人锁。 | 使用 Lua 脚本保证 `GET` 与 `DEL` 的原子性。 | `if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end` |
| 🟠 警告 | `curlRequest` | 强制关闭 SSL 验证 (`CURLOPT_SSL_VERIFYPEER = false`)，生产环境极易遭受中间人攻击 (MITM)。 | 配置系统 CA 证书路径，或至少对内部域名开启验证。 | `curl_setopt($curl, CURLOPT_CAINFO, '/etc/ssl/certs/ca-certificates.crt');` |
| 🟠 警告 | `getClientIP` | 盲目信任 `HTTP_X_FORWARDED_FOR`，未做 IP 格式校验，攻击者可伪造任意 IP 绕过风控或日志审计。 | 优先使用 `REMOTE_ADDR`，对代理头使用 `filter_var` 严格校验。 | `if (filter_var($ip, FILTER_VALIDATE_IP)) return $ip;` |
| 🟠 警告 | `asyncRequest` | **命名误导**。内部仍使用同步 `curl_exec()`，并未实现真正的异步请求，会阻塞当前进程。 | 若需真异步，应改用 `curl_multi`、消息队列或外部 Worker 进程。 | 使用 `curl_multi_init()` 或投递至 Redis Queue 异步消费。 |
| 🟡 建议 | `rs_hmset` | 函数被完整复制定义了两次，属于冗余代码，增加维护成本。 | 删除重复定义，保留一份即可。 | N/A |
| 🟡 建议 | `getFirstCharter` | 使用 `$str{0}` 访问字符串字符，PHP 7.4 已废弃，8.0 将抛出致命错误。 | 改为标准数组语法 `$str[0]`。 | `$fchar = ord($str[0]);` |
| 🟡 建议 | `doSingleFromTable` | 遍历数组时直接 `unset` 原键并赋新键，会破坏内部数组指针，可能导致数据丢失或死循环。 | 构建新数组返回，避免原地修改。 | `$new = []; foreach($data as $k=>$v) $new[substr($k,1)] = $v; return $new;` |
| 🟡 建议 | 整体结构 | 单文件超 1200 行，职责严重混杂（Redis、OSS、加密、短信、排序、地理计算等），违反单一职责原则。 | 按领域拆分为 `redis_helper.php`, `oss_helper.php`, `crypto_helper.php` 等。 | N/A |
## 3. 总结与行动建议
### 🚨 优先修复项（P0/P1）
1. **移除硬编码凭证**：立即将 OSS `accessId`/`accessKey` 抽离至配置文件或 `.env`，并轮换已泄露的密钥。
2. **替换废弃语法**：全局替换 `create_function()` 为匿名函数，将 `$str{0}` 改为 `$str[0]`，确保兼容 PHP 8.x。
3. **修复分布式锁缺陷**：将 `doRedisLockRelease` 改为 Lua 脚本执行，避免高并发下的竞态条件。
4. **优化 Redis 连接管理**：引入连接复用机制（单例或 CI Cache Driver），消除每次请求的 TCP 握手开销。
### 🛠 后续重构与优化方向
- **架构拆分**：当前 `common_helper.php` 已演变为“垃圾桶”文件。建议按业务域拆分为独立 Helper，并在 `autoload.php` 中按需加载，降低内存占用。
- **安全加固**：
- 废弃自定义的 `passport_encrypt`，全面迁移至 `openssl` 或 `libsodium`。
- 为所有外部请求（cURL、IP 解析、二维码解析）增加超时控制、重试机制与输入白名单校验。
- **规范对齐**：
- 统一命名规范（推荐 `snake_case` 或 `camelCase`，避免 `rs_sMembers` 与 `get_mac_by_url` 混用）。
- 补充类型声明（PHP 7+ 支持 `function foo(string $key, int $timeout): bool`），提升静态分析能力。
- 遵循 PSR-12 缩进与括号规范，移除冗余注释。
- **框架适配提示**：CI3 的 Helper 设计初衷是轻量级工具函数。频繁在 Helper 中调用 `get_instance()->load->model()` 会破坏 MVC 边界。建议将涉及复杂业务逻辑（如 `get_mac_by_url`）的代码迁移至 `Service` 层或 `Model` 层，Helper 仅保留纯数据处理函数。
> ⚠️ **局限性说明**：提供的代码在末尾 `import($file)` 函数处被截断，无法评估该函数的完整逻辑。若该函数涉及动态文件包含（如 `include $file`），需重点审查路径遍历漏洞（Path Traversal）。建议补充完整代码以便进行闭环审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779762114
|
1779762114
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
310
|
22
|
30
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 请求参数该json
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `3cb0eccba ## 自动代码审查报告
**分支**: app-260616
**提交**: `3cb0eccbae21e2151f4db6856d18d5869042b67c`
**提交人**: zhangjunnan (121158035@qq.com)
**时间**: 2026-05-26 09:43:17
---
## 1. 审查摘要
- **代码质量评分**：4/10 分
- **总体评价**：该文件承担了过多职责，将工具函数、业务逻辑、第三方 SDK 调用、数据库查询及缓存操作全部耦合在单一 Helper 中。存在严重的安全隐患（硬编码云密钥、弱加密算法）、明显的性能瓶颈（频繁创建/销毁 Redis 连接）、多处 PHP 7.2+/8.0+ 已废弃语法，以及非原子的分布式锁实现。整体可维护性与扩展性较差。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `alioss_deleteObject` / `alioss_addObject` | **硬编码云存储密钥**：AccessKey 与 SecretKey 直接写死在代码中，极易泄露导致数据被恶意删除或盗刷。 | 将密钥迁移至 `config/oss.php` 或环境变量，通过 `$CI->config->item()` 读取。 | `$param = $CI->config->item('aliyun_oss');` |
| 🔴 严重 | `passport_encrypt` / `passport_decrypt` | **弱加密算法**：使用 `srand/rand` + XOR 异或实现加密，随机数可预测，极易被逆向破解，不符合现代安全标准。 | 废弃该实现，改用 PHP 原生 `openssl_encrypt/decrypt` 或 CI3 内置的 `Encryption` 库。 | `openssl_encrypt($str, 'AES-256-CBC', $key, 0, $iv);` |
| 🔴 严重 | `decodeUnicode` | **使用已废弃函数**：`create_function` 在 PHP 7.2 已废弃，PHP 8.0 已彻底移除，会导致 Fatal Error。 | 替换为匿名函数（Closure）。 | `preg_replace_callback('/\\\\u([0-9a-f]{4})/i', function($m){ return mb_convert_encoding(pack("H*", $m[1]), "UTF-8", "UCS-2BE"); }, $str);` |
| 🔴 严重 | `doRedisLockRelease` | **分布式锁竞态条件**：先 `get()` 判断再 `del()` 是非原子操作。高并发下可能误删其他进程持有的锁。 | 使用 Lua 脚本保证 `GET` 与 `DEL` 的原子性，或升级 Redis 2.6+ 的 `EVAL`。 | `return $redis->eval("if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end", 1, $key, $value);` |
| 🟠 警告 | 所有 `rs_*` 函数 | **频繁建立/关闭 Redis 连接**：每个函数内部都调用 `get_aliyun_redis_conn()` 并执行 `$obj->close()`，造成严重的 TCP 握手开销与性能损耗。 | 移除 `$obj->close()`，采用单例模式或复用 CI 的 Redis 驱动缓存连接。请求结束时统一释放。 | 封装 `RedisService` 类，内部维护 `private static $instance;` |
| 🟠 警告 | `get_mac_by_url` | **重复加载模型与实例化**：多次调用 `get_instance()` 和 `$CI->load->model()`，逻辑分支冗长，难以测试与维护。 | 提取为独立 Service 类，模型在构造函数中注入一次。使用策略模式或配置映射替代硬编码 `strpos`。 | `$this->familyModel = $CI->load->model('ahead_family_servers_model', '', TRUE);` |
| 🟠 警告 | `doSingleFromTable` | **键名处理逻辑缺陷**：`substr($k, 1)` 强依赖键名以 `_` 开头。若传入普通键名会导致数据覆盖或丢失。 | 增加前缀判断，安全剥离下划线。 | `if (str_starts_with($k, '_')) { $data[substr($k, 1)] = $v; unset($data[$k]); }` |
| 🟠 警告 | `curlRequest` | **禁用 SSL 证书验证**：`CURLOPT_SSL_VERIFYPEER => false` 会暴露于中间人攻击（MITM）风险中。 | 配置有效的 CA 证书路径，或至少记录安全警告。生产环境严禁关闭验证。 | `curl_setopt($curl, CURLOPT_CAINFO, '/path/to/cacert.pem');` |
| 🟠 警告 | `checkWXClient` | **类型比较错误**：`preg_match` 返回的 `$useragent` 是数组，直接与字符串 `'5.0'` 比较会触发 Warning 且逻辑失效。 | 应比较捕获组 `$useragent[1]`。 | `if (isset($useragent[1]) && version_compare($useragent[1], '5.0', '<'))` |
| 🟡 建议 | `rs_hmset` | **函数重复定义**：文件中存在两个完全相同的 `rs_hmset` 函数，违反 PHP 语法规范（会报 Cannot redeclare）。 | 删除其中一个冗余定义。 | 无 |
| 🟡 建议 | `getFirstCharter` | **废弃的字符串访问语法**：`$str{0}` 在 PHP 8.0 中已移除，会引发 Fatal Error。 | 统一改为方括号语法 `$str[0]`。 | `$fchar = ord($str[0]);` |
| 🟡 建议 | `parseQrcodeContent` | **依赖外部不稳定服务**：调用 `zxing.org` 公共接口解析二维码，无超时控制，易受网络波动或接口下线影响。 | 改用本地 PHP 二维码解析库（如 `chillerlan/php-qrcode` 或 `endroid/qr-code`）。 | 引入 Composer 包替代 `file_get_contents` |
| 🟡 建议 | 全局 | **违反框架分层规范**：Helper 文件不应包含模型查询、第三方 SDK 实例化及复杂业务流。代码结构明显为 CodeIgniter 3 风格，非 `phpci`。 | 将业务逻辑迁移至 `application/libraries/` 或 `application/services/`，Helper 仅保留纯函数工具。 | 遵循 CI3 `libraries` 规范，使用 `$this->load->library()` 调用。 |
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **立即移除硬编码密钥**：将阿里云 OSS、Redis、短信平台的 AccessKey/Secret 全部抽离至配置文件或 `.env`，并通过 CI 的 Config 组件读取。
2. **替换弱加密算法**：废弃 `passport_*` 系列函数，全面迁移至 `openssl` 或框架内置加密组件。
3. **修复分布式锁竞态条件**：使用 Lua 脚本重写 `doRedisLockRelease`，确保 `GET` 与 `DEL` 的原子性。
4. **消除 PHP 8 兼容性问题**：替换 `create_function`，修正 `$str{0}` 为 `$str[0]`，修复 `checkWXClient` 的数组比较逻辑。
### 🛠 后续重构与优化方向
1. **架构解耦（单一职责原则）**：
- 当前文件是一个“上帝文件”。建议按功能拆分为：`RedisService.php`、`CryptoService.php`、`SmsService.php`、`UrlParserService.php`、`OssService.php`。
- Helper 文件仅保留无状态、无副作用的纯函数（如 `getDistance`、`floor_4`、`create_random_num`）。
2. **Redis 连接池优化**：
- 移除所有 `$obj->close()` 调用。在 CI3 中，建议封装一个 `RedisClient` 单例类，利用 `__destruct()` 或 CI 的 `shutdown` 钩子统一释放连接，或直接使用 CI 内置的 `Cache` 驱动（`$this->load->driver('cache', ['adapter' => 'redis'])`）。
3. **框架适配说明**：
- 代码中大量使用 `get_instance()`、`load->model()`、`defined('BASEPATH')`，这是典型的 **CodeIgniter 3** 架构特征，而非 `phpci`。若项目确为 CI3，建议充分利用其 `Hooks`、`Libraries` 和 `Config` 机制；若计划迁移至 `phpci` 或其他现代框架，需彻底重构依赖注入方式。
4. **代码规范与可测试性**：
- 遵循 PSR-12 命名规范，统一使用驼峰或下划线。
- 为复杂逻辑（如 `get_mac_by_url`）编写单元测试，剥离 `get_instance()` 依赖，改用构造函数注入模型实例，提升可测试性。
> 💡 **提示**：由于提供的代码片段末尾 `import($file)` 函数被截断，且文件整体体积庞大，本次审查基于已提供内容。建议在重构前使用 `phpstan` 或 `psalm` 进行静态分析，并配合 `php-cs-fixer` 自动化格式化。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779759797
|
1779759797
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
643
|
22
|
81
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 预订列表
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `422c54fb5 ## 自动代码审查报告
**分支**: app-260616
**提交**: `422c54fb5bc9fc67619ac2b5c777d7be5b60df9e`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-09 16:52:26
---
## 1. 审查摘要
- **代码质量评分**：4.5 / 10 分
- **总体评价**：代码实现了较为复杂的商户端业务逻辑，但存在典型的“巨型控制器/模型”反模式。安全层面存在硬编码密钥与 SQL 注入风险；性能层面存在明显的 N+1 查询与重复资源加载；架构层面严重违反单一职责原则，且混用了 CodeIgniter 3 的底层特性（注：项目结构及语法特征高度吻合 CI3，非 `phpci` 框架，以下审查基于 CI3 最佳实践）。整体需进行系统性重构。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `MerchantAppServer.php` (约第350行) | **硬编码敏感凭证**：`xfyun_tts_config` 直接暴露了第三方 API 的 `APPID`、`APISecret` 和 `APIKey`，极易导致服务被盗刷或数据泄露。 | 将敏感配置移至 `application/config/` 下的独立配置文件或环境变量中，通过 `$this->config->item()` 读取。 | `// config/xfyun.php<br>return ['appid' => 'xxx', 'secret' => 'xxx'];<br><br>// Controller<br>$config = $this->config->item('xfyun');` |
| 🔴 严重 | `Ahead_book_model.php` (第5行) | **框架生命周期违规**：在类外部直接调用 `$CI = &get_instance();`。CI 框架在文件加载阶段尚未完成初始化，会导致致命错误或不可预期的行为。 | 移除文件顶部的全局调用。在类方法内部按需使用 `$this->load->` 或 `$CI = &get_instance()`。 | `// 删除文件顶部的 $CI = &get_instance();<br>// 在方法内部使用：<br>$CI =& get_instance();` |
| 🔴 严重 | `Ahead_book_model.php` (`get_book_list` 方法内) | **SQL 注入漏洞**：`$where_str[] = "(book._book_no LIKE '%" . $params['book_no'] . "%' ..."` 直接拼接用户输入，未进行转义或参数绑定。 | 使用 CI Query Builder 的 `like()` 方法或 `$this->db->escape_like_str()` 进行安全过滤。 | `$search = $this->db->escape_like_str($params['book_no']);<br>$this->db->group_start()<br> ->like('book._book_no', $search, 'both')<br> ->or_like('book._customer_contact', $search, 'after')<br>->group_end();` |
| 🔴 严重 | `MerchantAppServer.php` (`__construct`) | **初始化逻辑断裂**：通过 `if ($this->router->fetch_method() !== "uploadPic")` 跳过核心初始化。若其他未白名单方法被调用，将因 `$this->request`、`$this->stream` 等属性未定义而抛出 `Undefined property` 或空指针异常。 | 移除方法级白名单拦截。改为在 `__construct` 中安全初始化基础属性，或在具体方法开头按需校验。 | `// 移除 if 判断<br>$this->stream = json_decode(file_get_contents('php://input'), true) ?? [];` |
| 🟠 警告 | `Ahead_book_model.php` (`get_book_list` 循环内) | **N+1 查询性能瓶颈**：`foreach` 循环中逐行调用 `$this->ahead_vip_model->get_vip_info_by_recharge()`，数据量大时将导致数据库连接耗尽与响应延迟。 | 改为批量查询：先收集所有 `customer_contact`，使用 `WHERE IN` 一次性查出 VIP 信息，再在 PHP 中映射到对应行。 | `$contacts = array_column($list['rows'], 'customer_contact');<br>$vip_data = $this->ahead_vip_model->get_batch_by_mobiles($contacts);<br>// 循环中通过 $vip_data[$row['customer_contact']] 赋值` |
| 🟠 警告 | `MerchantAppServer.php` (`index` 方法) | **重复加载模型与配置**：多个 `case` 分支中重复执行 `$this->load->model()` 和 `$this->config->load()`，增加 I/O 开销与内存占用。 | 将公共依赖的模型/配置提取至 `__construct` 或类属性中按需懒加载。 | `// __construct 中统一加载<br>$this->load->model(['ahead_merchant_role_priv_model', 'ahead_yc_shop_model']);` |
| 🟠 警告 | `MerchantAppServer.php` (约第15行) | **CORS 策略过于宽松**：`header("Access-Control-Allow-Origin:*");` 允许任意域名跨域请求，易被恶意站点利用发起 CSRF 或数据窃取。 | 根据实际业务配置可信域名白名单，或限制为 App 端特定 `User-Agent`/`Origin`。 | `$allowed = ['https://app.yourdomain.com'];<br>if (in_array($_SERVER['HTTP_ORIGIN'] ?? '', $allowed)) {<br> header("Access-Control-Allow-Origin: {$_SERVER['HTTP_ORIGIN']}");<br>}` |
| 🟡 建议 | `MerchantAppServer.php` (`index` 方法) | **魔法数字与硬编码泛滥**：`case '0005'`、`$permission_id = 534`、`$unsetMenuIds = [694, 849...]` 等缺乏语义化定义，维护成本极高。 | 提取为类常量或独立配置文件（如 `config/permissions.php`），使用枚举或常量映射。 | `const FUNC_LOGIN = '0005';<br>const PERM_VIP_RECHARGE_INVALID = 534;` |
| 🟡 建议 | `MerchantAppServer.php` (约第200行) | **数组过滤逻辑低效**：使用 `foreach` + `unset` + `array_values()` 过滤菜单，可读性差且性能不佳。 | 改用 `array_filter()` 结合闭包函数，代码更简洁且符合函数式编程规范。 | `$menus = array_values(array_filter($menus, function($v) use ($unsetMenuIds) {<br> return !in_array($v['id'], $unsetMenuIds) && !in_array($v['parentid'], $unsetMenuIds);<br>}));` |
| 🟡 建议 | `MerchantAppServer.php` / `Ahead_book_model.php` | **命名规范与拼写错误**：`AplicationController` 拼写错误；变量命名混用驼峰与下划线；注释含大量历史标记（如 `add by nan 17.10.25`）。 | 遵循 PSR-12 规范：类名 PascalCase，方法/属性 camelCase，常量 UPPER_SNAKE_CASE。清理过期注释。 | `class MerchantAppServer extends ApplicationController` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即移除硬编码密钥**：将 `xfyun_tts_config` 等敏感配置迁移至环境变量或加密配置文件中，避免凭证泄露。
2. **修复 SQL 注入风险**：全面审查 `Ahead_book_model.php` 中的 `$where_str` 拼接逻辑，统一替换为 CI Query Builder 的安全绑定方法。
3. **纠正框架生命周期调用**：删除 `Ahead_book_model.php` 文件顶部的 `$CI = &get_instance();`，防止框架初始化冲突。
### 🛠 后续重构与优化方向
1. **架构拆分（Controller -> Service/Repository）**：
- 当前 `MerchantAppServer` 承担了路由分发、鉴权、权限校验、数据组装、业务逻辑等所有职责，违反单一职责原则。
- **建议**：按业务域拆分为独立控制器（如 `AuthController`, `OrderController`, `PrinterController`），并将复杂业务逻辑下沉至 `Service` 层，模型仅负责数据持久化。
2. **性能优化策略**：
- 解决 `get_book_list` 中的 N+1 查询问题，采用批量加载或 `JOIN` 预加载。
- 将重复的 `$this->load->model()` 移至构造函数或使用 CI 的自动加载配置。
- 对高频调用的权限校验（如 `check_priv`）引入 Redis 缓存，降低数据库压力。
3. **规范化与可维护性提升**：
- 建立全局常量/配置中心管理魔法数字（接口号、权限ID、菜单ID等）。
- 统一输入校验层：在 `__construct` 或中间件中统一解析 JSON、校验 Token 格式、过滤非法字符，避免在每个 `case` 中重复处理。
- 补充异常处理与日志记录：当前 `try-catch` 仅返回失败提示，建议接入统一日志组件（如 Monolog）记录堆栈，便于线上排查。
> 📌 **注**：项目代码结构、加载方式（`$this->load->`、`get_instance()`、`BASEPATH`）与 **CodeIgniter 3** 高度一致。若实际使用的是内部封装的 `phpci` 框架，请核对上述 CI3 特性是否被框架兼容或重写。建议查阅框架官方文档确认路由分发、模型加载及安全过滤的最佳实践。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780995146
|
1780995146
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
617
|
22
|
77
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - Merge pull request '开房套餐 🔍 代码审查报告：app-260616 - Merge pull request '开房套餐转房增加房态判断。' (#75) from app...
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `48af25d1e ## 自动代码审查报告
**分支**: app-260616
**提交**: `48af25d1eb8d8e97ce1b9fc107d08baf2a9eb74e`
**提交人**: zhangjunnan (121158035@qq.com)
**时间**: 2026-06-09 10:36:26
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了较为完整的商家端业务逻辑，但整体架构偏向传统的“胖控制器+贫血模型”模式。存在**硬编码敏感密钥**、**SQL注入风险**、**N+1查询性能瓶颈**及**事务处理不规范**等关键问题。代码规范与 PSR-12 存在较大偏差，魔法数字泛滥，可维护性较低。
- **风险等级**：🔴 高
> 📌 *注：提示中提及 `phpci` 框架，但实际代码结构、加载方式（`$this->load->`、`get_instance()`、`BASEPATH`）均明确指向 **CodeIgniter 3.x**。以下审查将基于 CI3 最佳实践与通用 PHP 安全规范进行。*
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `MerchantAppServer.php`<br>(约 150-160 行) | **硬编码敏感 API 密钥**：科大讯飞 `APPID`、`APISecret`、`APIKey` 直接暴露在控制器中，极易导致密钥泄露与盗刷。 | 将敏感配置移至 `application/config/` 或环境变量中，通过 `$this->config->item()` 读取。生产环境严禁硬编码。 | `// config/xfyun.php<br>return ['appid'=>getenv('XFYUN_APPID'), ...];<br>// 控制器中<br>$config = $this->config->item('xfyun');` |
| 🔴 严重 | `Ahead_yc_merchant_user_model.php`<br>`get_user_shop_page()` 等方法 | **SQL 注入漏洞**：直接使用字符串拼接构造 `WHERE` 与 `LIKE` 条件（如 `"... like '%" . $params['name'] . "%'"`），未使用查询构建器转义。 | 全面改用 CI3 Query Builder 的 `like()`、`where()` 方法，或手动使用 `$this->db->escape()`。 | `$this->db->like('user._name', $params['name'], 'both');<br>// 替代原有的字符串拼接` |
| 🔴 严重 | `Ahead_yc_merchant_user_model.php`<br>`check_token()` | **弱加密验证 Token**：使用 `md5()` 拼接静态盐值验证 Token，存在碰撞风险且无过期机制，易被重放攻击。 | 升级为 `hash_hmac('sha256')` 或引入 JWT。Token 生成时应绑定时间戳并校验有效期。 | `hash_hmac('sha256', $payload, $secret_key);<br>// 结合 Redis 设置 TTL 实现会话管理` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`get_list()` | **N+1 查询性能瓶颈**：在 `foreach` 循环中频繁调用 `$this->ahead_yc_order_model->get_one()` 获取关联数据，导致数据库连接数激增。 | 使用 `WHERE IN` 批量查询或 `JOIN` 关联表一次性获取数据，或使用 CI 缓存机制。 | `$ids = array_column($order_info, 'relation_order_id');<br>$orders = $this->ahead_yc_order_model->get_by_ids($ids);<br>// 循环中通过数组映射获取` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`invalid_book()` | **事务回滚机制不健全**：在 `$this->db->trans_start()` 后直接调用自定义 `throwError()`，若该函数未抛出标准异常，可能导致事务挂起或数据不一致。 | 使用 `try-catch` 包裹事务逻辑，确保异常时强制 `trans_rollback()`，并依赖 CI 的 `trans_status()` 判断。 | `try { $this->db->trans_start(); ... } catch(\Exception $e) { $this->db->trans_rollback(); throw $e; }` |
| 🟠 警告 | `MerchantAppServer.php`<br>`index()` | **控制器职责过重 (Fat Controller)**：单方法超 300 行，混杂权限校验、菜单过滤、配置加载、数据组装，违反单一职责原则。 | 将业务逻辑下沉至 `Service` 或 `Repository` 层，控制器仅负责路由分发与请求/响应转换。 | `// 控制器<br>$data = $this->login_service->handleLogin($this->stream);<br>$this->success_response($data);` |
| 🟡 建议 | 全局多处 | **魔法数字与硬编码 ID 泛滥**：如 `permission_id = 534`、`$unsetMenuIds = [694, 849...]` 等散落在代码中，后期维护成本极高。 | 提取为常量类（如 `PermissionConst::RECHARGE_INVALID = 534`）或写入配置文件。 | `class MenuConst { const FILTER_IDS = [694, 849, 824, 1250]; }` |
| 🟡 建议 | 全局多处 | **命名规范与 PSR-12 不符**：类名使用下划线（`Ahead_book_order_model`），变量混用驼峰与下划线，注释含过期人员标记（`edit by nan 17.10.25`）。 | 遵循 PSR-12：类名 `PascalCase`，方法/属性 `camelCase`，清理历史注释，使用 PHPDoc 规范。 | `class AheadBookOrderModel extends Simple_model { ... }` |
| 🟡 建议 | `Ahead_yc_merchant_user_model.php` | **频繁使用 `get_instance()`**：在 Model 中多次调用 `$CI = &get_instance();` 获取 CI 实例，增加耦合且影响性能。 | CI3 的 Model 已继承 `CI_Model`，可直接使用 `$this->load->model()` 或 `$this->config->item()`。 | `// 移除 $CI = &get_instance();<br>$this->load->model('ahead_yc_merchant_model');` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即移除硬编码密钥**：将 `MerchantAppServer.php` 中的讯飞 API 密钥、加密盐值等迁移至配置文件或 `.env`，并检查版本控制历史是否已泄露。
2. **修复 SQL 注入漏洞**：全面审查 `Ahead_yc_merchant_user_model.php` 中所有动态拼接 SQL 的地方，替换为 CI Query Builder 或参数化查询。
3. **升级 Token 验证机制**：废弃 MD5 静态盐方案，引入带过期时间的 HMAC-SHA256 签名或标准 JWT，并在 Redis 中维护会话黑名单。
### 🛠 后续重构与优化方向
1. **架构分层改造**：
- 将 `MerchantAppServer::index()` 拆分为 `AuthService`、`MenuService`、`PermissionService`。
- 控制器仅保留：参数接收 -> 调用 Service -> 格式化响应。
2. **数据库查询优化**：
- 消除 `get_list()` 等方法的 N+1 查询，改用 `JOIN` 或批量 `WHERE IN`。
- 对高频读取的配置数据（如权限列表、菜单树）引入 Redis 缓存，设置合理 TTL。
3. **规范化与工程化**：
- 统一类名与文件命名规范，清理 `//edit by xxx` 等无效注释。
- 将散落的权限 ID、菜单 ID、状态码提取至 `config/constants.php` 或独立常量类。
- 引入静态分析工具（如 PHPStan / Psalm）与代码规范检查（PHP_CodeSniffer PSR-12），纳入 CI/CD 流程。
> ⚠️ **局限性说明**：`MerchantAppServer.php` 代码在 `case "1001"` 处被截断，未能完整审查该分支的结账取消逻辑。若该分支涉及资金扣减或订单状态变更，请补充完整代码以便进行事务与并发安全审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780972586
|
1780972586
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
323
|
22
|
34
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 需求 赠时报表记录 16382
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `4f497336f ## 自动代码审查报告
**分支**: app-260616
**提交**: `4f497336fdaef33cedee9de5e99c8ffaed4a1686`
**提交人**: chenjunfeng (developer.jeff.c@gmail.com)
**时间**: 2026-05-26 14:04:50
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了较为复杂的订单转换、交接班、重新支付及报表统计逻辑，业务覆盖度较高。但存在大量**原生 SQL 拼接**、**逻辑运算符优先级隐患**、**魔法数字硬编码**及**调试日志残留**等问题。整体架构偏向传统 CI3 风格，事务管理与模型加载方式不够规范，安全与性能风险突出。
- **风险等级**：🔴 高（存在 SQL 注入隐患、逻辑判断缺陷及生产环境日志泄露风险）
> 📌 **框架说明**：代码特征（如 `$this->load->model()`、`$this->db->query()`、`trans_start()` 等）高度符合 **CodeIgniter 3** 规范。若 `phpci` 为内部定制版或笔误，以下审查基于 CI3 核心机制与 PHP 通用最佳实践。若为独立框架，请对照其官方文档调整组件调用方式。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_sales_record_v2`<br>`shifting_turnover_v2`<br>`get_drink_income_detail` 等多处 | **SQL 注入漏洞**：大量使用字符串拼接构造 `WHERE`、`UPDATE` 及 `UNION` 语句，未使用参数绑定或查询构造器。攻击者可通过构造恶意参数篡改查询逻辑或窃取数据。 | 全面替换为 CI3 Query Builder 或 `$this->db->query($sql, $binds)` 参数绑定。避免直接拼接用户输入。 | `$this->db->where('_merchant_id', $param['merchant_id'])->get($table);`<br>或<br>`$this->db->query("SELECT * FROM t WHERE id = ?", [$id]);` |
| 🔴 严重 | `_validate_timing2package_params` | **逻辑运算符优先级错误**：`&&` 优先级高于 `||`，导致 `!isset($params['actual_pay']) \|\| $params['actual_pay'] < 0` 未正确分组。当 `is_manager_pay` 为假时，若 `actual_pay < 0` 仍会触发报错，逻辑偏离预期。 | 使用括号明确条件分组，确保仅在 `is_manager_pay` 开启时校验金额。 | `if (isset($params['is_manager_pay']) && $params['is_manager_pay'] && (!isset($params['actual_pay']) \|\| $params['actual_pay'] < 0)) { throwError('差价错误'); }` |
| 🔴 严重 | `repay_order` | **双重否定逻辑混乱**：`if (!$orderInfo['_pay_scene'] != 5)` 语义晦涩且易引发误判。当 `_pay_scene` 为 `5` 时，`!5` 转为 `false`，`false != 5` 为 `true`，导致本应跳过的逻辑被错误执行。 | 改为正向清晰判断，移除冗余取反操作。 | `if ($orderInfo['_pay_scene'] != 5) { ... }` |
| 🟠 警告 | `get_sales_record_v2` | **分页参数未做边界校验**：`LIMIT " . ($page - 1) * $page_size` 若传入 `$page <= 0` 将生成负数偏移量，导致 SQL 语法错误或全表扫描。 | 增加类型转换与最小值限制。 | `$page = max(1, (int)$page);`<br>`$offset = ($page - 1) * $page_size;` |
| 🟠 警告 | `shifting_turnover_v2` | **生产环境日志泄露与性能损耗**：`do_log($res . '--' . $this->db->last_query(), 'hljceshi');` 将布尔值与完整 SQL 拼接记录，可能暴露敏感业务数据，且高频写入严重拖慢接口响应。 | 移除生产环境调试日志，或改用框架标准日志组件并开启脱敏/环境隔离。 | `if (ENVIRONMENT === 'development') { log_message('debug', $this->db->last_query()); }` |
| 🟠 警告 | `cancel_present` | **事务管理方式不一致**：混用 `trans_begin()` 与 `trans_commit()/trans_rollback()`，而其他方法使用 `trans_start()/trans_complete()`。手动模式若遗漏提交/回滚易导致连接池阻塞或数据不一致。 | 统一使用 CI3 推荐的自动事务管理 `trans_start()` / `trans_complete()`。 | `$this->db->trans_start();`<br>`// 业务逻辑`<br>`$this->db->trans_complete();`<br>`if ($this->db->trans_status() === FALSE) { $this->db->trans_rollback(); throwError('...'); }` |
| 🟡 建议 | 文件顶部 | **反模式：全局获取 CI 实例**：`$CI = &get_instance();` 在类外部调用违反 MVC 规范，且模型内应通过 `$this->load->model()` 或构造函数加载依赖。 | 移除顶部代码，在 `__construct()` 中初始化依赖模型。 | `public function __construct() { parent::__construct(); $this->load->model('Ahead_yc_order_model'); }` |
| 🟡 建议 | 全文多处 | **魔法数字泛滥**：硬编码状态值（如 `10, 11, 14, 669` 等）散落在业务逻辑中，降低可读性与后期维护效率。 | 提取为类常量或独立配置类，配合注释说明业务含义。 | `const PAY_PLATFORM_CASH = 10;`<br>`const PAY_PLATFORM_WECHAT = 4;`<br>`const PERM_REPAY_ORDER = 669;` |
| 🟡 建议 | `add_exchange_order` 末尾 | **代码截断**：提供代码在 `'_amount' => $value['cost_price'` 处中断，无法审查后续插入逻辑、事务闭合及异常处理。 | 补充完整方法代码，以便评估数据一致性保障机制。 | *(待补充完整代码后复审)* |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **彻底消除 SQL 注入风险**：将 `get_sales_record_v2`、`shifting_turnover_v2` 等核心方法中的原生 SQL 拼接全部替换为 Query Builder 或参数绑定。这是当前最高优先级的安全整改项。
2. **修正逻辑运算符与双重否定 BUG**：立即修复 `_validate_timing2package_params` 的优先级问题及 `repay_order` 中的 `!$x != 5` 逻辑，避免线上出现金额校验绕过或 VIP 余额误扣。
3. **清理调试日志**：移除 `shifting_turnover_v2` 中的 `do_log` 硬编码调用，避免生产环境性能损耗与敏感数据泄露。
### 🛠 后续重构与优化方向
- **统一事务与模型加载规范**：全量采用 `trans_start()` / `trans_complete()` 自动事务管理；将频繁使用的模型移至构造函数或基类中预加载，减少运行时开销。
- **复杂查询性能优化**：`get_sales_record_v2` 中的 `UNION` + 外层 `GROUP BY` + 独立 `COUNT` 查询组合极耗资源。建议：
- 为 `_merchant_id`、`_shop_id`、`_order_id`、`_pay_platform` 等高频过滤字段建立复合索引。
- 考虑将统计逻辑下沉至数据库视图或使用定时任务预计算，避免实时高并发查询。
- **代码规范化**：
- 遵循 PSR-12 规范，统一类名、方法名命名风格。
- 使用常量替代魔法数字，补充 PHPDoc 类型声明（如 `@param int $merchantId`）。
- 将自定义 `throwError()` 逐步迁移至标准 `throw new \RuntimeException()` 配合全局异常处理器，提升错误堆栈可追溯性。
- **补充缺失代码**：请提供 `add_exchange_order` 完整实现，以便审查订单扩展表写入、优惠券状态更新及事务回滚的完整性。
> 💡 **提示**：若 `phpci` 框架对数据库操作或事务管理有特定封装（如强制使用 DAO 层或特定查询语法），请优先遵循其官方规范。上述建议基于 PHP 通用安全与性能标准，可直接适配至主流 MVC 架构。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779775490
|
1779775490
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
593
|
22
|
73
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 自助商家小程序兑换开房，续费的订单卡券要退回给用户
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `5999c22d1 ## 自动代码审查报告
**分支**: app-260616
**提交**: `5999c22d1ad94b48eae8ff43caaefa11d27932c6`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 15:21:04
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该 Model 承担了支付流水记录、回调处理、账单查询、营业报表及核心退款等大量业务逻辑。整体功能完整，但存在明显的架构越界（Model 层混杂业务逻辑与第三方 API 调用）、SQL 拼接安全隐患、循环内 N+1 查询性能瓶颈以及事务管理不规范等问题。代码风格偏向传统 PHP 开发，缺乏现代 PHP 类型约束与 PSR-12 规范。
- **风险等级**：🔴 高（存在 SQL 注入隐患、事务回滚不一致、硬编码敏感信息）
> 📌 **框架说明**：代码中大量使用 `$CI = &get_instance()`、`$this->load->model()`、`$this->db->trans_begin()` 等特征，实际为 **CodeIgniter 3** 架构，而非 `phpci`（PHP 持续集成服务器）。以下审查基于 CI3 及现代 PHP 最佳实践进行。若为自研封装框架，请确保底层查询构建器支持参数化绑定。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `update_refund_amount` / `refund` 多处 | **SQL 注入风险**：直接使用字符串拼接构造 `$where` 和 `$up` 条件（如 `'_relation_id="' . $relation_id . '"...'`），未使用预处理或查询构建器，极易被恶意参数注入。 | 全面改用 CI3 查询构建器或参数化查询，禁止手动拼接 SQL 片段。 | `$this->db->where('_relation_id', $relation_id)->where('_type', $type)->where_in('_status', [1,4]);`<br>`$this->db->set('_status', 4)->set('_refund_amount', '_refund_amount+' . $refund_amount, FALSE)->update($this->table_name);` |
| 🔴 严重 | `refund` 方法 | **事务回滚逻辑缺陷**：在多处 `if (!$res)` 中重复调用 `$this->db->trans_rollback()`，且依赖自定义 `throwError()`。若 `throwError` 未正确抛出异常或终止执行，会导致事务状态不一致或数据库锁死。 | 使用 `try...catch` 统一包裹事务，仅在 `catch` 中执行一次回滚，并抛出标准 `Exception`。 | `try { $this->db->trans_begin(); /* 业务逻辑 */ $this->db->trans_commit(); } catch (\Exception $e) { $this->db->trans_rollback(); throw $e; }` |
| 🔴 严重 | `mobile_refund` 方法 | **硬编码敏感密钥**：`md5()` 中直接写死 `'1441600902'` 和 `'2017040606573534'`，疑似支付网关盐值或签名密钥，存在代码泄露导致资金安全风险。 | 将密钥移至 `config/payment.php` 或环境变量中，通过 `config_item()` 读取。 | `$salt = config_item('refund_sign_salt'); $data['refund_key'] = md5($order_info['_id'] . $order_info['_trade_no'] . $salt);` |
| 🟠 警告 | `get_bill_pay_log` / `get_refundable_pay_log` | **N+1 查询性能瓶颈**：在 `foreach` 循环内频繁调用 `get_one()`、加载模型及查询配置。当 `$log_data` 数据量较大时，将产生数十次甚至上百次 DB 请求，严重拖慢接口响应。 | 提前收集所有关联 ID，使用 `WHERE IN` 批量查询，在内存中构建映射表后循环赋值。 | `$ids = array_column($log_data, 'relation_id'); $exts = $this->ahead_yc_order_extension_model->select(['where_in' => ['_order_id', $ids]]); $extMap = turn_array_key($exts, '_order_id');` |
| 🟠 警告 | `add_order_pay_log` | **循环内修改传入参数**：`$params` 在循环中被直接覆盖（如 `$params['_pay_platform'] = $platform`），导致后续迭代使用被污染的数据，且 `$actual_pay` 累加逻辑可能失真。 | 使用局部变量或克隆参数数组，避免副作用。明确多支付金额计算边界。 | `foreach ($payPlatformArr as $platform) { $currentParams = $params; if ($payPlatform == 14) { $currentParams['_pay_platform'] = $platform; ... } }` |
| 🟠 警告 | `update_after_pay_call_back` | **类型比较不一致**：`$newPayLogData['_type'] == 1` 与后续 `== '1'` 混用，PHP 弱类型比较可能导致分支误判。常量键名为字符串 `'1'`，但传入值可能为整型。 | 统一使用严格比较 `===`，或在方法入口处进行类型标准化。 | `if ((string)$newPayLogData['_type'] === '1')` |
| 🟡 建议 | 全局 | **违反单一职责原则 (SRP)**：Model 层包含退款计算、第三方 API 调用、报表聚合、Redis 队列推送等大量业务逻辑，导致类臃肿且难以测试。 | 抽离业务逻辑至 `Service` 或 `Library` 层，Model 仅保留数据存取与基础查询。 | 创建 `RefundService::processRefund()` 处理退款流程，Model 仅提供 `updateStatus()`、`getById()` 等方法。 |
| 🟡 建议 | 全局 | **魔法数字泛滥**：大量硬编码的平台/状态码（如 `1, 2, 11, 15, 17-28`），可读性差且易遗漏维护。 | 充分利用已定义的 `const` 常量，或建立统一的 `PaymentPlatform` 枚举/配置类。 | `if ($platform == self::VIP_PRESENT_PAY)` 替代 `== 15` |
| 🟡 建议 | 全局 | **缺乏现代 PHP 规范**：无 `declare(strict_types=1);`，无参数/返回值类型声明，注释含口语化历史遗留说明（如 `//之前不知道为啥被注释掉...`）。 | 遵循 PSR-12，补充类型提示，清理无效注释，使用 PHPDoc 规范方法签名。 | `public function add_order_pay_log(int $merchantId, int $adminUid, string $type, int $relationId, array $params, array $multPayIndexArr = []): array` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复 SQL 注入隐患**：立即替换所有字符串拼接的 `$where` 和 `$up` 逻辑，改用框架提供的查询构建器或参数化绑定。这是资金安全与数据完整性的底线。
2. **重构事务管理**：将 `refund()` 方法中的 `trans_begin/commit/rollback` 包裹在 `try...catch` 中，移除重复的 `trans_rollback()` 调用，确保异常发生时事务能安全回滚且不阻塞连接。
3. **移除硬编码密钥**：将 `mobile_refund` 中的签名盐值迁移至配置文件或环境变量，禁止在代码库中明文存储支付相关密钥。
### 🛠 后续重构与优化方向
1. **架构分层（MVC -> MVCS）**：
- 将 `refund()`、`update_after_pay_call_back()` 中的业务编排逻辑抽离至 `application/services/PaymentService.php`。
- Model 仅负责 `insert()`, `update()`, `select()`, `getOne()` 等数据操作。
- 第三方 API 调用（微信/支付宝退款）封装至 `application/libraries/PaymentGateway.php`。
2. **性能优化（消除 N+1）**：
- 对 `get_bill_pay_log` 和 `get_refundable_pay_log` 实施“批量预加载”策略。使用 `WHERE IN` 一次性拉取关联表数据，通过 `array_column` + `array_combine` 构建内存映射，将 DB 查询次数从 `O(N)` 降至 `O(1)`。
3. **规范化与可维护性**：
- 引入 PHP 7.4+ 类型声明与严格模式。
- 建立统一的 `PaymentPlatform` 与 `PayLogStatus` 常量/枚举类，彻底消除魔法数字。
- 清理历史注释，使用 PHPDoc 补充 `@param`、`@return`、`@throws` 说明。
> ⚠️ **局限性说明**：提供的代码在 `mobile_refund` 方法末尾被截断，未能完整审查支付宝退款回调处理及后续逻辑。建议补充完整代码以便进行全链路安全与异常流审查。若需针对特定 CI3 版本或自定义底层封装进行适配调整，请提供框架核心加载器或 DB 驱动实现细节。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780903264
|
1780903264
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
571
|
22
|
70
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 续费二维码加门店ID
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `61c327705 ## 自动代码审查报告
**分支**: app-260616
**提交**: `61c327705c8a45322199027037057e2e0e167776`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-05 16:25:19
---
## 1. 审查摘要
- **代码质量评分**：`N/A`（待提供具体变更代码）
- **总体评价**：当前仅提供了项目目录结构，未包含具体的变更代码片段或 Diff 内容。该目录结构高度符合 **CodeIgniter 3** 的核心架构（Helpers/Libraries/Database Drivers）。在缺乏实际代码的情况下，无法进行逻辑、安全及性能维度的深度评估。
- **风险等级**：`未知`（需结合具体变更内容判定）
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `N/A` | **未提供变更代码**：无法定位具体文件、行号及业务逻辑，审查流程无法启动。 | 请补充具体的代码变更内容（建议提供 Git Diff 或完整文件片段），并标注涉及的业务场景与调用链路。 | 无 |
## 3. 总结与行动建议
- **优先补充**：请提供本次提交的具体代码变更内容。为提升审查效率，建议包含：
1. 修改/新增的 PHP 文件路径及完整代码（或 `git diff` 输出）。
2. 代码所处的业务上下文（如：Controller 调用、Model 查询、Helper 扩展等）。
3. 是否涉及敏感操作（如：文件上传、支付回调、权限校验、外部 API 调用）。
- **后续重构与优化方向（基于提供的目录结构）**：
由于项目结构呈现典型的 CI3/类 CI 架构，在收到代码后，我将严格围绕您要求的 5 个维度展开审查，重点关注：
- **🔒 安全性**：`DB_driver.php` 及查询构造器是否强制使用预处理/参数绑定；`security_helper.php` 与 `form_helper.php` 是否严格处理 XSS/CSRF Token；`Session` 驱动是否启用 `cookie_httponly` 与加密存储；`Upload.php` 是否校验 MIME 类型与文件头而非仅依赖扩展名。
- **⚡ 性能优化**：`Cache` 驱动（Redis/Memcached）的键名设计与序列化策略；`DB_result.php` 是否避免在 `foreach` 中执行未缓存的同步查询；`Image_lib.php` 等重型库是否采用懒加载或队列异步处理。
- **📐 代码规范**：确保新增/修改代码严格遵循 **PSR-12**（类型声明、严格模式、缩进、命名空间）；Helper 函数避免全局污染，优先采用静态方法或依赖注入容器管理。
- **🧩 框架适配**：若 `phpci` 为 CI 的定制分支或内部框架，请确认其生命周期钩子（Hooks）、自动加载机制（Autoloader）与路由分发逻辑的差异。对于不确定的框架特定用法，我将明确标注并建议查阅 `phpci` 官方文档。
请补充代码内容，我将立即为您输出完整的深度审查报告。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780647919
|
1780647919
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
469
|
22
|
56
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 1
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `67f40bda4 ## 自动代码审查报告
**分支**: app-260616
**提交**: `67f40bda4fe54e9ed5e8f551606cdea0973b268b`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 15:52:23
---
## 1. 审查摘要
- **代码质量评分**：4.5 / 10 分
- **总体评价**：该控制器实现了商家端 App 的核心路由与业务分发功能，业务覆盖较广。但存在明显的架构反模式（巨型 `switch` 充当路由器、构造函数职责过重）、严重的安全隐患（硬编码密钥、CORS 通配符、疑似明文密码比对）以及大量重复逻辑。代码可维护性、安全性与扩展性均处于较低水平，亟需重构。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | ~380-385 | **硬编码第三方服务密钥**：科大讯飞 TTS 的 `APPID`、`APISecret`、`APIKey` 直接写死在代码中，极易随版本库泄露，导致服务被盗刷或数据泄露。 | 将敏感凭证移至 `application/config/` 独立配置文件或服务器环境变量中，通过 `$this->config->item()` 读取。 | `'xfyun_tts_config' => $this->config->item('xfyun_tts')` |
| 🔴 严重 | ~100-105 | **CORS 通配符配置**：`Access-Control-Allow-Origin: *` 允许任意域名跨域请求，结合 Token 鉴权机制，极易遭受 CSRF 攻击或敏感接口被恶意调用。 | 限制为可信域名白名单，或通过配置项动态输出，禁止使用 `*`。 | `header("Access-Control-Allow-Origin: " . $this->config->item('allowed_origins'));` |
| 🔴 严重 | ~450-455 | **密码校验与存储不规范**：`if ($data['_discount_pwd'] != $_old_password)` 疑似直接比对明文密码；且更新时未进行哈希处理，违反现代密码安全规范。 | 使用 `password_hash()` 存储，`password_verify()` 校验。若历史数据为明文，需规划平滑迁移方案。 | `if (!password_verify($_old_password, $data['_discount_pwd'])) { $this->error_response('旧密码不正确'); }`<br>`$this->ahead_yc_merchant_user_model->update(['_discount_pwd' => password_hash($_new_password1, PASSWORD_DEFAULT)], ['_id' => $uid]);` |
| 🟠 警告 | ~15-20 | **构造函数职责过重**：`__construct` 中混合了请求解析、CORS 设置、鉴权、权限校验、配置加载、日志记录等，严重违反单一职责原则（SRP），且影响单元测试。 | 将鉴权、日志、配置初始化抽离至中间件或基类控制器（如 `BaseApiController`）；构造函数仅保留核心依赖注入。 | 提取 `AuthMiddleware::handle()`、`ApiLogger::log()` |
| 🟠 警告 | ~200-350 | **巨型 Switch 充当路由器**：`index()` 方法使用超长 `switch` 分发 30+ 个接口，导致方法膨胀、难以维护，且每次请求都会加载大量未使用的 Model。 | 采用 CI3 原生路由配置，或改为动态方法调用（如 `$this->{$method}()`），将每个 `case` 拆分为独立方法。 | `public function func_0005() { /* 登录逻辑 */ }`<br>`$method = 'func_' . $request['function']; if (method_exists($this, $method)) { return $this->$method(); }` |
| 🟠 警告 | ~250-260 | **重复的权限校验与菜单过滤**：登录接口中多次调用 `check_priv`，且硬编码菜单 ID（Magic Numbers），业务规则与代码强耦合。 | 将菜单过滤规则配置化（如 `config/menus.php`）；提取独立的 `MenuService` 或 `PermissionService` 处理组装逻辑。 | `$this->menu_service->filterByPriv($menus, $user_type, $role_id);` |
| 🟠 警告 | ~500-530 | **支付方式过滤逻辑冗余**：`00066` 接口中针对 `api_type` 的过滤存在大量重复的 `if` 与 `array_diff`，违反 DRY 原则。 | 使用映射数组统一管理排除规则，通过循环批量处理。 | `$exclude_map = ['bill_pay' => [10], 'vip_recharge' => [3,7,8...]];`<br>`$exclude = $exclude_map[$api_type] ?? [];`<br>`$data['paytype'] = array_values(array_diff($data['paytype'], $exclude));` |
| 🟡 建议 | ~10 | **基类拼写错误**：`extends AplicationController` 疑似拼写错误，可能导致类继承失败或 IDE 无法识别。 | 修正为正确的基类名称（如 `CI_Controller` 或 `ApplicationController`）。 | `class MerchantAppServer extends CI_Controller` |
| 🟡 建议 | ~30-40 | **JSON 解析缺乏容错**：`json_decode($this->stream, true)` 未校验解析结果，若客户端传入非法 JSON 会导致后续逻辑崩溃或返回 500 错误。 | 增加 `json_last_error()` 校验，并统一使用 `php://input` 读取请求体。 | `$raw = file_get_contents('php://input');`<br>`$data = json_decode($raw, true);`<br>`if (json_last_error() !== JSON_ERROR_NONE) { $this->error_response('请求数据格式错误'); }` |
| 🟡 建议 | 全文 | **代码规范与可读性**：缩进不一致、长行未换行、变量命名混杂（如 `$this->stream` 与 `$this->get_stream`）、缺少类型声明与注释，不符合 PSR-12。 | 使用 `PHP-CS-Fixer` 或 IDE 自动格式化；统一使用驼峰/蛇形命名；为复杂逻辑添加 PHPDoc。 | 略（建议接入 CI/CD 静态检查流水线） |
> 📝 **注**：代码在 `case "1001":` 处被截断，无法评估该分支的完整逻辑与潜在风险。若该分支涉及订单状态变更或资金操作，请补充完整代码以便进行深度审查。
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即移除硬编码密钥**：将 `xfyun_tts_config` 等敏感信息迁移至配置文件或 `.env`，并检查 Git 历史是否已泄露。
2. **修复密码安全逻辑**：全面排查 `_discount_pwd` 及其他密码字段的存储与校验方式，强制引入 `password_hash`/`password_verify`。
3. **收敛 CORS 策略**：将 `Access-Control-Allow-Origin: *` 替换为业务域名白名单，避免接口被恶意跨域调用。
4. **增加输入校验容错**：对 `json_decode`、`file_get_contents('php://input')` 增加异常捕获与格式校验，防止恶意请求导致服务崩溃。
### 🛠 后续重构与优化方向
1. **架构解耦（核心）**：
- 废弃 `index()` 巨型 `switch` 路由，改用 **CI3 原生路由** 或 **命令模式/动态方法分发**。
- 将鉴权、日志、配置加载等横切关注点抽离至 **中间件** 或 **基类控制器**，保持业务方法纯净。
2. **服务层拆分**：
- 将菜单组装、权限校验、支付方式过滤等复杂逻辑下沉至独立的 `Service` 类，控制器仅负责参数接收、调用服务、返回响应。
- 消除硬编码的 Magic Numbers（如菜单 ID、支付平台 ID），统一收敛至配置中心或数据库字典表。
3. **性能与规范提升**：
- 模型加载统一移至构造函数或按需懒加载，避免在 `switch` 分支中重复调用 `$this->load->model()`。
- 引入 PSR-12 代码规范检查工具（如 `php-cs-fixer`），统一命名风格，补充关键方法的 PHPDoc 注释。
- 针对高频接口（如登录、个人中心）考虑引入 Redis 缓存菜单/配置数据，降低 DB 查询压力。
> 💡 **框架适配提示**：当前代码特征与 **CodeIgniter 3** 高度吻合。若 `phpci` 为内部定制框架，请确认其是否支持中间件机制与动态路由。若不支持，建议优先采用 `BaseController` 继承模式与 `call_user_func_array` 实现轻量级分发，逐步向现代 MVC 架构演进。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780386743
|
1780386743
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
567
|
22
|
67
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 续费小程序码
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `697aa9f19 ## 自动代码审查报告
**分支**: app-260616
**提交**: `697aa9f1918d12c5fb5d69b56908c15e2658e2b1`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-05 16:03:21
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该模型文件承载了大量核心业务逻辑（包厢状态流转、权限过滤、计费差价计算等），整体结构具备一定分层意识。但存在多处**高危 SQL 注入风险**、**Token 解析缺乏安全校验**、**返回值类型严重不一致**以及**全局函数/变量滥用**等问题。代码规范与 PSR-12 存在较大偏差，且末尾代码被截断，部分逻辑无法完整评估。
- **风险等级**：🔴 高（存在直接拼接 SQL 的注入点、未校验的 Token 解析、逻辑缺陷可能导致资损或越权）
> ⚠️ **局限性说明**：您提供的代码在 `get_room_detail` 方法末尾（`$priv_where['_role_i`）被截断。本次审查仅基于已提供的完整代码片段，未覆盖截断后的逻辑。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `list_rooms_info`<br>`list_nearby_family_servers_info`<br>`get_nearby_ids`<br>`get_family_server_ids_by_shop_ids` | **SQL 注入漏洞**：多处使用 `$addsql` 或 `$shop_ids` 直接拼接 SQL 字符串，未做任何过滤或参数绑定。攻击者可构造恶意参数执行任意 SQL。 | 废弃字符串拼接，全面改用 CI 查询构建器（Query Builder）或参数绑定 `$this->db->query($sql, $binds)`。 | ```php<br>// 修复前<br>$sql = "... WHERE _shop_id in " . $shop_ids;<br><br>// 修复后<br>$ids = explode(',', $shop_ids);<br>$this->db->where_in('_shop_id', $ids);<br>$result = $this->db->get('ahead_family_servers')->result_array();<br>``` |
| 🔴 严重 | `get_count_status_room`<br>`get_count_room_by_shop` | **Token 解析无校验且忽略签名**：`explode("_", $token)` 未检查数组长度，越界会触发 Warning；`$sign` 参数完全未参与验签，存在伪造身份越权风险。 | 增加格式校验、长度检查，并调用框架签名验证函数。 | ```php<br>$parts = explode('_', trim($request['token']));<br>if (count($parts) !== 4) {<br> return ['status' => -1, 'msg' => 'Token格式错误'];<br>}<br>[$merchant_id, $uid, $utype, $sign] = $parts;<br>// 必须调用签名验证逻辑<br>if (!$this->verify_token_sign($merchant_id, $uid, $utype, $sign)) {<br> return ['status' => -2, 'msg' => '签名验证失败'];<br>}<br>``` |
| 🔴 严重 | `get_is_valid_family_server_id` | **逻辑缺陷：参数未生效**：方法接收 `$id` 和 `$shop_id`，但 SQL 查询中完全未使用这两个条件，导致返回结果与预期不符。 | 将参数加入 WHERE 条件。 | ```php<br>$sql = "SELECT count(1) as num FROM ahead_family_servers WHERE _family_server_id=? AND _merchant_id=? AND _shop_id=?";<br>$result['data'] = $this->db->query($sql, [$family_server_id, $id, $shop_id])->row_array();<br>``` |
| 🟠 警告 | 全局多处 | **返回值类型不一致**：部分方法返回 `array('status'=>1)`，部分返回 `bool`，部分返回 `string`（如 `last_query()`）。调用方难以统一处理，易引发 `Undefined index` 或类型错误。 | 统一模型层返回规范，建议始终返回结构化数组：`['success' => bool, 'data' => mixed, 'msg' => string]`。 | ```php<br>// 统一规范示例<br>public function add_room(...): array {<br> if ($exists) {<br> $this->update(...);<br> return ['success' => true, 'msg' => '更新成功'];<br> }<br> $res = $this->insert(...);<br> return $res ? ['success' => true, 'msg' => '新增成功'] : ['success' => false, 'msg' => '数据库写入失败'];<br>}<br>``` |
| 🟠 警告 | `get_room_detail` (约 L950) | **字符串拼接含双逗号**：`$functions .= "32,2,5,6,12,18,,20,24,58";` 中 `18,,20` 存在连续逗号，下游解析时会产生空元素或报错。 | 使用数组管理功能码，最后统一 `implode(',', $functions)`。 | ```php<br>$functions = [32, 2, 5, 6, 12, 18, 20, 24, 58];<br>// 后续动态添加<br>$functions[] = 41;<br>$func_str = implode(',', array_unique($functions));<br>``` |
| 🟠 警告 | 文件顶部 & 方法内 | **`$CI =& get_instance()` 滥用**：在类外部调用一次，内部方法又重复调用。违反 CI 框架设计，增加内存开销且破坏封装性。 | 移除文件顶部调用。在 CI 模型中，`$this` 已继承自 `CI_Model`，可直接使用 `$this->load`、`$this->db` 等。 | ```php<br>// 删除文件顶部的 $CI =& get_instance();<br>// 方法内直接使用 $this->load->helper('common'); 即可<br>``` |
| 🟡 建议 | 类属性定义 (L15-L30) | **属性可见性过高**：`$tableName`、`$redis_key`、`$room_info` 等均为 `public`，外部可随意篡改，破坏对象状态。 | 改为 `protected` 或 `private`，通过 Getter/Setter 或受保护方法访问。 | `protected $tableName = 'ahead_family_servers';` |
| 🟡 建议 | 全局函数调用 | **强依赖全局函数**：大量使用 `get_aliyun_redis_conn()`、`smallChangeFormat()`、`preMinute()` 等全局函数。不利于单元测试、依赖注入及框架迁移。 | 将全局函数封装为 Helper 类或服务类，通过 `$this->load->helper()` 或 DI 容器注入。 | 建议逐步重构为 `RedisService::getInstance()->hGet(...)` |
| 🟡 建议 | 代码规范 | **短 `if` 语句未使用大括号**：如 `if ($room_area) $where['_room_area'] = $room_area;` 违反 PSR-12 规范，易引发后续维护时的逻辑错误。 | 严格遵循 PSR-12，所有控制结构必须使用大括号。 | ```php<br>if ($room_area) {<br> $where['_room_area'] = $room_area;<br>}<br>``` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题（P0/P1）
1. **彻底修复 SQL 注入**：立即替换 `list_rooms_info`、`list_nearby_family_servers_info`、`get_nearby_ids` 等 4 个方法中的字符串拼接 SQL。这是最高危的安全漏洞，必须优先处理。
2. **统一返回值契约**：制定团队级模型返回规范（如 `['code' => int, 'data' => mixed, 'message' => string]`），并在 `update_room_status`、`add_room` 等方法中强制对齐，避免调用层崩溃。
3. **修复 Token 解析逻辑**：补充 `explode` 后的 `count()` 校验，并接入签名验证机制。当前逻辑等同于“裸奔”，极易被伪造请求绕过权限。
### 🛠 后续重构与优化方向
1. **状态机与魔法数字治理**：代码中大量使用 `-1, 0, 1, 2, 3` 及 `32,2,5...` 等硬编码。建议提取为类常量或枚举（PHP 8.1+），例如：
```php
const STATUS_FREE = 0;
const STATUS_CONSUMING = 1;
const STATUS_REPAIRING = 2;
```
2. **Redis 连接生命周期管理**：当前 `get_aliyun_redis_conn()` 在多处被调用且部分未显式 `close()`。建议封装为单例或连接池，或在 CI 的 `__destruct()` 中统一释放，防止连接泄漏。
3. **解耦全局函数**：将 `smallChangeFormat`、`getNewSmallChange` 等计费相关函数抽离至独立的 `PriceCalculator` 服务类，便于后续进行单元测试和价格策略扩展。
4. **框架适配说明**：基于代码特征，`phpci` 高度兼容 CodeIgniter 3。若该框架有自定义的 `DB_driver` 或 `Session` 实现，请确保 `$this->db->query()` 的底层预处理机制未被覆盖。建议查阅 `phpci` 官方文档中关于 **Query Builder 安全过滤** 与 **模型自动加载** 的章节。
> 💡 **下一步建议**：修复上述 P0 问题后，建议引入静态分析工具（如 `PHPStan` 或 `Psalm`）配置 CI 流水线，自动拦截类型不一致与未定义变量问题。如需对截断的 `get_room_detail` 方法或特定计费逻辑进行深度审查，请提供完整代码片段。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780646601
|
1780646601
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
478
|
22
|
57
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 自助报表
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `6c1575fa3 ## 自动代码审查报告
**分支**: app-260616
**提交**: `6c1575fa3fcb52898b64e380e2fc77cf85718a86`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 18:50:14
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：业务逻辑覆盖较全，报表统计与多维度聚合功能实现完整。但存在明显的 **SQL 注入隐患**、**N+1 查询性能瓶颈** 以及 **面向对象设计不规范** 问题。部分查询构造器使用方式偏离现代 PHP 安全规范，需优先修复。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_songs_sales_pay_log_model.php`<br>约第 268 行 (`refund` 方法) | **SQL 注入风险**：`$refund_reason` 与 `$CI->admin_data` 直接字符串拼接进 `UPDATE` 语句，未做转义或参数绑定。若输入含双引号或特殊字符将导致语法错误或注入。 | 使用框架查询构造器的参数绑定机制，或调用内置的 `escape()` 方法。避免手动拼接 SQL。 | ```php<br>// 推荐写法<br>$this->db->set('_refund_reason', $refund_reason)<br> ->set('_refund_admin_id', $CI->admin_data['_id'] ?? 0)<br> ->set('_refund_admin_name', $CI->admin_data['_name'] ?? '')<br> ->where($where)<br> ->update($this->table_name);<br>``` |
| 🔴 严重 | `Ahead_songs_sales_pay_log_model.php`<br>约第 200 行<br>`Jh_community_shop_revenues_detail_model.php`<br>约第 150 行 | **SQL 注入/语法错误**：`$pay_platform_where` 循环中直接拼接 `$params['pay_platform_arr']`，且**未添加引号**。若值为字符串将引发 SQL 语法报错；若未做类型过滤则存在注入风险。 | 强制类型转换 `(int)`，或改用框架提供的 `or_where()` 链式调用，由底层驱动处理转义。 | ```php<br>// 推荐写法<br$this->db->group_start();<br>foreach ($params['pay_platform_arr'] as $p) {<br> $parts = explode('_', $p);<br> $this->db->or_where('a._pay_platform', (int)$parts[0]);<br> if (!empty($parts[1])) {<br> $this->db->or_where('a._second_pay_platform', (int)$parts[1]);<br> }<br>}<br>$this->db->group_end();<br>``` |
| 🟠 警告 | `Ahead_songs_sales_pay_log_model.php`<br>约第 115 行 (`get_shop_incomes_statement_trend`) | **N+1 查询性能瓶颈**：在 `foreach ($result as &$v)` 循环中逐段执行 `$this->select()`。若查询跨度为 30 天，将产生 30+ 次独立 SQL 请求，严重拖慢接口响应。 | 改为**单次查询**拉取全量时间段数据，利用 `GROUP BY` 时间表达式，在 PHP 层按 Key 映射填充；或引入 Redis 缓存趋势数据。 | ```php<br>// 优化思路：一次性查询<br>$where['_consume_time >='] = $min_start;<br>$where['_consume_time <'] = $max_end;<br>$all_data = $this->select($where, $fields, $group_by);<br>// 在 PHP 中按 create_hour/date 建立索引映射<br>$mapped = array_column($all_data, 'amount', $group_by);<br>``` |
| 🟠 警告 | 两文件顶部 | **反模式：全局 `$CI` 实例化**：在类外部声明 `$CI = &get_instance();` 违反 OOP 原则。在文件被 `include` 时即执行，易在 CLI/多进程环境下引发状态污染或内存泄漏。 | 移除文件顶部全局声明。在类内部通过 `$this->load->model()` 按需加载，或在 `__construct()` 中统一初始化。 | 删除顶部 `$CI = &get_instance();`，方法内直接使用 `$this->load->model('xxx');` |
| 🟠 警告 | `Jh_community_shop_revenues_detail_model.php`<br>多个统计方法 | **重复聚合逻辑**：`get_community_revenues_data`、`get_community_revenues_sum_data` 中计算 `wx_amount`、`tuangou_amount` 等逻辑高度重复，违反 DRY 原则。 | 抽取私有方法 `private function aggregate_revenue_stats(array $data): array` 统一处理收入/退款分类汇总。 | ```php<br>private function aggregate_revenue_stats($data) {<br> $stats = ['wx'=>0, 'tuangou'=>0, 'other'=>0];<br> foreach($data as $v) { /* 统一分类累加 */ }<br> return $stats;<br>}<br>``` |
| 🟡 建议 | 全局多处 | **魔法数字/字符串泛滥**：大量使用 `'1'`, `'4'`, `'8'`, `'9'` 表示状态与支付渠道，缺乏语义化，后期维护成本高。 | 定义类常量或 PHP 8.1+ 枚举（Enum）。如 `const STATUS_PAID = 1; const PAY_WECHAT = '1';`。 | ```php<br>class Ahead_songs_sales_pay_log_model {<br> const PAY_WECHAT = '1';<br> const PAY_VIP = '3';<br> // 替换代码中的硬编码<br>}<br>``` |
| 🟡 建议 | `Jh_community_shop_revenues_detail_model.php`<br>约第 240 行 (`get_date_type_info`) | **静态缓存潜在风险**：`self::$date_type_info` 在 PHP-FPM 下安全，但若项目未来迁移至 Swoole/Workerman 等常驻进程，将导致跨请求数据污染。 | 改为实例属性 `$this->date_type_info`，或增加请求级重置逻辑。若确定仅运行于 FPM 可保留。 | `private $date_type_info = [];` 替代 `public static $date_type_info = [];` |
| 🟡 建议 | `Ahead_songs_sales_pay_log_model.php`<br>约第 140 行 | **频繁加载模型**：同一方法内多次调用 `$this->load->model()`。虽 CI 有内部缓存，但影响代码整洁度与可读性。 | 将高频依赖模型移至构造函数或父类中预加载，或使用依赖注入容器管理。 | 在 `__construct()` 中集中加载 `ahead_shop_group_model` 等。 |
## 3. 总结与行动建议
### 🔑 优先修复项（P0/P1）
1. **彻底修复 SQL 拼接漏洞**：立即替换 `refund()` 方法中的字符串拼接，以及所有 `$pay_platform_where` 的 `implode(' or ', ...)` 逻辑。务必使用框架提供的参数绑定或查询构造器链式方法。
2. **消除 N+1 查询**：重构 `get_shop_incomes_statement_trend()`，将循环内的数据库查询改为**单次范围查询 + PHP 内存映射**。预计可降低 70% 以上的数据库 I/O 开销。
3. **移除全局 `$CI` 声明**：将文件顶部的 `get_instance()` 调用清理，改为标准的模型内部加载机制，避免潜在的状态泄漏。
### 🛠 后续重构与优化方向
- **统一查询构造器规范**：确认 `phpci` 框架底层 `DB_driver` 是否支持 `?` 占位符或命名参数绑定。若不支持，建议封装一层安全查询辅助类，强制拦截未转义的输入。
- **业务常量集中管理**：将支付渠道、订单状态、时间类型等硬编码提取至独立的 `Config` 类或 `Enum` 文件中，提升代码自解释能力。
- **报表计算逻辑抽象**：当前多个模型中存在相似的 `type=1(收入)` 与 `type=2(退款)` 分类汇总逻辑。建议抽象为 `RevenueCalculator` 服务类，通过策略模式或简单工厂处理不同维度的统计，降低模型耦合度。
- **异常处理规范化**：代码中使用了全局函数 `throwError()`。建议逐步替换为 PHP 原生 `throw new \InvalidArgumentException()` 或自定义业务异常类，配合全局异常处理器统一返回格式。
> 💡 **框架适配提示**：代码呈现典型的 CodeIgniter 3 架构特征（如 `get_instance()`、`load->model()`、`select()` 等）。若 `phpci` 为内部定制框架，请重点核对 `system/database/DB_driver.php` 中 `select()`、`up()` 等方法的底层实现是否默认开启参数绑定。若未开启，上述安全修复必须手动调用 `$this->db->escape()` 或 `(int)` 强转。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780397414
|
1780397414
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
642
|
22
|
80
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 预订列表
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `6c2219403 ## 自动代码审查报告
**分支**: app-260616
**提交**: `6c2219403bf4db53b66686f356e77bd5c4e06939`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-09 16:49:37
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：业务功能覆盖较完整，状态流转与权限校验逻辑较为清晰。但存在**高危 SQL 注入漏洞**、**事务处理机制不规范**、**严重的 N+1 查询性能瓶颈**，且代码风格偏向传统 PHP 写法，缺乏现代类型声明与 PSR-12 规范。部分方法逻辑冗长，职责划分不够清晰。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_book_model.php`<br>`add_book()` 方法 | **事务处理逻辑错误**。在 `try` 块中手动调用 `$this->db->trans_rollback()` 后直接 `return`，但方法末尾仍执行 `$this->db->trans_complete()`。在 CI 类框架中，`trans_complete()` 会自动根据状态提交或回滚，手动回滚会导致事务状态机混乱，可能引发“事务已提交/回滚”异常或数据不一致。 | 移除 `try-catch` 中的手动回滚，采用框架标准事务流：`trans_start()` → 业务逻辑 → `trans_complete()` → 通过 `trans_status()` 判断结果。异常捕获应仅用于记录日志或转换错误格式。 | ```php<br>$this->db->trans_start();<br>// ... 业务逻辑 ...<br>$this->db->trans_complete();<br>if ($this->db->trans_status() === FALSE) {<br> return ['success'=>false, 'msg'=>'预订失败'];<br>}<br>``` |
| 🔴 严重 | `Ahead_book_model.php`<br>`get_book_list()` ~L285 | **SQL 注入漏洞**。`$where_str[] = "(book._book_no LIKE '%" . $params['book_no'] . "%' ..."` 直接拼接用户输入，未做任何转义或参数绑定。攻击者可构造恶意输入破坏查询结构或拖库。 | 使用框架查询构建器的 `like()` 方法，或强制类型转换/使用 `escape()`。复杂条件建议拆分为多个 `or_group_start()`。 | ```php<br>$this->db->group_start();<br>$this->db->like('book._book_no', $params['book_no']);<br>$this->db->or_like('book._customer_contact', $params['book_no'], 'after');<br>// ... 其他条件 ...<br>$this->db->group_end();<br>``` |
| 🔴 严重 | `Ahead_book_model.php`<br>`update_book()` ~L195 | **SQL 注入漏洞**。`$where = "_merchant_id=" . $merchantId . " and _id in (" . implode(",", $ids) . ")";` 直接拼接字符串作为 WHERE 条件。 | 使用数组条件或 `where_in()`，避免手写 SQL 片段。 | ```php<br>$where = ['_merchant_id' => $merchantId];<br>$this->db->where_in('_id', $ids);<br>``` |
| 🟠 警告 | `Ahead_book_model.php`<br>`get_book_list()` ~L330-380 | **N+1 查询性能瓶颈**。在 `foreach ($list['rows'] as &$row)` 循环中频繁调用 `get_one()`、`get_vip_info_by_recharge()` 等模型方法。数据量稍大时将导致数据库连接耗尽、响应超时。 | 提取循环中所需的所有 ID，使用 `where_in` 批量查询，或在 SQL 层通过 `LEFT JOIN` 一次性获取。循环内仅做数组映射与格式化。 | ```php<br>$userIds = array_unique(array_filter(array_column($list['rows'], 'ahead_user_id')));<br>$users = $this->ahead_user_model->get_list(['_id' => $userIds]);<br>$userMap = array_column($users, '_mobile', '_id');<br>// 循环内直接 $row['customer_contact'] = $userMap[$row['ahead_user_id']] ?? '';<br>``` |
| 🟠 警告 | `Ahead_book_model.php`<br>`add_book()` ~L45 | **日期格式化逻辑错误且冗余**。`strtolower(date("Ymd H:30"))` 中 `H:30` 非标准格式（应为 `H:i`），且 `strtolower` 对日期字符串无意义。业务意图疑似“取整到半小时”。 | 使用数学取整或标准时间函数。若需取当前时间最近的半小时节点：`date('Y-m-d H:i', floor(time()/1800)*1800)`。 | `$thirtyTime = date('Y-m-d H:i', floor($nowTime / 1800) * 1800);` |
| 🟠 警告 | `Ahead_book_model.php`<br>全文多处 | **模型重复加载**。在多个方法内部反复调用 `$this->load->model()`，增加框架解析开销，且不利于依赖管理。 | 将高频使用的模型移至 `__construct()` 中统一加载，或采用服务容器/依赖注入。 | ```php<br>public function __construct() {<br> parent::__construct();<br> $this->load->model('ahead_shop_config_model');<br> $this->load->model('Ahead_yc_shop_model');<br>}<br>``` |
| 🟡 建议 | `Ahead_book_model.php`<br>`Ahead_book_order_operation_log_model.php` | **不符合 PSR-12 规范**。方法名使用下划线（如 `add_book`），缺少参数与返回类型声明，文件顶部 `$CI = &get_instance();` 暴露在全局作用域。 | 方法名改为驼峰式（`addBook`），补充类型提示（`int $merchantId, array $params`），移除全局 `$CI` 赋值，按需使用 `$this->ci` 或 `$CI =& get_instance()` 局部获取。 | `public function addBook(int $merchantId, int $uid, array $params): array` |
| 🟡 建议 | `Ahead_book_order_operation_log_model.php`<br>`get_log_list()` ~L45 | **循环内分支查询冗余**。根据 `source` 在循环中调用不同模型的 `get_one()`，可优化为分组批量查询。 | 按 `source` 分组收集 `user_id`，分别批量查询后合并映射，减少 DB 交互次数。 | *(逻辑同 N+1 优化，按 source 分组后批量 `where_in` 查询)* |
| 🟡 建议 | `Ahead_book_model.php`<br>`update_book()` 末尾 | **代码截断**。方法在 `if (isset($params['welcome_minutes']) && $params['welcome_minutes']) {` 处中断，无法评估完整逻辑与事务闭合情况。 | 请补充完整代码。审查当前仅基于已提供片段。 | N/A |
> 💡 **框架适配说明**：代码结构高度类似 CodeIgniter 3/4。若 `phpci` 为定制框架，其事务状态机（`trans_start/complete/status`）与查询构建器（`where_in/like`）的实现可能与原生 CI 存在差异。建议对照 `phpci` 官方文档确认事务自动回滚机制与参数绑定语法。
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即修复 SQL 注入**：替换所有字符串拼接的 WHERE/LIKE 条件，全面改用框架查询构建器或参数绑定。这是最高优先级的安全红线。
2. **重构事务控制流**：移除 `try-catch` 中的手动 `trans_rollback()`，统一使用 `trans_start() → trans_complete() → trans_status()` 标准模式，确保数据一致性。
3. **消除 N+1 查询**：将 `get_book_list()` 循环内的单条查询改为批量查询（`where_in`）或 SQL `JOIN`，预计可将列表接口响应时间降低 60%~80%。
### 🛠 后续重构与优化方向
- **分层架构优化**：当前 Model 承担了过多业务逻辑（如权限校验、短信发送、欢迎词编码、日志记录）。建议引入 `Service` 层处理业务流程，Model 仅负责数据存取，符合单一职责原则。
- **现代化 PHP 特性**：全面启用 PHP 7.4+/8.x 类型声明（`declare(strict_types=1);`、参数/返回类型、属性类型），提升代码健壮性与 IDE 提示体验。
- **配置与常量管理**：硬编码的魔法数字（如 `1, 2, -1, 7, 11, 34`）应提取为类常量或配置文件，提升可维护性。
- **异常处理规范化**：`throwError()` 疑似全局函数，建议替换为抛出标准 `InvalidArgumentException` 或自定义业务异常类，配合全局异常处理器统一返回 JSON 格式。
- **补充完整代码**：请提供 `update_book()` 方法的完整实现，以便审查其事务边界、数据校验与状态流转逻辑。
如需针对特定模块（如短信发送逻辑、权限校验链路）进行深度剖析或提供完整重构代码模板，可随时提供补充片段。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780994977
|
1780994977
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
479
|
22
|
58
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 1
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `6de5af6e3 ## 自动代码审查报告
**分支**: app-260616
**提交**: `6de5af6e35f472ac5142d043b227de4326e9fda9`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 18:54:48
---
## 1. 审查摘要
- **代码质量评分**：6.0 / 10 分
- **总体评价**：代码业务逻辑完整，覆盖了营业额统计、趋势分析、详情查询及流水记录等核心场景。但存在**严重的 SQL 注入隐患**、**循环内查询（N+1）性能瓶颈**以及**框架上下文滥用**问题。代码风格偏向传统 CI3 写法，缺乏现代 PHP 类型声明与常量管理，可维护性与安全性需重点提升。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `refund()` 方法 | **SQL 注入漏洞**：`$refund_reason` 与 `$order_data['_id']` 直接拼接至 SQL 字符串，未做任何转义或预处理。攻击者可构造恶意输入破坏数据或提权。 | 废弃字符串拼接，改用框架查询构造器（Query Builder）或预处理语句。若 `Simple_model::up()` 不支持绑定参数，需重写该方法或改用原生 `$this->db->update()`。 | ```php<br>// 安全写法<br>$this->db->set('_status', 4)<br> ->set('_refund_time', time())<br> ->set('_refund_amount', '_actual_pay', FALSE)<br> ->set('_other_pay_refund_amount', '_other_pay_amount', FALSE)<br> ->set('_refund_reason', $refund_reason)<br> ->set('_refund_admin_id', $CI->admin_data['_id'] ?? 0)<br> ->set('_refund_admin_name', $CI->admin_data['_name'] ?? '')<br> ->where('_merchant_id', $order_data['_merchant_id'])<br> ->where('_shop_id', $order_data['_shop_id'])<br> ->where('_order_id', $order_data['_id'])<br> ->where('_type', $type)<br> ->where('_status', 1)<br> ->update($this->table_name);<br>``` |
| 🔴 严重 | `get_shop_incomes_statement_detail()` | **SQL 注入漏洞**：`$pay_platform_where` 数组通过字符串拼接构造 `OR` 条件，用户传入的 `$params['pay_platform_arr']` 未过滤直接入 SQL。 | 使用查询构造器的分组条件语法替代手动拼接，确保参数自动转义。 | ```php<br>$this->db->group_start();<br>foreach ($params['pay_platform_arr'] as $pp) {<br> $arr = explode('_', $pp);<br> $this->db->or_where('a._pay_platform', $arr[0]);<br> if (!empty($arr[1])) {<br> $this->db->where('a._second_pay_platform', $arr[1]);<br> }<br>}<br>$this->db->group_end();<br>``` |
| 🟠 警告 | `get_shop_incomes_statement_trend()` | **N+1 查询性能瓶颈**：在 `foreach ($result as &$v)` 循环中反复调用 `$this->select()`。若 `$result` 有 30 个时间段，将触发 30 次独立 DB 查询，高并发下极易拖垮数据库。 | 改为**单次查询**拉取全量数据，在 PHP 层按时间维度聚合；或使用 `IN` 条件一次性查询后分组。 | 建议将时间范围合并为单次查询，返回后使用 `array_reduce` 或循环按 `create_hour/date/month` 映射填充 `$result`。 |
| 🟠 警告 | 文件顶部第 2 行 | **框架生命周期违规**：`$CI = &get_instance();` 在类定义外全局执行。文件被 `include` 时即触发，可能引发上下文污染、内存泄漏或单元测试失败。 | 移除顶部代码，将依赖加载移至 `__construct()` 或具体业务方法中。 | ```php<br>public function __construct()<br>{<br> parent::__construct();<br> // 按需加载模型或保持延迟加载<br>}<br>``` |
| 🟠 警告 | `get_shop_incomes_statement_detail()` | **模型状态污染**：使用 `$this->set_table_name($table_name . ' a')` 修改了模型内部表名状态，虽在末尾恢复，但在并发请求或链式调用中易引发别名冲突。 | 避免修改全局模型状态，建议实例化临时查询对象或使用框架提供的 `from()`/`join()` 链式语法。 | 使用 `$this->db->from($this->table_name . ' a')` 替代全局状态修改。 |
| 🟠 警告 | `add_data()` 方法 | **未初始化变量**：`$second_pay_platform` 仅在 `if` 分支中赋值，末尾依赖 `?? 0` 兜底。在 PHP 严格模式或旧版本中会触发 `Notice`，且逻辑分支遗漏时易产生脏数据。 | 方法开头显式初始化：`$second_pay_platform = 0;`，并确保所有分支均有明确赋值。 | `$second_pay_platform = 0; // 初始化` |
| 🟡 建议 | 全局多处 | **魔法数字/字符串泛滥**：状态值 `1, 4`、平台值 `8, 9, 17~28` 等硬编码散落各处，业务变更时需全局搜索替换，极易遗漏。 | 提取为类常量（`const`），集中管理业务字典。 | ```php<br>const STATUS_PAID = 1;<br>const STATUS_REFUNDED = 4;<br>const PAY_PLATFORM_GROUP = '8';<br>``` |
| 🟡 建议 | 类名/方法名 | **不符合 PSR-12 规范**：类名与方法名使用下划线分隔（如 `Ahead_songs_sales_pay_log_model`、`get_shop_incomes_statement_sum`）。 | 逐步重构为 `StudlyCaps` 类名与 `camelCase` 方法名。若受历史包袱限制，至少保持项目内统一。 | `class AheadSongsSalesPayLogModel extends Simple_model` |
| 🟡 建议 | `get_shop_incomes_statement_trend()` | **非标准异常处理**：使用自定义 `throwError()` 函数中断流程，不利于全局异常捕获与日志追踪。 | 改用标准 PHP 异常或框架异常类。 | `throw new \InvalidArgumentException('营业额走势查询时间错误');` |
## 3. 总结与行动建议
### 🔑 优先修复项（P0）
1. **彻底修复 SQL 注入**：`refund()` 与 `get_shop_incomes_statement_detail()` 中的字符串拼接必须立即替换为查询构造器或参数绑定。这是当前最高危的安全漏洞。
2. **消除 N+1 查询**：重构 `get_shop_incomes_statement_trend()`，将循环查询改为单次批量查询 + PHP 内存聚合。可预期性能提升 5~10 倍。
3. **清理全局上下文**：移除文件顶部的 `$CI = &get_instance();`，遵循框架依赖注入或构造函数初始化规范。
### 🛠 后续重构与优化方向
1. **引入类型声明与常量管理**：
- 为所有方法参数与返回值添加 PHP 7.4+/8.0+ 类型提示（如 `array`, `int`, `string`）。
- 将 `$type_arr`、`$incomes_pay_platform_arr` 等硬编码数组迁移至配置类或数据库字典表，提升可配置性。
2. **统一数据格式化策略**：
- `change_number_format()` 被高频调用，建议在数据库层使用 `ROUND()` 或 `FORMAT()`，或在返回前统一批量处理，减少函数调用开销。
3. **框架适配说明**：
- 代码特征高度匹配 **CodeIgniter 3** 架构。若 `phpci` 为内部定制框架，请确认 `Simple_model::up()`、`$this->select()` 是否底层已实现 PDO 预处理。若未实现，上述 SQL 注入修复方案必须落地。
- 建议查阅 `phpci` 官方文档中关于 `Query Builder` 与 `Model 生命周期` 的章节，确保状态隔离与事务安全。
> 💡 **专家提示**：当前代码业务耦合度较高，建议后续将“数据聚合逻辑”与“数据查询逻辑”拆分。可引入 `Repository` 模式或 `Service` 层处理复杂统计，保持 Model 仅负责基础 CRUD，以提升代码的可测试性与扩展性。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780397688
|
1780397688
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
569
|
22
|
69
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 1
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `6f7666fbf ## 自动代码审查报告
**分支**: app-260616
**提交**: `6f7666fbfcd3c63692feac764fa0a0fc7251b2f9`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-05 16:19:57
---
## 1. 审查摘要
- **代码质量评分**：暂无法评分（待提供具体变更代码）
- **总体评价**：当前仅提供了项目目录结构，未包含具体的 `变更文件内容`。该结构呈现典型的 PHP MVC 框架特征（高度类似 CodeIgniter 3.x 架构）。在缺乏实际代码的情况下，无法进行逻辑、安全、性能及规范维度的深度审查。
- **风险等级**：待评估（需结合具体变更内容判定）
## 2. 问题详情
*注：由于未提供实际变更代码，下表仅基于您提供的目录结构，列出此类框架中**高频出现的典型隐患**作为审查预检参考。实际审查将在您提交代码后精准定位到具体文件与行号。*
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `system/helpers/security_helper.php` / 动态 | 若自定义安全过滤函数未严格处理输出，或依赖过时的 `xss_clean()` 正则，极易引发 XSS 漏洞或 ReDoS 拒绝服务。 | 优先使用 PHP 原生 `htmlspecialchars($str, ENT_QUOTES \| ENT_SUBSTITUTE, 'UTF-8')` 进行输出转义；输入校验使用 `filter_var()` 或框架验证器。 | `echo htmlspecialchars($user_input, ENT_QUOTES \| ENT_SUBSTITUTE, 'UTF-8');` |
| 🔴 严重 | `system/database/DB_driver.php` / 动态 | 原生 SQL 拼接未使用预处理（Prepared Statements）或查询构建器，存在 SQL 注入风险。 | 全面改用参数化查询或框架查询构建器，禁止直接拼接用户输入。 | `$this->db->query('SELECT * FROM users WHERE id = ?', [$id]);` |
| 🟠 警告 | `system/libraries/Cache/Cache.php` / 动态 | 缓存驱动未配置合理的 TTL，或缺少缓存穿透/雪崩防护机制，高并发下易导致数据库负载骤增。 | 为缓存键设置随机过期时间，使用 `Cache::remember()` 模式，并对空结果进行短 TTL 缓存防穿透。 | `if ($data = $this->cache->get('key')) return $data; ... $this->cache->save('key', $data, rand(300, 3600));` |
| 🟠 警告 | `system/libraries/Session/Session.php` / 动态 | Session 驱动未强制绑定 IP/User-Agent 校验，或 Cookie 未设置 `HttpOnly`/`Secure` 标志，易遭会话劫持。 | 在配置中启用 `sess_match_ip`、`sess_match_useragent`，并设置 `cookie_httponly = TRUE`、`cookie_secure = TRUE`（HTTPS 环境）。 | `config.php: $config['cookie_httponly'] = TRUE; $config['cookie_secure'] = TRUE;` |
| 🟡 建议 | `system/helpers/array_helper.php` / 动态 | 数组操作函数未使用 PHP 7+ 类型声明与严格模式，缺乏对非数组参数的防御性编程。 | 增加 `declare(strict_types=1);`，使用 `is_array()` 或类型提示，避免隐式类型转换导致的 Notice/Warning。 | `function array_get(array $array, string $key, $default = null) { ... }` |
| 🟡 建议 | `system/libraries/Upload.php` / 动态 | 文件上传未校验 MIME 类型与扩展名白名单，或未限制上传目录执行权限，存在 WebShell 风险。 | 严格校验 `$_FILES['file']['type']` 与 `finfo_open()`，重命名文件，并将上传目录置于 Web 根目录外或禁用 PHP 执行。 | `if (!in_array(pathinfo($file, PATHINFO_EXTENSION), ['jpg','png'])) { throw new Exception('Invalid type'); }` |
## 3. 总结与行动建议
- **优先修复的关键问题**：请补充具体的 `变更文件内容`（建议提供完整函数/类或 Git Diff）。收到后我将立即针对逻辑闭环、SQL/XSS 防护、内存管理及 PSR-12 规范进行逐行审查。
- **后续重构/优化方向**：
1. **安全基线加固**：确保所有数据库交互强制使用参数化查询；所有用户输入输出经过严格过滤/转义；敏感操作（如登录、支付、数据导出）需校验 CSRF Token 并实施权限拦截。
2. **性能与架构优化**：针对 `system/libraries/Cache/` 与 `system/database/` 模块，建议引入连接池配置、懒加载机制及 N+1 查询检测。对高频调用的 Helper 函数可考虑静态化或编译缓存。
3. **框架适配说明**：您提及的 `phpci` 框架在公开生态中较少见，当前目录结构与 **CodeIgniter 3.x** 高度一致。若确为内部定制框架，请确认其生命周期钩子（如 `pre_controller`、`post_system`）、自动加载机制及路由规则是否与原生 CI 存在差异。如有差异，建议查阅 `phpci` 官方文档或提供核心加载器代码，以便精准对齐框架最佳实践。
4. **规范升级路径**：建议逐步向 PSR-12 靠拢，统一命名空间、引入 PHP 7.4+ 类型声明（Typed Properties/Return Types），并使用 `try-catch` 替代全局错误抑制符 `@`，提升代码可维护性与 IDE 静态分析友好度。
> 📥 **下一步**：请粘贴具体的变更代码片段（或提供文件路径+关键逻辑），我将基于上述维度为您输出完整、可落地的深度审查报告。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780647598
|
1780647598
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
587
|
22
|
71
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 自助商家可以退兑换的订单
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `7579aebe0 ## 自动代码审查报告
**分支**: app-260616
**提交**: `7579aebe01b6a39b8b0d1220156c118c82a79eff`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 14:02:04
---
## 1. 审查摘要
- **代码质量评分**：4 / 10 分
- **总体评价**：该模型类承载了大量订单查询、统计报表、分页及退款逻辑，功能覆盖较全。但代码存在**严重的 SQL 注入隐患**、**敏感信息硬编码**、**多处 SQL 语法错误**及**重复的分页实现**。整体架构偏向早期 PHP 开发习惯，未遵循现代 PHP 规范与 MVC 分层原则，可维护性与安全性较低。
- **风险等级**：🔴 高
> 📌 **框架说明**：代码结构、`$this->db` 调用方式及目录特征高度符合 **CodeIgniter 3** 框架。若 `phpci` 为贵司内部定制框架，请结合其官方文档对 Query Builder 语法进行适配。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 全局多处 | **SQL 注入风险**：大量使用 `$addsql` 字符串直接拼接至 `WHERE` 或 `JOIN` 条件中，未做参数绑定或白名单过滤。若 `$addsql` 来自用户输入，将导致严重注入。 | 废弃字符串拼接，全面改用框架 Query Builder 或预处理语句。若必须动态拼接，需严格校验键名白名单。 | `$this->db->where($safe_conditions)->get('ahead_yc_order');` |
| 🔴 严重 | 第 14 行 / `refund()` | **敏感信息硬编码**：`public $encrypt` 及退款方法中的 MD5 盐值（`'1441600902'` 等）直接写死在代码中，且属性为 `public`，极易泄露。 | 移至 `application/config/` 或 `.env` 环境变量，属性改为 `protected`，构造函数中读取。 | `protected $encrypt;`<br>`$this->encrypt = config_item('order_encrypt_key');` |
| 🔴 严重 | `get_new_add_people_trend_data` | **SQL 语法错误**：子查询 `NOT IN (select DISTINCT(_ahead_user_id))` **缺失 `FROM` 表名**，执行时将直接抛出数据库语法错误。 | 补全子查询表名及关联条件，确保逻辑闭环。 | `NOT IN (SELECT _ahead_user_id FROM ahead_yc_order WHERE _merchant_id = ?)` |
| 🔴 严重 | `cjy_consumption_trend_data` | **Query Builder 键名错误**：`$where['_merchant_id='] = $merchant_id;` 不符合 CI 规范，键名中的 `=` 会导致生成的 SQL 异常或条件失效。 | 移除键名中的操作符，使用标准数组键值对。 | `$where['_merchant_id'] = $merchant_id;` |
| 🟠 警告 | 多个统计方法 | **模型层越权处理 JSON**：多处使用 `json_encode()` 包装查询结果返回。模型应仅负责数据获取，序列化应交由 Controller 或 API 响应层。 | 移除模型中的 `json_encode()`，直接返回数组。在控制器层统一处理响应格式。 | `return $result['data']; // 移除 json_encode` |
| 🟠 警告 | `get_order_manage_by_page` | **强制索引滥用**：通过 `strpos($addsql, '_shop_id')` 判断后硬编码 `force index(_merchant_id)`。索引策略应由 DBA 通过执行计划决定，硬编码易导致全表扫描或索引失效。 | 移除 PHP 层的 `force index`，依赖数据库优化器。若确需优化，应在数据库层建立复合索引 `(merchant_id, shop_id, timestamp)`。 | 删除 `force index` 拼接逻辑 |
| 🟠 警告 | `set_page_info` / `get_page_info` / `cjy_get_page_info` | **分页逻辑严重重复**：三处独立实现分页计算、状态判断，代码冗余且易产生边界条件不一致。 | 抽取为独立 `PaginationService` 或 CI Library，统一调用。 | `PaginationHelper::calc($total, $page, $pageSize)` |
| 🟡 建议 | 文件顶部 | **模型加载方式错误**：`$CI =& get_instance(); $CI->load->model('Simple_model');` 在类外部执行，违反框架生命周期，且每次文件解析都会执行。 | 移除顶部代码。若需加载父类依赖，应在 `__construct()` 中处理或配置自动加载。 | 删除顶部两行代码 |
| 🟡 建议 | 全局 | **代码规范与命名**：变量带 `$_` 前缀属旧式风格；方法过长（如 `get_business` 超 60 行）违反单一职责；缺乏 PHP 7+ 类型声明。 | 遵循 PSR-12，移除 `$_` 前缀，添加类型提示，拆分大方法。 | `public function getOrderInfo(int $merchantId, string $orderId = ''): array` |
---
## 3. 总结与行动建议
### 🚨 优先修复的关键问题（P0）
1. **修复 SQL 注入漏洞**：立即审查所有传入 `$addsql` 的调用链。若无法短期内全面重构，至少对 `$addsql` 进行严格的正则白名单过滤（仅允许 `字段名 IN (...)` 或 `字段名 = ?` 格式），并强制使用 `$this->db->query($sql, $bindings)` 绑定参数。
2. **修正致命 SQL 语法错误**：修复 `get_new_add_people_trend_data` 中缺失 `FROM` 的子查询，以及 `cjy_consumption_trend_data` 中错误的 Query Builder 数组键名。
3. **移除硬编码密钥**：将 `$encrypt`、退款 MD5 盐值、`PAY_BASE_URL` 等全部迁移至配置文件或环境变量，杜绝生产环境密钥泄露风险。
### 🛠 后续重构与优化方向（P1/P2）
1. **统一数据访问层 (DAL)**：
- 废弃原生 SQL 字符串拼接，全面迁移至框架 Query Builder。
- 将 `json_encode()` 从 Model 剥离，确保 Model 仅返回 `array` 或 `object`。
2. **抽象通用组件**：
- 将重复的分页计算逻辑封装为 `PaginationTrait` 或独立 Library。
- 将复杂的报表统计（如二次消费、消费走势）拆分为独立的 `ReportService`，避免 Model 臃肿。
3. **性能与数据库优化**：
- 针对 `BETWEEN ? AND ?` 及 `GROUP BY` 高频查询，建议 DBA 添加覆盖索引：`INDEX idx_merchant_shop_time (_merchant_id, _shop_id, _timestamp)`。
- 移除 `force index` 硬编码，改用 `EXPLAIN` 分析慢查询后针对性优化。
4. **现代化 PHP 规范**：
- 启用 `declare(strict_types=1);`。
- 为方法参数和返回值添加类型声明（如 `int`, `array`, `bool`）。
- 使用常量类或枚举（PHP 8.1+）替代散落的 `const` 定义，提升可读性。
> ⚠️ **局限性说明**：您提供的代码在末尾处被截断（`$this->ahead_yc_merchant_user_model->get_one(['_id' => $para`）。若截断部分包含权限校验、事务处理或核心业务逻辑，请补充完整代码后重新提交审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780898524
|
1780898524
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
492
|
22
|
65
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 1
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `75a9d9baa ## 自动代码审查报告
**分支**: app-260616
**提交**: `75a9d9baa49a930ee4e1d99ccd63a2d417ef0915`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-03 10:40:12
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10
- **总体评价**：该模型覆盖了社区商家营收明细的核心业务场景，数据聚合与趋势计算逻辑较为完整。但存在**静态缓存误用导致的数据污染**、**全局实例化反模式**、**SQL 拼接安全隐患**以及**多处重复代码与硬编码**。财务相关写入操作缺乏事务保护，整体架构可维护性与健壮性有待提升。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 第 2-4 行 | 文件顶部直接调用 `get_instance()` 并加载模型。该代码在文件被 `include/require` 时即执行，无论类是否被实例化，造成不必要的性能损耗与全局状态污染。 | 移除顶部代码，将依赖模型加载移至构造函数中，遵循面向对象初始化规范。 | `public function __construct() { parent::__construct(); $this->load->model('Report_model'); }` |
| 🔴 严重 | `get_date_type_info` 方法 | 使用 `public static $date_type_info` 缓存时间配置，但缓存逻辑依赖实例方法 `$this->load->model()` 且未区分 `$shop_id`。首次调用后，后续不同门店的请求将返回错误缓存，导致报表时间范围错乱。 | 移除静态属性，改为实例属性缓存或使用框架缓存驱动（如 Redis/CI Cache），并以 `$shop_id` 作为缓存键。 | `$cache_key = 'date_type_' . $shop_id; if (!$this->cache->get($cache_key)) { ... }` |
| 🟠 警告 | `get_community_revenues_sum_data` & `detail_data` | 手动拼接 SQL 条件字符串 `'(a._pay_platform=' . $pay_platform . ...)'` 并传入 `where` 数组。若 `$params` 未经严格类型校验，将绕过查询构建器的转义机制，存在 SQL 注入风险。 | 使用查询构建器的 `group_start()` / `group_end()` 安全拼接，或强制转换为整型后使用参数绑定。 | `$this->db->group_start()->where('a._pay_platform', (int)$p1)->where('a._second_pay_platform', (int)$p2)->group_end();` |
| 🟠 警告 | `get_community_revenues_trend` 方法 | 在 `foreach ($result as &$v)` 循环中执行 `$this->select()`，形成循环查库。虽当前仅循环 2 次，但违背批量查询原则，且未使用 `try...finally` 保证 `enforce_con_db(2)` 必定执行，异常时可能残留连接状态。 | 提取时间范围后使用 `IN` 或范围查询一次性拉取数据，在 PHP 层分组聚合；数据库切换操作需包裹 `try...finally`。 | `try { $this->enforce_con_db(); $data = $this->select(...); } finally { $this->enforce_con_db(2); }` |
| 🟠 警告 | 所有 `add_by_*` 方法 | 财务数据写入直接调用 `$this->insert()`，未包裹数据库事务。若 `_add_log` 内部或后续业务逻辑抛出异常，可能导致营收明细与主订单状态不一致。 | 使用框架事务机制包裹关键写入流程，失败时自动回滚。 | `if ($this->db->trans_begin()) { $this->insert($data); $this->db->trans_commit(); } else { $this->db->trans_rollback(); }` |
| 🟡 建议 | 全局多处 | 大量硬编码魔法数字（如 `1`/`2` 表示收支类型，`8`/`9` 表示支付渠道），可读性差且后期维护易遗漏。 | 定义类常量统一管理业务状态，或使用 PHP 8.1+ `enum`。 | `const TYPE_INCOME = 1; const TYPE_REFUND = 2; const PAY_WECHAT = 1;` |
| 🟡 建议 | `get_community_revenues_data` & `sum_data` | 两个方法的 `foreach` 聚合逻辑完全重复，违反 DRY 原则。 | 提取为私有方法 `aggregate_revenue_data($data)`，统一处理金额计算与格式化。 | `private function aggregate_revenue_data(array $data): array { ... }` |
| 🟡 建议 | 类名与方法名 | 命名不符合 PSR-12 规范（如 `Jh_community_shop_revenues_detail_model`、`_add_log`）。 | 类名改为 `PascalCase`，方法名改为 `camelCase`，移除前导下划线。 | `class JhCommunityShopRevenuesDetailModel extends Report_model`<br>`private function addLog(...)` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复静态缓存污染**：立即移除 `public static $date_type_info` 的跨实例共享逻辑，改为基于 `$shop_id` 的实例缓存或框架缓存，否则多门店并发请求将产生严重数据错乱。
2. **消除 SQL 拼接隐患**：将 `pay_platform_where` 的手动字符串拼接替换为查询构建器的安全条件方法（如 `group_start()`/`group_end()` 或 `or_where()`），并对 `$params` 输入进行严格类型过滤。
3. **补充事务保护**：所有涉及 `_amount` 写入的 `add_by_*` 方法必须包裹数据库事务，确保财务明细与业务主表的数据原子性。
### 🛠 后续重构与优化方向
- **架构规范化**：将文件顶部的 `get_instance()` 调用彻底移除，依赖注入或构造函数加载模型。若 `phpci` 支持依赖注入容器，建议逐步替换 `$this->load->model()`。
- **查询性能优化**：`get_community_revenues_trend` 中的循环查库可优化为单次范围查询 + PHP 数组映射。建议在 `_business_date`、`_pay_platform`、`_type` 字段建立联合索引，加速 `GROUP BY` 聚合。
- **代码可维护性提升**：
- 提取重复的聚合逻辑与社区商家校验逻辑至 `Report_model` 基类。
- 使用常量/枚举替代魔法数字，配合 IDE 提示降低误用率。
- 统一遵循 PSR-12 命名与注释规范，补充 `@throws`、`@return` 类型声明。
- **框架适配提示**：代码呈现典型的 CodeIgniter 3/4 架构特征。若 `phpci` 为内部定制框架，请确认 `enforce_con_db()`、`select()` 等底层方法是否已内置防注入与连接池管理机制。建议查阅 `phpci` 官方文档中关于 **Query Builder 安全绑定** 与 **多数据源切换** 的最佳实践。
> 💡 **审查局限性说明**：本次审查基于提供的单一模型文件。若 `Report_model` 基类或 `select()` 底层实现已内置事务/防注入逻辑，部分风险等级可相应下调。建议结合完整调用链与数据库索引结构进行二次验证。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780454412
|
1780454412
|
0
|
0
|
0
|
0
|
Edit
Delete
|