|
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
|
|
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
|
|
466
|
21
|
177
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 优惠券可用，0元判断
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `3f39beffe ## 自动代码审查报告
**分支**: pay-260616
**提交**: `3f39beffef0899eed9db6cbf300ea1c7978dff1b`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 14:55:53
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了较为完整的优惠券/奖励券业务逻辑，包含状态映射、场景过滤、批量数据组装等功能。但存在明显的 **SQL 注入风险**、**循环内 N+1 查询性能瓶颈**、**异常吞没** 以及 **拼写/命名不规范** 问题。代码末尾存在截断，导致语法不完整。整体可维护性与安全性需重点优化。
- **风险等级**：🔴 高（存在 SQL 注入隐患与未处理的语法截断）
> 📌 **框架说明**：根据目录结构（`system/`, `application/`）及 `$this->load->model()` 等特征，推断实际框架为 **CodeIgniter 3.x**。以下审查基于 CI3 最佳实践。若 `phpci` 为自研框架，请对照其官方文档调整组件调用方式。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_valid_coupon` 末尾 | **代码截断与语法错误**：方法在 `continue` 处中断，缺少分号及闭合大括号，直接导致解析失败。 | 补全逻辑分支、闭合 `foreach`、`if` 及方法体。确保所有控制流完整。 | `continue;`<br>`}`<br>`}`<br>`return [...];` |
| 🔴 严重 | `get_my_reward_list`<br>`get_reward_list` | **SQL 注入漏洞**：`$params['name']` 与 `$shopIds` 直接拼接至 `LIKE` 和 `REGEXP` 语句中，未做转义或参数绑定。 | 使用 CI Query Builder 的 `like()` 方法，或对输入进行严格类型校验与 `escape()` 处理。 | `$this->db->like('reward._name', $params['name']);`<br>`$shopIds = array_map('intval', $shopIds);` |
| 🟠 警告 | `build_reward_data` | **N+1 查询性能瓶颈**：在 `foreach` 循环中调用 `get_package_shop_ids()` 和 `get_one()`，数据量大时将引发严重数据库压力。 | 提前收集所有 `relation_id`，使用 `WHERE IN` 批量查询，构建映射数组后再循环赋值。 | 见下方重构示例 |
| 🟠 警告 | `add_reg_reward`<br>`add_reg_gift` | **异常吞没**：`catch (Exception $e)` 仅返回固定提示，未记录错误堆栈，导致线上问题难以排查。 | 使用 `log_message('error', $e->getMessage());` 记录日志，或向上抛出异常交由全局错误处理。 | `catch (\Exception $e) { log_message('error', $e->getMessage()); return ['success'=>false, 'msg'=>'系统异常']; }` |
| 🟠 警告 | 文件头部 | **错误使用 `get_instance()`**：在 Model 文件顶部直接调用 `$CI = &get_instance();` 违反 CI 生命周期，且 Model 内部应直接使用 `$this`。 | 删除全局 `$CI` 赋值。若需调用其他组件，应在方法内使用 `$this->load->...` 或 `$this->...`。 | `// 删除此行：<br>// $CI = &get_instance();` |
| 🟡 建议 | 全文多处 | **拼写与命名不规范**：`$fileds` → `$fields`，`$from_palce` → `$from_place`，`TYPR_DADA` → `TYPE_DATA`。违反 PSR-12。 | 全局搜索替换修正拼写，常量使用大写下划线，变量使用小驼峰或蛇形。 | `const TYPE_DATA = [...];<br>public $fields = "...";` |
| 🟡 建议 | 各方法内部 | **重复加载 Model/Library**：`$this->load->model()` 在多个方法中重复调用，增加框架解析开销。 | 将公共依赖移至 `__construct()` 中加载，CI 会自动缓存已加载组件。 | `public function __construct() { parent::__construct(); $this->load->model('Ahead_shop_model'); }` |
| 🟡 建议 | `build_reward_data` | **时间计算逻辑脆弱**：`strtotime(date("Ymd") . " +1 day")` 依赖字符串拼接，易受时区影响。 | 使用 `strtotime('today')` 与 `strtotime('tomorrow')` 或 `DateTime` 对象提升可读性与准确性。 | `$today_start = strtotime('today');<br>$tomorrow_start = strtotime('tomorrow');` |
---
## 3. 总结与行动建议
### 🔑 优先修复项（P0/P1）
1. **修复 SQL 注入**：立即替换所有手动拼接的 `LIKE`、`REGEXP`、`FIND_IN_SET` 语句。CI3 推荐使用 `$this->db->like()`、`$this->db->where_in()` 或 `$this->db->query($sql, $bindings)` 进行参数绑定。
2. **补全代码截断**：检查 `get_valid_coupon` 方法末尾逻辑，确保 `continue;` 语法完整，并闭合所有控制块。
3. **消除 N+1 查询**：将 `build_reward_data` 中的循环内查询改为批量查询。示例：
```php
// 优化前（循环内查询）
foreach ($reward_data as &$row) {
$row['shop_ids'] = $this->model->get_package_shop_ids($row['relation_id']);
}
// 优化后（批量查询+映射）
$relation_ids = array_column($reward_data, 'relation_id');
$shop_map = $this->model->get_package_shop_ids_batch($relation_ids); // 返回 [id => shop_ids]
foreach ($reward_data as &$row) {
$row['shop_ids'] = $shop_map[$row['relation_id']] ?? [];
}
```
### 🛠 后续重构方向
1. **统一数据访问层**：当前 Model 承担了过多业务逻辑（如 URL 拼接、前端展示字段组装）。建议将 `build_reward_data` 中的视图渲染逻辑剥离至 `Service` 层或 `Helper`，保持 Model 专注数据读写。
2. **引入类型声明**：若运行环境为 PHP 7.4+，建议为方法参数和返回值添加类型提示（如 `public function add_reg_reward(int $merchantId, int $shopId, int $uid, array $params = []): array`），提升静态分析能力与代码健壮性。
3. **配置化魔法值**：将硬编码的状态码、场景映射、图片 URL 等抽离至配置文件（如 `config/reward.php`），便于运营动态调整，减少代码修改频率。
4. **规范异常处理**：建立统一的业务异常类（如 `RewardException`），在 Controller 层捕获并格式化返回，避免 Model 层直接返回 `['success'=>false, 'msg'=>...]` 混合结构。
> 💡 **提示**：若需针对 `get_valid_coupon` 截断部分进行完整审查，请提供完整代码。当前审查已覆盖核心风险点，建议按优先级逐步落地修复。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780383353
|
1780383353
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
465
|
21
|
176
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616 🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616' of https://gitea.g-hi.co...
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `e6cbddd66 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `e6cbddd666642acd220fe95c1d43a33018e53773`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 14:41:28
---
## 📋 审查摘要
- **变更文件数**: 3
- **严重问题**: 2
- **高危问题**: 5
- **中危问题**: 4
- **建议优化**: 3
## 🐛 发现的问题
### <font color="red">[语法错误] 类定义外部调用 get_instance() 与 load_model()</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: `application/models/Ahead_shop_book_time_info_model.php`
- **行号**: 1-3
- **问题描述**: 在 PHP 类定义外部直接执行 `$CI = &get_instance();` 和 `$CI->load->model('Simple_model');`。在 CodeIgniter 框架中，文件被 `require/include` 时框架核心尚未完全初始化，此时调用 `get_instance()` 会返回 `NULL` 或触发致命错误，且破坏了 CI 的模型加载生命周期。
- **修复建议**: 删除文件顶部的全局代码。将基类加载移至构造函数内，或直接继承 CI 标准基类：
```php
class Ahead_shop_book_time_info_model extends CI_Model { // 或 Simple_model
public function __construct() {
parent::__construct();
$this->load->model('Simple_model'); // 如需显式加载
}
}
```
### <font color="red">[跨文件调用] 未加载的自定义 Helper 函数将导致致命错误</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `application/models/Ahead_shop_book_time_info_model.php`
- **行号**: 多处（如 `throwError`, `timeToHour`, `hourToTime`, `mergeTimeRanges`, `shiftTimeRange`, `minutesToUnits`, `minToStr`, `mintoStr`, `getPrevUnitTime` 等）
- **问题描述**: 代码中大量调用了自定义辅助函数，但当前文件及构造函数中均未使用 `$this->load->helper()` 加载对应文件。若未在 `config/autoload.php` 中全局配置，运行时会直接抛出 `Call to undefined function` 致命错误。
- **修复建议**: 在 `__construct()` 中统一加载所需 Helper，或确认已加入自动加载配置：
```php
public function __construct() {
parent::__construct();
$this->load->helper(['custom_time', 'custom_array', 'custom_string']); // 替换为实际文件名
}
```
### <font color="red">[跨文件调用] 依赖的模型/基类未在提供的项目结构中验证</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `application/models/Ahead_shop_book_time_info_model.php`
- **行号**: 类定义行及多处 `$this->load->model()`
- **问题描述**: 代码继承 `Simple_model`，并动态加载 `ahead_family_servers_model`, `ahead_shop_config_second_model`, `ahead_room_discontinue_rule_model`, `ahead_shop_model`, `ahead_room_timing_model`, `ahead_book_time_lock_model`。提供的「项目结构」中未包含这些文件。若文件不存在或命名不符合 CI 规范（如 `Xxx_model.php` 对应类 `Xxx_model`），将触发 `Unable to locate the model you have specified` 错误。
- **修复建议**: 核对 `application/models/` 目录，确保所有被引用的模型文件存在，且文件名与类名严格匹配（CI3 推荐首字母大写或全小写，但需与 `$this->load->model('xxx_model')` 参数一致）。
### [安全隐患] 前端未校验数据直接调用系统 API 可能导致崩溃
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/coupon/shop-list/shop-list.js`
- **行号**: ~238 (`handleCancel` 方法)
- **问题描述**: `wx.makePhoneCall({ phoneNumber: this.data.oper_shop.shop_phone_number })` 未对 `oper_shop` 对象及 `shop_phone_number` 字段进行非空校验。若用户未选择门店或数据未正确回显即触发取消操作，将传入 `undefined`，导致微信 API 报错并中断后续逻辑。
- **修复建议**: 增加防御性判断：
```javascript
handleCancel() {
this.setData({ showConfirm: false });
const phone = this.data.oper_shop?.shop_phone_number;
if (!phone) return wx.showToast({ title: '暂无联系电话', icon: 'none' });
wx.makePhoneCall({ phoneNumber: phone });
}
```
### [逻辑 BUG] JS 对象字面量键名重复导致数据覆盖
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js`
- **行号**: ~20, ~26
- **问题描述**: `data` 对象中 `operational_scene: ''` 被定义了两次。在 JS 中，后定义的键会静默覆盖前者，可能导致初始状态混乱，且增加后期维护排查成本。
- **修复建议**: 删除重复的 `operational_scene: ''` 定义，保留一处即可。
### [逻辑 BUG] 数组索引越界风险未做拦截
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js`
- **行号**: ~105, ~110 (`toPayPage` 方法)
- **问题描述**: 直接通过 `this.data.package_list[this.data.packageIndex].id` 和 `this.data.hour_list[this.data.hourIndex].hour` 拼接 URL。若 `packageIndex` 或 `hourIndex` 仍为初始值 `-1`，或对应数组为空，将抛出 `Cannot read properties of undefined` 异常导致页面白屏。
- **修复建议**: 跳转前增加有效性校验：
```javascript
toPayPage() {
if (this.data.tabId === 'package') {
if (this.data.packageIndex < 0 || !this.data.package_list[this.data.packageIndex]) {
return wx.showToast({ title: '请选择套餐', icon: 'none' });
}
// ... 跳转逻辑
} else {
if (this.data.hourIndex < 0 || !this.data.hour_list[this.data.hourIndex]) {
return wx.showToast({ title: '请选择时长', icon: 'none' });
}
// ... 跳转逻辑
}
}
```
### [代码质量] 多处拼写错误可能导致逻辑分支失效
- **严重程度**: 中危
- **文件**: `application/models/Ahead_shop_book_time_info_model.php`
- **行号**: 多处
- **问题描述**: 存在明显的拼写不一致或错误，若前端或下游逻辑依赖这些字段名将导致数据匹配失败：
- `mintoStr` (应为 `minToStr`，与同文件其他调用不一致)
- `v['opreational_scene']` (应为 `operational_scene`)
- `cross_day_emd_time` (应为 `cross_day_end_time`)
- **修复建议**: 使用 IDE 全局搜索替换功能统一修正拼写，并建立提交前拼写检查规范。
### [代码质量] 核心方法过长，违反单一职责原则
- **严重程度**: 中危
- **文件**: `application/models/Ahead_shop_book_time_info_model.php`
- **行号**: `get_book_day_time_info` 方法 (约 350+ 行)
- **问题描述**: 该方法同时承担了时间计算、套餐可用性校验、门店营业时间判断、不可用时间合并、跨天逻辑处理、价格信息获取等过多职责。代码嵌套深、状态变量多，极难进行单元测试和后续迭代维护。
- **修复建议**: 按业务边界拆分为多个私有方法，例如：
- `_calculate_business_time_range()`
- `_check_package_time_availability()`
- `_merge_unavailable_time_slots()`
- `_apply_voucher_restrictions()`
主方法仅负责流程编排，提升可读性与可测试性。
## ✅ 代码亮点
1. **定位防重入机制优秀**：`shop-list.js` 中的 `getLocation` 使用了 `_locating` 锁配合 `15秒` 超时兜底释放，有效避免了并发请求和异常回调导致的永久阻塞，体现了扎实的异步编程功底。
2. **动态 Tab 渲染逻辑清晰**：`continue-packages.js` 根据 `package_list` 和 `hour_list` 的实际数据动态生成 `tab_list` 并自动选中默认项，交互体验流畅。
3. **静态缓存优化查询**：PHP 模型中合理使用 `self::$book_days_info`、`self::$shop_data` 等静态变量缓存高频查询结果，有效降低了数据库 IO 压力。
## 📝 总体建议
1. **严格遵循 CI 生命周期**：立即修复模型文件顶部的全局 `$CI` 调用，确保所有依赖加载在 `__construct()` 或方法内部执行。建议统一在 `autoload.php` 中配置常用 Helper/Model，避免遗漏。
2. **强化前端防御性编程**：小程序端在调用 `wx.navigateTo`、`wx.makePhoneCall` 或访问数组元素前，务必进行非空与边界校验，防止因后端数据延迟或异常导致前端崩溃。
3. **重构巨型方法**：`get_book_day_time_info` 是典型的“上帝方法”，建议尽快按职责拆分。可引入策略模式或工厂模式处理不同场景（如团购券、普通预订、跨天预订）的时间计算逻辑。
4. **建立跨文件引用检查流程**：建议在 CI/CD 或本地提交钩子中加入静态分析工具（如 PHPStan、ESLint），自动拦截未定义的函数、类及拼写错误，降低运行时风险。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780382488
|
1780382488
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
464
|
21
|
175
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 定位弹窗bug修复，锁逻辑优化
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `b65ecaaf1 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `b65ecaaf1ca6e9661d5f83a54a98f597c6b923e3`
**提交人**: linyangrui (yangruilin888@gmail.com)
**时间**: 2026-06-02 14:01:45
---
## 📋 审查摘要
- **变更文件数**: 1
- **严重问题**: 1
- **高危问题**: 2
- **中危问题**: 2
- **建议优化**: 2
## 🐛 发现的问题
### <font color="red">[跨文件调用] 引用了项目中未定义的 config 及 Model 类</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/coupon/shop-list/shop-list.js`
- **行号**: 第 2-4 行
- **问题描述**: 代码中导入了 `../../../config`、`../../../models/public.js` 和 `../../../models/reserve.js`，并实例化了 `PublicModel` 和 `ReserveModel`。但根据提供的项目结构，仅包含 PHP 系统文件，**未包含任何 JS 配置文件或 models 目录**。若这些文件不存在或导出方式不匹配（如未使用 `export class` 或 `module.exports`），将直接导致页面白屏或 `ReferenceError`。
- **修复建议**:
1. 确认 `config.js`、`models/public.js`、`models/reserve.js` 是否真实存在于对应路径。
2. 确保模型文件使用正确的 ES6 模块导出语法，例如：
```javascript
// models/public.js
export class PublicModel { ... }
```
3. 若使用 CommonJS，需改为 `const { PublicModel } = require('../../../models/public.js')`。
### [逻辑 BUG] 未校验数组类型直接调用 includes 方法可能导致运行时崩溃
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/coupon/shop-list/shop-list.js`
- **行号**: 第 238-239 行 (`tuanGouVerify` 方法内)
- **问题描述**: `book_operational_scene.includes(...)` 和 `open_room_operational_scene.includes(...)` 直接假设 `this.data.oper_shop.book_operational_scene` 为数组。若后端返回 `null`、`undefined` 或字符串，调用 `.includes()` 会抛出 `TypeError: Cannot read properties of undefined (reading 'includes')`，导致核销流程中断。
- **修复建议**: 增加类型安全校验或使用可选链：
```javascript
const bookScene = Array.isArray(this.data.oper_shop.book_operational_scene) ? this.data.oper_shop.book_operational_scene : [];
if (bookScene.includes(Number(this.data.operational_scene))) { ... }
```
### [逻辑 BUG] 拨打电话前未校验手机号有效性
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/coupon/shop-list/shop-list.js`
- **行号**: 第 212 行 (`handleCancel` 方法内)
- **问题描述**: `wx.makePhoneCall({ phoneNumber: this.data.oper_shop.shop_phone_number })` 直接读取门店数据。若 `oper_shop` 未正确加载或 `shop_phone_number` 字段为空/非数字字符串，微信 API 会静默失败或弹出错误提示，影响用户体验。
- **修复建议**: 调用前增加有效性校验：
```javascript
const phone = this.data.oper_shop.shop_phone_number;
if (phone && /^1[3-9]\d{9}$/.test(phone)) {
wx.makePhoneCall({ phoneNumber: phone });
} else {
wx.showToast({ title: '门店电话无效', icon: 'none' });
}
```
### [代码质量] 频繁使用 wx.redirectTo 可能导致页面导航栈断裂
- **严重程度**: 中危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/coupon/shop-list/shop-list.js`
- **行号**: 第 168-203 行 (`onShopClick` 方法内)
- **问题描述**: 多个分支大量使用 `wx.redirectTo` 关闭当前页并跳转。若用户从深层页面（如订单详情）进入此页，`redirectTo` 会销毁当前页，导致用户点击“返回”时直接跳回首页或上一页，破坏预期的导航层级。
- **修复建议**: 根据业务场景区分使用 `wx.navigateTo`（保留当前页，允许返回）或 `wx.redirectTo`。对于“选择门店后返回上一页”的场景，推荐使用 `wx.navigateBack()` 配合页面通信（`getCurrentPages()` 或全局事件总线）传递数据。
### [代码质量] 定位防重入锁状态变量未初始化
- **严重程度**: 中危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/coupon/shop-list/shop-list.js`
- **行号**: 第 78-81 行 (`getLocation` 方法内)
- **问题描述**: `this._locating` 和 `this._locatingTimer` 作为实例属性使用，但未在 `data` 或 `onLoad` 中初始化。虽然 JS 允许动态添加属性，但在严格模式或某些小程序基础库版本中可能引发不可预期的状态残留。
- **修复建议**: 在 `data` 中显式声明或在 `onLoad` 初始化：
```javascript
data: {
// ... 其他字段
_locating: false,
_locatingTimer: null
}
// 使用时改为 this.data._locating 或保持实例属性但统一初始化
```
## ✅ 代码亮点
1. **防重入与超时兜底设计优秀**：`getLocation` 中通过 `this._locating` 防重入，并配合 `setTimeout` 15秒强制释放锁，有效避免了定位 API 异常回调缺失导致的永久阻塞问题。
2. **箭头函数保留上下文**：所有 `wx` API 回调均使用箭头函数 `(res) => {}`，正确绑定了 `this` 指向，避免了传统回调中 `this` 丢失的常见陷阱。
3. **状态分离清晰**：将 UI 展示状态（如 `oper_scene_list_show`）与业务数据（`oper_scene_list`）分离，符合小程序数据驱动视图的最佳实践。
## 📝 总体建议
1. **跨文件依赖强校验**：当前代码强依赖外部 Model 和 Config，建议在项目根目录补充 `jsconfig.json` 或配置 ESLint 路径别名，并在 CI/CD 流程中加入静态依赖检查，防止路径拼写错误或文件遗漏。
2. **异步流程现代化**：当前大量使用回调函数嵌套，建议逐步迁移至 `Promise` + `async/await` 语法（微信基础库已全面支持），可大幅提升代码可读性与错误捕获能力（配合 `try...catch`）。
3. **框架规范说明**：审查要求中提及了 PHP CodeIgniter 规范，但本文件为微信小程序原生 JS。若项目为前后端分离架构，请确保后端 CI 模型命名规范（如 `Xxx_model.php`）与前端 JS 模型调用逻辑解耦，避免命名混淆。
4. **安全加固**：`getCityByLocation` 中腾讯地图 API Key 直接暴露在前端。建议将逆地理编码请求移至后端代理，或配置微信域名白名单及 Key 的 Referer/IP 限制，防止 Key 被恶意盗刷。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780380105
|
1780380105
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
463
|
21
|
174
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 续费时长不足提醒
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `3d5c038c4 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `3d5c038c406ce0d175afd9afe9d642d16466a5e8`
**提交人**: linyangrui (yangruilin888@gmail.com)
**时间**: 2026-06-02 13:55:36
---
## 📋 审查摘要
- **变更文件数**: 1
- **严重问题**: 2
- **高危问题**: 2
- **中危问题**: 1
- **建议优化**: 1
## 🐛 发现的问题
### <font color="red">[跨文件调用] 引用的模块文件在提供的项目结构中不存在</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js`
- **行号**: 2-4
- **问题描述**: 代码顶部通过 `import` 引入了 `../../../config`、`../../../models/package` 和 `../../../models/billiards`。但提供的项目结构仅包含 PHP/CodeIgniter 系统文件，**未包含任何 JavaScript 模块或模型文件**。无法验证 `PackageModel`、`BilliardsModel` 及其方法 `getTimePackageList()`、`getHourPriceInfo()` 是否存在，若文件缺失或路径错误将直接导致页面白屏或模块加载失败。
- **修复建议**: 确认实际项目目录结构，补充缺失的 JS 配置文件与模型文件，或修正相对路径。若为微信小程序项目，需确保 `models/` 和 `config.js` 存在于正确的相对路径下。
### <font color="red">[语法错误] data 对象中存在重复键名 operational_scene</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js`
- **行号**: 18, 25
- **问题描述**: `data` 对象中 `operational_scene: ''` 被定义了两次（第18行和第25行）。在 JavaScript 中，后定义的键值会静默覆盖前者，但这属于明显的复制粘贴错误，在严格模式或某些构建工具下会抛出语法警告，且极易引发后续数据绑定混乱。
- **修复建议**: 删除第 25 行的重复定义，保留一处即可。
```javascript
// 修复后
data: {
img_baseurl: config.img_baseurl,
order_type: '',
order_id: '',
operational_scene: '', // 仅保留一处
room_id: '',
// ... 其他字段
}
```
### [逻辑 BUG] toPayPage 方法中未校验索引导致潜在的越界/空指针异常
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js`
- **行号**: 118, 124
- **问题描述**: `toPayPage()` 中直接通过 `this.data.package_list[this.data.packageIndex].id` 和 `this.data.hour_list[this.data.hourIndex].hour` 获取数据。初始状态下 `packageIndex` 和 `hourIndex` 均为 `-1`。若用户在未点击选择任何套餐或时长时直接触发“下一步”，将抛出 `TypeError: Cannot read properties of undefined`，导致页面崩溃。
- **修复建议**: 在跳转前增加索引有效性校验：
```javascript
toPayPage() {
if (this.data.tabId === 'package') {
if (this.data.packageIndex === -1 || !this.data.package_list[this.data.packageIndex]) {
return wx.showToast({ title: '请选择套餐', icon: 'none' });
}
wx.navigateTo({ url: `...&package_id=${this.data.package_list[this.data.packageIndex].id}&from=renew` });
} else {
if (this.data.hourIndex === -1 || !this.data.hour_list[this.data.hourIndex]) {
return wx.showToast({ title: '请选择时长', icon: 'none' });
}
wx.navigateTo({ url: `...&hour=${this.data.hour_list[this.data.hourIndex].hour}&from=renew` });
}
}
```
### [安全隐患] URL 参数拼接未进行编码处理
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js`
- **行号**: 118, 124
- **问题描述**: 使用字符串拼接构造 `wx.navigateTo` 的 `url`。若 `order_id`、`order_type` 或动态获取的 `package_id`/`hour` 中包含特殊字符（如 `&`, `?`, `#`, 空格或中文字符），会导致 URL 解析错误、参数截断或路由跳转失败。
- **修复建议**: 使用 `encodeURIComponent()` 对所有动态参数进行安全编码：
```javascript
const params = `order_id=${encodeURIComponent(this.data.order_id)}&order_type=${encodeURIComponent(this.data.order_type)}&package_id=${encodeURIComponent(this.data.package_list[this.data.packageIndex].id)}&from=renew`;
wx.navigateTo({ url: `/pages/community-reserve/pay/pay?${params}` });
```
### [代码质量] 生产环境遗留 console.log 调试代码
- **严重程度**: 中危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js`
- **行号**: 108
- **问题描述**: `console.log('getHourPriceInfo', res)` 未移除。在正式环境中输出完整响应对象可能泄露敏感业务数据（如价格策略、用户标识等），且频繁打印会影响小程序性能。
- **修复建议**: 移除该行，或替换为项目统一的日志上报工具（如仅在开发环境输出）。
### [代码质量] 回调风格嵌套较深，建议改用 Promise/async-await
- **严重程度**: 低危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js`
- **行号**: 45, 105
- **问题描述**: `packageModel.getTimePackageList` 和 `billiardsModel.getHourPriceInfo` 采用传统回调函数风格。在复杂业务逻辑中易导致回调地狱，且错误处理（如网络超时、接口报错）不够直观。
- **修复建议**: 将底层模型请求改造为返回 `Promise`，页面层使用 `async/await` 重构，提升可读性与异常捕获能力。
## ✅ 代码亮点
1. **动态 Tab 渲染逻辑清晰**：`getPackageList` 中根据 `time_package` 和 `hour_list` 的数据状态动态生成 `tab_list`，并自动选中默认项，用户体验设计合理。
2. **状态管理集中**：使用 `this.setData` 统一更新视图状态，符合微信小程序数据驱动的开发规范。
3. **防御性编程意识**：在 `onHourTap` 中对 `item.status == '-1'` 进行了拦截，避免了无效请求。
## 📝 总体建议
1. **框架环境对齐**：提供的项目结构为 PHP/CodeIgniter 后端目录，但变更文件为微信小程序前端 JS。请确保前后端项目目录隔离清晰，或在审查时提供完整的前端目录树，以便准确验证跨文件引用。
2. **强化空值与边界校验**：前端直接依赖后端返回的数组索引极易引发崩溃。建议在数据赋值后统一进行类型/长度校验，或使用可选链操作符 `?.` 提升代码健壮性。
3. **统一请求封装**：建议将 `packageModel` 和 `billiardsModel` 的底层请求统一封装为支持 `Promise` 的 HTTP 客户端，集中处理 Loading 状态、Token 注入、全局错误拦截与重试机制。
4. **代码规范**：建议接入 ESLint + Prettier 进行自动化检查，避免重复键名、未编码参数等低级问题流入生产环境。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780379736
|
1780379736
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
462
|
21
|
173
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616 🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616' of https://gitea.g-hi.co...
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `bf1edff88 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `bf1edff88440429c70c62cec00506846bb56d7e2`
**提交人**: linyangrui (yangruilin888@gmail.com)
**时间**: 2026-06-02 13:52:49
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了复杂的订单计价、预订校验与支付退款逻辑，业务覆盖较全。但存在明显的**财务精度隐患**、**遗留调试代码**、**事务控制不规范**及**大量魔法数字**。代码结构偏向“过程式堆砌”，缺乏面向对象封装，且未遵循现代 PHP 编码规范。
- **风险等级**：🟠 中（涉及资金计算与支付回调，精度与事务问题可能引发资损或数据不一致）
> 📌 **框架说明**：根据代码结构（`BASEPATH`、`get_instance()`、`system/` 目录规范），当前项目实际基于 **CodeIgniter 3** 框架，而非 `phpci`。以下审查将严格基于 CI3 架构与 PHP 最佳实践进行。
---
## 2. 问题详情
| 严重程度 | 文件/位置 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Neworderservice.php`<br>`getOrderTypeInfo` 方法内 | **遗留调试代码**：循环中存在 `echo $vip_upgrade_data_actual_pay;`。在 API/Service 层直接输出会破坏 JSON/XML 响应结构，导致前端解析失败或支付回调异常。 | 立即删除 `echo`，如需排查请改用 `log_message('debug', ...)` 或框架日志组件。 | `// 删除该行<br>log_message('debug', '升级金额: ' . $vip_upgrade_data_actual_pay);` |
| 🔴 严重 | `Neworderservice.php`<br>多处价格计算逻辑 | **浮点数精度丢失风险**：金额计算直接使用 `float` 运算，仅用 `sprintf("%.2f")` 格式化。PHP 浮点数运算存在固有精度问题（如 `0.1+0.2=0.30000000000000004`），长期运行易导致账目不平。 | 财务计算必须统一转为**整数（分）**或使用 `bcmath` 扩展。所有加减乘除使用 `bcadd`, `bcmul`, `bcsub` 等。 | `$actual_pay = bcmul($price, $quantity, 2);<br>$total = bcadd($total, $actual_pay, 2);` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`check_notify` 方法 | **事务控制不规范**：使用 `$this->db->trans_start()` 配合 `try-catch` 手动 `trans_rollback()`。CI3 的 `trans_start()` 已内置自动回滚机制，混合使用可能导致状态混乱或重复回滚。 | 改用显式事务控制：`trans_begin()` → 业务逻辑 → `trans_status()` 判断 → `trans_commit()` / `trans_rollback()`。 | 见下方重构示例 |
| 🟠 警告 | 多个文件<br>业务方法内部 | **模型重复加载**：在循环或方法体内频繁调用 `$this->CI->load->model()`。CI3 的 Loader 虽支持重复加载不报错，但会增加不必要的 I/O 与内存开销。 | 将依赖模型统一移至 `__construct()` 中加载，或配置 `config/autoload.php`。 | `public function __construct() {<br> parent::__construct();<br> $this->load->model('Ahead_vip_level_model');<br>}` |
| 🟠 警告 | `Ahead_shop_book_time_info_model.php` | **静态缓存脏数据风险**：大量使用 `public static $xxx = []` 缓存门店/日期数据。在 PHP-FPM 长连接或 CLI 守护进程下，静态变量不会随请求释放，易引发内存泄漏或跨请求数据污染。 | 改为实例属性 `private $cache = []`，或引入 Redis/Memcached。若必须用静态缓存，需在请求结束或关键节点 `unset()`。 | `private static $cache = [];<br>// 使用完后清理<br>self::$cache = [];` |
| 🟡 建议 | `Neworderservice.php`<br>`Ahead_book_order_model.php` | **魔法数字泛滥**：大量使用 `-1, 1, 2, 3, 4, 5, 7, 13, 14, 22` 表示状态、支付渠道、业务类型。可读性极差，后期维护极易出错。 | 定义类常量或独立配置类集中管理。 | `const PAY_WECHAT = 1;<br>const PAY_VIP = 3;<br>const STATUS_DISABLED = -1;` |
| 🟡 建议 | 全部文件 | **未遵循 PSR-12 规范**：缩进不一致、混用 `array()` 与 `[]`、单行过长、注释风格老旧（如 `//add by nan 210317`）。 | 使用 `PHP-CS-Fixer` 或 IDE 自动格式化。统一短数组语法、4空格缩进、移除过时注释。 | 全局替换 `array()` → `[]`<br>统一注释为 `/** ... */` 或 `// ` |
| 🟡 建议 | `Ahead_book_order_model.php`<br>`send_success_msg` | **敏感信息日志泄露**：`doLog(var_export($order_data, true))` 可能记录用户手机号、支付流水号等敏感信息，违反数据安全规范。 | 日志输出前进行脱敏处理（如手机号掩码、流水号截断）。 | `doLog('退款请求: ' . json_encode($safe_data), 'refund');` |
### 🔧 事务控制重构示例（CI3 推荐写法）
```php
$this->db->trans_begin();
try {
// 1. 执行数据库操作
$this->db->insert('table', $data);
$this->db->update('table', $data, ['id' => $id]);
// 2. 检查事务状态
if ($this->db->trans_status() === FALSE) {
$this->db->trans_rollback();
return ['status' => false, 'msg' => '数据库操作失败'];
}
// 3. 提交事务
$this->db->trans_commit();
return ['status' => true, 'msg' => '成功'];
} catch (Exception $e) {
$this->db->trans_rollback();
log_message('error', '事务异常: ' . $e->getMessage());
return ['status' => false, 'msg' => '系统异常'];
}
```
---
## 3. 总结与行动建议
### 🚨 优先修复项（P0/P1）
1. **立即移除 `echo` 调试代码**，防止破坏 API 响应流。
2. **全面替换浮点数运算为 `bcmath` 或整数分计算**，财务模块必须保证精度绝对安全。
3. **规范数据库事务写法**，采用 `trans_begin()` + `trans_status()` 显式控制，避免隐式回滚导致的状态不一致。
4. **模型依赖前置**，将 `load->model()` 移至构造函数，提升执行效率。
### 🛠 后续重构方向
1. **架构分层优化**：当前 `Neworderservice` 承担了过多职责（价格计算、优惠券校验、套餐组装、状态映射）。建议拆分为：
- `PriceCalculator`（纯计算逻辑，无副作用）
- `OrderAssembler`（数据组装与持久化）
- `CouponValidator`（优惠券规则校验）
2. **常量与配置抽离**：建立 `config/order_constants.php`，集中管理支付渠道、订单状态、业务类型等魔法数字。
3. **引入 DTO/VO 模式**：使用数组传递大量业务数据极易出现键名拼写错误或类型不一致。建议定义 `OrderDTO`、`GoodsDTO` 等数据结构类，提升类型安全与 IDE 提示体验。
4. **静态缓存治理**：评估 `Ahead_shop_book_time_info_model` 中的静态缓存必要性。高频查询建议接入 Redis，低频数据使用实例级缓存即可。
> ⚠️ **局限性说明**：提供的 `Neworderservice.php` 与 `Ahead_shop_book_time_info_model.php` 代码在末尾被截断，部分循环逻辑、边界条件处理及辅助函数（如 `mergeTimeRanges`、`throwError`）无法完整评估。建议补充完整代码以便进行更精准的边界测试与安全审计。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780379569
|
1780379569
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
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
|
|
460
|
22
|
52
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 1
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `b81fc07a2 ## 自动代码审查报告
**分支**: app-260616
**提交**: `b81fc07a2830943f9142c042f75df2aace449b54`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 13:45:48
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了门店包厢时间预订的核心业务逻辑，但存在明显的架构设计缺陷。方法职责过重、时间处理逻辑脆弱、频繁加载模型与重复的 JSON 序列化操作导致性能与维护成本较高。部分边界条件与异常处理缺失，存在潜在的运行时报错风险。
- **风险等级**：🟠 中（存在逻辑隐患、性能瓶颈及不规范用法，需优先重构核心方法）
> ⚠️ **局限性说明**：提供的代码在 `get_shop_book_info_v2` 方法中截断，本次审查仅基于可见部分。若截断处包含关键逻辑（如数据库事务、最终返回结构），请补充后二次审查。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 文件顶部 / 全局作用域 | `$CI = &get_instance();` 定义在类外部，且 `$CI->load->model('Simple_model');` 写法错误。会导致作用域污染、内存泄漏，且在 CLI 或单元测试中直接报错。 | 移除全局 `$CI` 声明。模型加载应统一在 `__construct()` 中完成，或直接继承基类。 | `// 删除顶部代码<br>class Ahead_shop_book_time_info_model extends Simple_model {<br> public function __construct() {<br> parent::__construct();<br> $this->load->model('ahead_family_servers_model');<br> // 其他模型按需加载<br> }<br>}` |
| 🔴 严重 | `_update_un_book_time` 方法内 | `array_intersect(...array_values($all_room_book_time))` 当 `$all_room_book_time` 为空数组时，解包后 `array_intersect()` 接收 0 个参数，PHP 8.0+ 会抛出 `ArgumentCountError`。 | 增加数组元素数量判断，或使用 `array_reduce` 安全求交集。 | `if (count($all_room_book_time) === 0) {<br> $time_info['un_book_time'] = [];<br>} elseif (count($all_room_book_time) === 1) {<br> $time_info['un_book_time'] = array_values($all_room_book_time)[0];<br>} else {<br> $time_info['un_book_time'] = array_intersect(...array_values($all_room_book_time));<br>}` |
| 🟠 警告 | `update_day_book_info` / 时间循环 | 时间步长循环 `for ($i = $start; $i <= $end; $i += $this->min_minute_unit_time)` 未对齐时间单位。若 `$start` 不是 300 秒的整数倍，会导致时间段错位或遗漏，且跨天时 `strtotime($end_date . ' 00:00:00')` 依赖服务器时区。 | 使用 `DateTime` 与 `DateInterval` 生成时间片，或强制对齐起始时间。避免硬编码时区依赖。 | `$start = new DateTime('@' . $book_order['_arrival_time']);<br>$end = new DateTime('@' . $book_order['_end_time']);<br>$interval = new DateInterval('PT5M');<br>while ($start <= $end) {<br> $book_time_arr[] = $start->format('H:i');<br> $start->add($interval);<br>}` |
| 🟠 警告 | `_update_un_book_time` / JSON解析 | `json_decode($data['_time_info'], true)` 未校验返回值。若数据库字段损坏或为空字符串，将返回 `null`，后续 `isset($time_info['room_book_time'])` 会触发 `Warning` 或逻辑异常。 | 增加类型校验与默认值兜底。 | `$time_info = json_decode($data['_time_info'], true);<br>if (!is_array($time_info)) {<br> $time_info = ['room_book_time' => [], 'un_book_time' => []];<br>}` |
| 🟠 警告 | `get_shop_book_info` 方法 | 方法长度超 250 行，混合了数据查询、时间计算、状态过滤、清扫时间叠加、跨天合并等逻辑。违反单一职责原则（SRP），极难测试与维护。 | 拆分为独立方法：`fetchRoomList()`, `calculateBusinessSlots()`, `mergeBookingData()`, `applyCleaningBuffer()`。 | *(架构重构建议，见第3部分)* |
| 🟡 建议 | 多处 | 硬编码魔法数字与字符串（如 `300`, `256`, `'CYD'`, `'ZD'`, `'00:00'`, `'23:55'`）。降低可读性且不利于后续配置化。 | 提取为类常量或配置文件。`256` 应替换为 `JSON_THROW_ON_ERROR`。 | `const MIN_UNIT_SECONDS = 300;<br>const ORDER_TYPE_BOOK = 'CYD';<br>const ORDER_TYPE_BILL = 'ZD';<br>// 使用 json_encode($data, JSON_THROW_ON_ERROR)` |
| 🟡 建议 | 全局/方法内 | 频繁使用 `$this->load->model()` 在业务方法内部动态加载。CI/类CI框架中，模型加载有开销，且破坏依赖可见性。 | 统一在构造函数加载，或使用依赖注入（DI）容器。若 `phpci` 支持懒加载，请确认其性能损耗。 | `// 构造函数中预加载<br>$this->load->model(['ahead_family_servers_model', 'ahead_book_order_model', 'ahead_bill_model']);` |
| 🟡 建议 | `update_day_time_info_by_bill` | 直接访问 `$CI->add_order_by_refund` 全局属性。该属性未定义且易被外部篡改，破坏封装性。 | 通过方法参数传入状态标识，或从 Session/Request 对象中安全获取。 | `public function update_day_time_info_by_bill($bill_data, $type, $is_refund = false) {<br> // 使用 $is_refund 替代 $CI->add_order_by_refund<br>}` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **移除全局 `$CI` 实例化**：立即将 `$CI = &get_instance();` 从文件顶部移除，改为在类方法内按需使用 `$this->load` 或 `$this->db`。
2. **修复 `array_intersect` 解包崩溃风险**：在 `_update_un_book_time` 中增加数组判空逻辑，防止 PHP 8+ 环境直接 Fatal Error。
3. **JSON 解析安全加固**：所有 `json_decode` 调用必须配合 `is_array()` 校验，并设置合理的默认结构，避免脏数据导致后续逻辑断裂。
### 🛠 后续重构与优化方向
1. **时间处理现代化**：
- 废弃 `date()` / `strtotime()` 字符串拼接，全面迁移至 `DateTimeImmutable` 与 `DatePeriod`。
- 将时间片生成逻辑抽离为独立的 `TimeSlotGenerator` 工具类，支持时区、步长、边界对齐配置。
2. **方法职责拆分（SRP）**：
- `get_shop_book_info` 建议拆分为：
- `getBusinessTimeConfig()`：获取营业时间与跨天标识
- `fetchRawBookingData()`：批量查询预订单与账单（避免 N+1）
- `calculateAvailability()`：计算可预订状态与清扫缓冲
- 使用 DTO（数据传输对象）替代深层嵌套数组，提升类型安全。
3. **性能优化**：
- **批量查询**：`_update_un_book_time` 中多次 `get_one` 可合并为 `where_in` 批量查询。
- **缓存策略**：门店营业时间、清扫时间、包厢列表等低频变动数据应引入 Redis/文件缓存，避免每次请求重复查库。
- **JSON 字段优化**：若 `_time_info` 数据量持续增长，建议评估是否拆分为独立的 `room_time_slots` 关联表，利用数据库索引替代 PHP 内存数组运算。
4. **框架适配提示**：
- 若 `phpci` 为内部定制框架，请确认其是否支持 **Repository 模式** 或 **Service 层**。当前 Model 承担了过多业务逻辑，建议将时间计算、状态流转移至 `ShopBookingService`，Model 仅负责数据持久化。
- 代码中大量使用 `do_log()`、`roundTime()`、`hourToTime()` 等未定义函数，请确保这些 Helper 已正确加载且无全局状态污染。
> 💡 **下一步建议**：建议先编写针对 `update_day_book_info` 与 `_update_un_book_time` 的单元测试，覆盖同天、跨天、边界时间、脏 JSON 等场景。通过测试用例驱动重构，可大幅降低线上回归风险。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780379148
|
1780379148
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
459
|
21
|
172
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `33cf68b8e ## 自动代码审查报告
**分支**: pay-260519
**提交**: `33cf68b8eed08573f0ad52ebc59f46f33e002b6c`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 13:42:33
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该模型承载了极其复杂的预订时间计算与状态判定逻辑，业务覆盖全面。但核心方法过长、职责边界模糊、大量依赖全局 `$CI` 对象传递状态，且存在多处逻辑交叉覆盖风险。代码风格偏向传统 PHP 5/7 早期写法，未遵循现代 PSR 规范，可维护性与性能存在明显瓶颈。
- **风险等级**：🔴 高
> 📌 **框架说明**：根据代码结构（`$CI = &get_instance()`、`system/` 目录、`$this->load->model()` 等），该代码实际基于 **CodeIgniter 3** 架构。以下审查基于 CI3 最佳实践。若确为内部自研 `phpci` 框架，请对照其官方文档调整组件加载与生命周期调用方式。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_day_time_info()` 核心循环 | 方法超 300 行，`$v['status']` 在多个 `if` 分支中被反复覆盖修改。条件交叉重叠（如套餐限制、营业时间、不可用时间、跨天逻辑等），极易因执行顺序导致状态误判或漏判。 | **拆分职责**：将校验逻辑抽离为独立方法（如 `checkVoucherTime()`, `checkBusinessHours()`, `checkLockedTime()`），采用**责任链模式**或**策略模式**依次校验，任一失败则提前返回或标记状态，避免嵌套覆盖。 | `foreach ($time_info as &$v) { $v['status'] = $this->validateTimeSlot($v, $constraints); }` |
| 🔴 严重 | `__construct()` & `set_shop_config()` | 频繁调用 `$CI = &get_instance()` 并直接读写 `$CI->operational_scene`、`$CI->request_source` 等属性。破坏 MVC 封装，易引发全局状态污染，且在并发或 CLI 环境下可能导致数据串扰。 | 移除对 `$CI` 属性的直接赋值。改为通过方法参数传递上下文，或使用 `$this->ci = &get_instance()` 在构造函数中缓存一次，仅通过 `$this->ci->config->item()` 读取配置。 | `protected $ci; public function __construct() { parent::__construct(); $this->ci = &get_instance(); }` |
| 🟠 警告 | `_get_un_book_time()` & `get_book_day_time_info()` | 多次重复调用 `ahead_shop_config_second_model->get_shop_setting()` 获取相同配置项，未做请求级缓存，增加数据库 I/O 压力。 | 使用 CI 缓存驱动或请求级静态数组缓存配置。若配置变更不频繁，建议接入 Redis/文件缓存。 | `protected function getShopConfig($key) { static $cache = []; return $cache[$key] ??= $this->ci->ahead_shop_config_second_model->get_shop_setting(...); }` |
| 🟠 警告 | `get_book_day_time_info()` 数据解析 | `json_decode($book_time_info['_time_info_new'], 1)` 未校验 JSON 格式。若数据库字段损坏或包含非法字符，将触发 Warning 并返回 `null`，导致后续 `foreach` 报错。 | 增加 `json_last_error()` 校验，并提供安全降级默认值。 | `$data = json_decode($json, true); if (json_last_error() !== JSON_ERROR_NONE) { $data = []; }` |
| 🟠 警告 | 全局时间计算 | 大量使用字符串时间（如 `'202407010800'`）进行 `array_intersect`、`strtotime` 转换。字符串比较易受时区、格式不一致影响，且性能低于整型时间戳。 | **统一使用 Unix 时间戳（int）**进行区间计算与交集判断，仅在最终输出时格式化为字符串。可封装 `TimeRange` 值对象。 | `class TimeRange { public int $start; public int $end; public function intersects(self $other): bool { ... } }` |
| 🟡 建议 | 全局常量与魔法值 | 大量硬编码魔法值：`'1'`, `'-1'`, `'2'`, `'3'`, `'4'`, `86400`, `3600`。可读性差，后期维护易出错。 | 定义类常量或枚举（PHP 8.1+），集中管理业务状态与时间单位。 | `const STATUS_AVAILABLE = '1'; const STATUS_UNAVAILABLE = '-1'; const SECONDS_PER_DAY = 86400;` |
| 🟡 建议 | 辅助函数依赖 | 依赖大量未命名空间的全局函数（`timeToHour`, `mergeTimeRanges`, `throwError` 等），不符合 PSR-4/12 规范，难以进行单元测试。 | 封装为独立的服务类（如 `BookingTimeCalculator`、`ValidationHelper`），通过依赖注入或静态方法调用，便于 Mock 测试。 | `class TimeUtils { public static function mergeRanges(array $ranges): array { ... } }` |
| 🟡 建议 | `set_shop_config()` 与 `set_room_info()` | 两个方法逻辑高度重复（获取场景、加载配置、计算分钟单位），违反 DRY 原则。 | 合并为单一受保护方法，通过参数区分调用场景，或提取为 `SceneConfigLoader` 组件。 | `protected function loadSceneConfig(?int $roomId = null): void { ... }` |
## 3. 总结与行动建议
### 🚨 优先修复项（P0/P1）
1. **消除 `$v['status']` 状态覆盖风险**：当前 `get_book_day_time_info()` 的 `foreach` 循环是系统核心，状态被多次覆盖极易引发线上客诉（如“明明可订却显示不可订”）。请立即将校验逻辑拆分为独立方法，采用**短路返回**或**状态累加器**模式。
2. **收敛全局 `$CI` 对象滥用**：禁止在 Model 中直接修改 `$CI->xxx` 属性。所有上下文数据（如 `request_source`, `operational_scene`）应通过方法参数传入，或使用 `$this->ci->session->userdata()` 等标准方式获取。
3. **增强 JSON 解析与输入校验**：对 `$params` 增加类型强转与基础校验（如 `ctype_digit($params['merchant_id'])`），对 `json_decode` 增加错误捕获，防止脏数据导致白屏或逻辑中断。
### 🛠 后续重构与优化方向
1. **架构分层**：当前 Model 承担了 `数据查询`、`业务规则计算`、`状态组装` 三重职责。建议引入 **Service 层**（如 `BookingAvailabilityService`）处理复杂时间计算，Model 仅负责数据持久化与基础查询。
2. **时间计算引擎化**：将 `mergeTimeRanges`、`shiftTimeRange`、`minutesToUnits` 等函数抽象为独立的 `TimeRangeCalculator` 类。内部统一使用 `int` 时间戳运算，彻底告别字符串时间拼接，提升计算精度与性能。
3. **配置缓存策略**：门店配置（`book_minute_unit`, `book_hour_options` 等）变更频率低，建议接入 CI 缓存驱动（`$this->ci->cache->save()`）或 Redis，设置合理 TTL（如 30 分钟），减少高频查询对 DB 的冲击。
4. **单元测试覆盖**：该模块逻辑分支极多，强烈建议使用 PHPUnit 编写核心校验逻辑的单元测试。通过 Mock 数据库与 `$CI` 对象，验证不同场景（跨天、套餐限制、最低时长、清扫时间）下的时间槽输出是否符合预期。
> 💡 **提示**：若需进一步审查 `Simple_model` 基类实现、`Tuangou` 库逻辑或控制器层调用方式，请提供相关代码片段。当前审查仅基于已提交的 Model 文件，部分全局函数与框架生命周期细节可能存在上下文盲区。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780378954
|
1780378954
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
458
|
21
|
171
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `86c4ad47f ## 自动代码审查报告
**分支**: pay-260519
**提交**: `86c4ad47ffe62ac1ed36e7dfc000b075636d8d47`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 13:35:51
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了复杂的多场景（KTV/台球/棋牌/酒馆）包厢预订时间计算逻辑，业务覆盖较全。但存在严重的**状态管理混乱**、**方法职责过重**、**静态缓存设计缺陷**及**潜在运行时错误**。代码结构偏向“上帝类”，违反单一职责原则（SRP），可维护性与测试性较差。
- **风险等级**：🔴 高
- **框架说明**：注：从目录结构、`$CI = &get_instance()`、`load->model()` 等特征判断，该代码实际基于 **CodeIgniter 3 (CI3)** 架构。以下审查基于 CI3 最佳实践，若 `phpci` 为内部定制版本，核心 PHP 规范与逻辑建议依然适用。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_days_info` / `self::$shop_data` 等静态属性 | 静态缓存未区分商户/门店ID。同一请求周期内若传入不同 `merchant_id`/`shop_id`，将直接返回错误缓存数据，导致严重业务串扰。 | 移除静态缓存或改用复合键缓存。建议改为实例属性或使用请求级缓存（如 CI 的 `$this->cache`）。 | `$key = "shop_{$merchant_id}_{$shop_id}"; if (!isset(self::$shop_data[$key])) { self::$shop_data[$key] = $this->ahead_shop_model->get_one(...); }` |
| 🔴 严重 | `get_book_day_time_info` / `foreach` 循环内 | 在 `foreach ($time_info as $k => &$v)` 中直接使用 `unset($time_info[$k])` 会破坏数组内部指针，导致后续元素跳过或遍历异常。 | 改用 `array_filter` 过滤，或收集待删除键后统一 `unset`。 | `$time_info = array_filter($time_info, fn($v) => $date != $today || $v['time'] > $now_hour_time);` |
| 🔴 严重 | `get_book_day_time_info` / `array_intersect` | `array_intersect(...array_values($all_room_book_time))` 在数组为空或元素不足时，PHP 8+ 会抛出 `Argument unpacking` 警告/错误，导致脚本中断。 | 增加元素数量校验，或使用 `call_user_func_array` 安全解包。 | `if (count($all_room_book_time) > 1) { $un_book_time = array_intersect(...array_values($all_room_book_time)); }` |
| 🟠 警告 | `get_book_days_info` | `$this->book_days += 1;` 直接修改类属性状态。若该方法被多次调用，天数会持续累加，造成不可预期的逻辑污染。 | 使用局部变量计算，保持实例状态不可变。 | `$days = $this->book_days + ($add_day ? 1 : 0); for ($i = 0; $i < $days; $i++) { ... }` |
| 🟠 警告 | `__construct` 及多处方法 | 频繁调用 `$CI = &get_instance()` 且未复用，增加不必要的函数调用开销。 | 在构造函数中统一赋值给 `$this->ci`，后续统一使用。 | `protected $ci; public function __construct() { parent::__construct(); $this->ci =& get_instance(); }` |
| 🟠 警告 | `get_book_day_time_info` | 方法体超 300 行，嵌套层级深，混合了时间计算、套餐校验、营业时间判断、DB查询等逻辑，违反单一职责原则。 | 拆分为独立私有方法或提取至 `BookingTimeService` 服务层。模型仅保留数据访问。 | 将 `_check_package_time()`, `_check_business_hours()`, `_merge_unavailable_times()` 拆分为独立方法。 |
| 🟠 警告 | 全局 `$params` 使用 | 直接使用 `$params['date']`, `$params['merchant_id']` 等，缺乏类型校验与白名单过滤，存在越权或非法参数注入风险。 | 引入显式类型转换或 CI 表单验证库，关键参数需做合法性校验。 | `$merchant_id = filter_var($params['merchant_id'], FILTER_VALIDATE_INT); if (!$merchant_id) throwError('商户ID无效');` |
| 🟡 建议 | 全局多处 | 存在大量魔法数字/字符串（如 `86400`, `'1'`, `'2'`, `'7'`, `'3600'`），降低可读性且易引发维护错误。 | 提取为类常量或配置文件枚举。 | `const SECONDS_PER_DAY = 86400; const SCENE_KTV = '1'; const SCENE_BILLIARDS = '2';` |
| 🟡 建议 | `get_book_day_time_info` | 变量名拼写错误：`opreational_scene`（应为 `operational_scene`）。 | 全局搜索替换修正拼写，避免后续维护混淆。 | 统一修正为 `operational_scene`。 |
| 🟡 建议 | 全局方法签名 | 缺少 PHP 7+ 类型声明（参数类型、返回类型），不符合现代 PHP 编码规范。 | 补充 `int`, `string`, `array`, `bool` 等类型提示，提升静态分析能力。 | `public function get_book_days_info(int $merchant_id, int $shop_id, string $check_date = '', bool $add_day = false): array` |
## 3. 总结与行动建议
### 🚨 优先修复项（P0/P1）
1. **修复静态缓存串扰**：立即将 `self::$shop_data`、`self::$date_time_info` 等静态属性改为带业务主键的数组缓存，或彻底移除静态缓存改用实例属性。这是当前最高风险点。
2. **修复 `foreach` 中的 `unset` 与数组解包**：替换为 `array_filter` 并增加 `count()` 判断，避免 PHP 8+ 环境下的致命错误。
3. **消除状态污染**：将 `$this->book_days += 1` 等直接修改实例属性的操作改为局部变量计算，确保对象可复用。
### 🛠 架构与重构方向
1. **模型瘦身（Model-Service 分离）**：当前模型承担了过多业务逻辑。建议将时间计算、套餐规则校验、不可用时间合并等逻辑抽离至独立的 `BookingTimeCalculatorService` 或 `PackageRuleValidator`。模型仅保留 `get_one()`, `get_shop_setting()` 等数据访问方法。
2. **统一 CI 实例引用**：在 `__construct` 中缓存 `$this->ci = &get_instance()`，避免重复调用。
3. **引入配置常量**：将 `86400`、`3600`、场景标识 `'1'/'2'/'3'` 等提取为类常量或独立配置文件，提升代码可读性与可维护性。
4. **补充输入校验**：在方法入口处对 `$params` 进行类型强转与合法性校验，避免脏数据流入核心计算逻辑。
### 📝 局限性说明
提供的代码片段在 `_get_un_book_time` 方法末尾被截断（`$this->next_date_room_book_time = [...]` 后无闭合），未能审查完整逻辑。建议补充完整文件后，重点检查跨天时间计算、数据库事务处理及异常回滚机制。若需进一步深度审查完整文件，可提供全量代码。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780378551
|
1780378551
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
457
|
21
|
170
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616 🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616' of https://gitea.g-hi.co...
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `b3e6dcf46 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `b3e6dcf46bee5866a10229a671616ec8e0c5b8e5`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 11:54:00
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码承载了复杂的订单计价、支付回调、退款及时间预订逻辑，业务覆盖面广。但存在明显的“上帝类”与“面条代码”特征，方法过长、职责混杂、大量魔法数字硬编码。财务计算缺乏精度控制，事务处理与框架规范存在偏差，整体可维护性与安全性亟待提升。
- **风险等级**：🔴 高（涉及资金计算精度、潜在 SQL 注入、事务状态机破坏）
> 📌 **框架适配说明**：您提供的代码结构（`BASEPATH`、`get_instance()`、`$this->CI->load->`、`Simple_model` 等）高度符合 **CodeIgniter 3** 规范，而非 `phpci`。以下审查将基于 CI3 最佳实践进行，若实际运行环境为 `phpci`，请核对底层加载器与事务机制的差异。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Neworderservice.php` (多处) | **浮点数精度丢失**：订单金额、折扣、服务费计算直接使用 `*` 和 `/`，未做精度处理，极易导致财务对账出现 `0.01` 元差异。 | 所有货币计算必须使用 `round($val, 2)` 或 `bcmath` 扩展。建议在累加后立即取整。 | `$actual_pay = round($goods['_actual_amount'] * $goods['_quantity'], 2);`<br>`$service_charge = round($actual_pay * $rate / 100, 2);` |
| 🔴 严重 | `Neworderservice.php` ~L330 | **SQL 注入隐患**：`$pack_goods_where = "wares_package._package_id in (" . implode(",", $id_array['package_id']) . ")";` 直接拼接用户可控数组。 | 使用 CI 查询构建器或严格过滤。若必须拼接，需强制转为整型数组。 | `$ids = array_map('intval', $id_array['package_id']);`<br>`$this->db->where_in('_package_id', $ids);` |
| 🔴 严重 | `Ahead_book_order_model.php` ~L75 | **事务状态机破坏**：在 `try` 块中手动调用 `$this->db->trans_rollback()` 后直接 `return`，会破坏 CI3 的 `trans_start()/trans_complete()` 自动提交/回滚机制，导致后续查询报错。 | 移除 `try` 内的手动 rollback，统一交由 `trans_complete()` 处理，或在 `catch` 中抛出异常。 | `try { ... } catch (Exception $e) { $this->db->trans_rollback(); log_message('error', $e->getMessage()); return ['status'=>false, 'msg'=>'支付异常']; }` |
| 🟠 警告 | `Neworderservice.php` ~L480 | **生产环境遗留调试代码**：`echo $vip_upgrade_data_actual_pay;` 会直接输出到响应流，破坏 API JSON/XML 结构。 | 立即移除 `echo`，改用框架日志记录。 | `// echo ...;`<br>`doLog("VIP升级金额累加: {$vip_upgrade_data_actual_pay}", 'vip_upgrade');` |
| 🟠 警告 | `Neworderservice.php` / `Ahead_book_order_model.php` (多处) | **模型重复加载**：在业务方法内部频繁调用 `$this->CI->load->model()`，每次调用都会触发文件包含与实例化，影响性能。 | 将依赖模型移至构造函数初始化，或配置 `autoload.php` 自动加载。 | `public function __construct() { parent::__construct(); $this->load->model(['Ahead_vip_level_model', 'Ahead_merchant_goods_model']); }` |
| 🟠 警告 | `Ahead_book_order_model.php` ~L310 | **原始 SQL 更新风险**：`$log_up = '_status=4,_refund_amount=_actual_pay'; $this->ahead_pay_log_model->up($log_up, $log_where);` 使用字符串拼接更新条件，缺乏参数绑定。 | 使用 CI 的 `update()` 方法或查询构建器，确保字段与值分离。 | `$this->db->set('_status', 4)->set('_refund_amount', '_actual_pay', FALSE)->where($log_where)->update('ahead_pay_log');` |
| 🟡 建议 | `Neworderservice.php` ~L105 | **方法命名拼写错误**：`rest_goods_price_by_un_vip` 中 `rest` 应为 `reset`。 | 修正命名以符合语义规范。 | `public function reset_goods_price_by_un_vip($data, $price_key = '_discount_price')` |
| 🟡 建议 | 全局多处 | **魔法数字泛滥**：`100`, `-1`, `1`, `2`, `3`, `7`, `13`, `14`, `22`, `58`, `56` 等状态值与配置值硬编码，可读性差且易改错。 | 提取为类常量或独立配置文件（如 `config/order_status.php`）。 | `const STATUS_DISABLED = -1;`<br>`const PAY_PLATFORM_WECHAT = 1;`<br>`const VIP_DISCOUNT_BASE = 100;` |
| 🟡 建议 | `Ahead_shop_book_time_info_model.php` | **静态属性缓存风险**：大量使用 `self::$book_days_info` 等静态变量缓存数据。在 PHP-FPM 长连接或 CLI 脚本中可能引发请求间状态污染。 | 改为实例属性 `$this->`，或使用 CI Cache 驱动（Redis/Memcached）进行跨请求缓存。 | `private $book_days_info = [];`<br>`public function get_book_days_info() { if (empty($this->book_days_info)) { ... } return $this->book_days_info; }` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **财务精度控制**：立即全局替换浮点数直接运算，引入 `round($val, 2)` 或 `bcmath`。建议在数据库层使用 `DECIMAL(10,2)`，并在 PHP 层统一封装 `MoneyCalculator` 工具类。
2. **事务机制规范化**：CI3 的事务是状态机模式。请严格遵循 `trans_start() -> 业务逻辑 -> trans_complete()` 范式，**禁止**在 `try` 块中手动 `trans_rollback()` 后直接返回。若需手动控制，请改用 `trans_begin()` / `trans_rollback()` / `trans_commit()`。
3. **SQL 安全加固**：清理所有字符串拼接的 `WHERE` 条件，全面转向 `$this->db->where()`、`$this->db->where_in()` 或参数化查询。
### 🛠 后续重构与优化方向
1. **拆分“上帝类”**：
- `Neworderservice::getOrderTypeInfo()` 超过 400 行，混合了价格计算、优惠券校验、服务费计算、订单组装。建议按职责拆分为：
- `PriceCalculatorService`（纯计算逻辑，无 DB 依赖）
- `CouponValidatorService`（优惠券规则校验）
- `OrderAssemblerService`（数据组装与持久化）
2. **统一异常与日志处理**：
- 代码中混用 `throwError()`、`doLog()`、`do_log()`。建议统一使用 CI 的 `show_error()` / `log_message()`，或引入 Monolog 等现代日志组件。
- 错误码与提示信息应集中管理，避免硬编码散落在业务逻辑中。
3. **时间计算规范化**：
- `Ahead_shop_book_time_info_model` 中大量使用 `strtotime()`、字符串拼接与 `date()` 进行时间区间计算。建议引入 `Carbon` 或 `DateTimeImmutable` 对象，避免跨天、夏令时、时区导致的边界 BUG。
4. **框架规范对齐**：
- 遵循 PSR-12：类名使用 `PascalCase`（如 `NewOrderService`），方法名使用 `camelCase`，添加类型声明（PHP 7.4+ 支持 `array`, `int`, `bool` 等）。
- 若实际框架确为 `phpci`，请核对底层是否兼容 CI3 的 `load->model()` 与事务 API，必要时适配框架提供的 Service Container 与 ORM。
> 💡 **提示**：当前代码片段在末尾被截断，部分逻辑（如 `create_community_shop_book_order` 结尾、`_get_un_book_time` 结尾）未能完整审查。建议补充完整文件后再次进行静态扫描与边界用例测试。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780372440
|
1780372440
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
456
|
21
|
169
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `da5f37938 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `da5f379382fb71fa01d0340a7f3ec62b05f240ae`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 11:14:37
---
## 1. 审查摘要
- **代码质量评分**：5.5/10
- **总体评价**：代码实现了复杂的包厢预订时间计算逻辑，但存在严重的状态管理缺陷、方法职责过重、静态缓存污染风险及性能隐患。整体可维护性较低，在并发或多租户场景下极易引发数据错乱。
- **风险等级**：🔴 高
> **注**：`phpci` 通常指 PHP 持续集成服务器，而非 PHP 开发框架。从代码特征（`$CI = &get_instance()`、`$this->load->model()`、`load->library()`）判断，实际使用的是 **CodeIgniter 3**。以下审查基于 CI3 架构与 PHP 最佳实践。若为自研框架，请对照其生命周期规范调整。
> **局限性说明**：代码在 `_get_un_book_time` 方法末尾截断，未包含完整逻辑。以下审查基于已提供部分，若截断处包含关键事务提交或状态回滚逻辑，请补充后复核。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_days_info` | **静态缓存未区分参数**：`self::$book_days_info` 首次赋值后全局生效。不同商户/门店/日期请求会直接复用脏数据，导致严重业务错乱。 | 移除静态缓存或改用带参数哈希的内存缓存键。若需缓存，应使用 `private static $cache = []` 并以参数组合作为 Key。 | `private static $book_days_cache = [];<br>$cache_key = md5(serialize([$merchant_id, $shop_id, $check_date, $add_day]));<br>if (isset(self::$book_days_cache[$cache_key])) return self::$book_days_cache[$cache_key];<br>// ... 计算逻辑 ...<br>self::$book_days_cache[$cache_key] = $result;` |
| 🔴 严重 | `get_book_days_info` | **实例状态被意外修改**：`$this->book_days += 1;` 直接修改对象属性。多次调用会导致天数无限累加，破坏后续所有依赖该属性的逻辑。 | 使用局部变量替代属性修改，保持对象状态不可变性。 | `$calc_days = $this->book_days + ($add_day ? 1 : 0);<br>for ($i = 0; $i < $calc_days; $i++) { ... }` |
| 🟠 警告 | `get_book_day_time_info` | **方法职责过重（God Method）**：单方法超 300 行，混合了数据查询、时间区间计算、业务规则过滤、UI 状态标记。违反单一职责原则，极难单元测试。 | 拆分为独立私有方法或抽离为 `BookingTimeCalculator` 服务类：`fetchRoomData()`、`calculateAvailableSlots()`、`applyVoucherRules()`、`formatTimeSlots()`。 | （建议按数据流拆分，保持单方法 < 80 行） |
| 🟠 警告 | 全局/多处 | **安全隐患：输入未校验**：`$params` 数组直接传入模型，缺乏类型与边界检查（如日期格式、ID 合法性）。恶意构造参数可能导致时间计算溢出或越权查询。 | 在 Controller 层使用 CI 表单验证或 PHP 8 类型声明；模型入口处增加基础校验。 | `if (!preg_match('/^\d{8}$/', $params['date'] ?? '')) { throwError('日期格式错误'); }<br>$params['merchant_id'] = filter_var($params['merchant_id'], FILTER_VALIDATE_INT);` |
| 🟠 警告 | `_get_un_book_time` | **性能瓶颈：参数展开求交集**：`array_intersect(...array_values($all_room_book_time))` 使用 `...` 展开，当包厢数较多时可能触发 `ArgumentCountError` 或内存飙升。 | 改用迭代方式求交集，或使用 `array_reduce`。 | `$intersection = array_shift($all_room_book_time);<br>foreach ($all_room_book_time as $arr) {<br> $intersection = array_intersect($intersection, $arr);<br>}` |
| 🟠 警告 | 构造函数/多处 | **框架开销：重复获取实例与加载**：多处重复 `$CI = &get_instance();` 及重复 `load->model()`。CI 虽会去重，但增加解析开销且破坏代码整洁度。 | 在构造函数中统一赋值 `$this->ci = &get_instance();`，利用 CI 的自动加载机制。 | `public function __construct() {<br> parent::__construct();<br> $this->ci = &get_instance();<br> $this->load->model('Simple_model');<br> // 其他初始化...<br>}` |
| 🟡 建议 | 类属性定义 | **封装性不足**：大量 `public` 属性暴露内部状态，外部可直接篡改业务规则（如 `$book_time_limit`、`$ignore_tuangou_time_limit`）。 | 改为 `protected` 或 `private`，通过 `getter/setter` 控制访问，并在 setter 中增加合法性校验。 | `protected $book_time_limit = 3600;<br>public function setBookTimeLimit(int $seconds): void {<br> $this->book_time_limit = max(300, $seconds);<br>}` |
| 🟡 建议 | 全局函数依赖 | **隐式依赖全局辅助函数**：大量使用 `timeToHour`、`mergeTimeRanges`、`shiftTimeRange` 等未声明的全局函数，降低可测试性与 IDE 静态分析能力。 | 将时间计算逻辑封装为独立的 `TimeRangeHelper` 类或 Service，通过依赖注入或静态方法调用。 | `class TimeRangeHelper { public static function merge(array $ranges): array { ... } }` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复静态缓存污染与状态突变**：立即移除 `self::$book_days_info` 的无差别缓存，并删除 `$this->book_days += 1` 的副作用代码。这是当前导致多租户数据串扰的核心隐患。
2. **拆分巨型方法**：将 `get_book_day_time_info` 按数据流向拆分为 `获取基础数据` → `计算不可用区间` → `应用业务规则（团购/营业/锁定）` → `格式化输出` 四个独立步骤，提升可读性与可测试性。
3. **输入参数强校验**：在模型入口或 Controller 层对 `$params['date']`、`$params['merchant_id']`、`$params['shop_id']` 进行严格类型与格式校验，防止非法数据流入核心计算逻辑。
### 🛠 后续重构与优化方向
- **架构升级建议**：若项目允许，建议逐步迁移至 **CodeIgniter 4** 或现代 PHP 框架（Laravel/Symfony）。CI4 原生支持依赖注入、命名空间、类型声明与更安全的 Query Builder，可大幅减少 `$CI = &get_instance()` 的滥用。
- **时间计算服务化**：当前时间区间合并、偏移、交集判断逻辑高度耦合。建议抽离为独立的 `BookingTimeService`，使用值对象（Value Object）如 `TimeSlot`、`DateRange` 替代裸数组，提升类型安全。
- **缓存策略优化**：静态数组缓存仅适用于单次请求生命周期。若需跨请求复用，应改用 CI Cache 驱动（Redis/Memcached）并设置合理的 TTL；若仅用于单次请求内复用，请使用 `private static $cache = []` 并严格绑定参数哈希。
- **性能监控**：在 `_get_un_book_time` 中涉及多次 `json_decode` 与数据库查询。建议对 `_time_info_new` 字段建立合理索引，或考虑将高频查询的预订状态同步至 Redis 位图/集合中，降低 MySQL 压力。
> 如需针对截断部分或特定业务场景（如团购券跨天逻辑、包厢锁定机制）进行深度逻辑推演，请提供完整代码片段。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780370077
|
1780370077
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
455
|
21
|
168
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `0ac5959e9 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `0ac5959e97ad1556e54d98b526577ae626e2d2f1`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 11:11:09
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该模型实现了复杂的多场景（KTV/台球/棋牌/酒馆）包厢预订时间计算逻辑，业务覆盖全面。但存在典型的“上帝方法”、状态管理混乱、硬编码泛滥及数组操作性能隐患。代码片段在末尾截断，部分边界逻辑无法完整评估。整体可维护性较低，需进行结构化重构。
- **风险等级**：🔴 高（逻辑耦合度高、静态缓存潜在污染、复杂时间计算易引发线上预订冲突或超时）
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_day_time_info` (~L200-L500) | **上帝方法 (God Method)**：该方法超 300 行，混合了数据查询、时间区间计算、套餐规则校验、营业逻辑判断等。违反单一职责原则，极难测试与维护。 | 拆分为独立方法：`fetchBookingData()`、`calculateTimeSlots()`、`applyPackageConstraints()`、`filterUnavailableRanges()`。通过依赖注入或参数传递状态。 | `// 拆分后结构示意<br>public function getBookDayTimeInfo($params) {<br> $slots = $this->generateBaseSlots($params);<br> $slots = $this->applyBusinessHours($slots);<br> return $this->applyPackageRules($slots);<br>}` |
| 🔴 严重 | `self::$book_days_info` 等静态属性 (~L115) | **静态缓存跨请求污染风险**：在 PHP-FPM 或长驻进程（如 Swoole/CLI Worker）中，静态变量会跨请求残留，导致不同商户/门店数据串扰。 | 改用实例级缓存或引入 Redis/Cache 驱动。若必须使用静态缓存，需在请求生命周期结束时清理，或增加 `merchant_id`+`shop_id` 作为缓存 Key。 | `// 推荐：使用框架缓存组件<br>$cacheKey = "book_days:{$merchant_id}:{$shop_id}";<br>$data = $this->cache->get($cacheKey);<br>if (!$data) { $data = $this->calculateDays(); $this->cache->save($cacheKey, $data, 300); }` |
| 🟠 警告 | 多处 (`__construct`, `set_shop_config` 等) | **频繁调用 `get_instance()`**：每次调用都会触发全局实例查找，增加不必要的开销。 | 在构造函数中统一获取并赋值给实例属性，后续直接复用。 | `class Ahead_shop_book_time_info_model extends Simple_model {<br> protected $ci;<br> public function __construct() {<br> parent::__construct();<br> $this->ci =& get_instance();<br> }<br>}` |
| 🟠 警告 | 全文多处 (`'1'`, `'2'`, `'merchantApp'`, `'7'`) | **魔法值泛滥**：场景标识、请求来源、支付场景等硬编码散落在业务逻辑中，极易因拼写错误或业务变更引发 Bug。 | 提取为类常量，提升可读性与可维护性。 | `const SCENE_KTV = '1';<br>const SCENE_BILLIARDS = '2';<br>const REQUEST_MERCHANT_APP = 'merchantApp';<br>// 使用：if ($this->ci->request_source === self::REQUEST_MERCHANT_APP)` |
| 🟠 警告 | `get_book_day_time_info` (~L280) | **数组展开运算符性能隐患**：`array_intersect(...array_values($all_room_book_time))` 在数组较大时易触发内存溢出或 `ArgumentCountError`。 | 改用迭代交集算法或专用区间计算库。避免一次性展开未知长度的数组。 | `// 安全迭代求交集<br>$result = array_shift($all_room_book_time);<br>foreach ($all_room_book_time as $arr) { $result = array_intersect($result, $arr); }` |
| 🟠 警告 | `_get_un_book_time` (~L620) | **硬编码时间边界判断**：`if ($prev_last_start_hour == '23:55')` 强依赖分钟单位，若商家配置变更（如改为 15 分钟），逻辑将失效。 | 基于动态时间单位计算，或使用 `DateTime` 对象进行精确比较。 | `// 动态判断<br>$maxTime = date('H:i', strtotime('23:59') + $this->min_minute_unit_time);<br>if ($prev_last_start_hour >= $maxTime) { ... }` |
| 🟡 建议 | 类属性定义 (~L10-L100) | **属性可见性设计不当**：大量业务状态属性声明为 `public`，外部可直接篡改，破坏封装性。 | 改为 `protected` 或 `private`，通过方法参数或 Setter 传递状态。 | `protected $book_room_id = 0;<br>protected $shop_business_from = 0;<br>// 提供只读访问器<br>public function getBookRoomId(): int { return $this->book_room_id; }` |
| 🟡 建议 | 时间处理逻辑 (全文) | **时间处理依赖字符串拼接**：大量使用 `date('YmdHi')`、字符串加减，缺乏时区控制，易在跨天/夏令时场景出错。 | 统一使用 `DateTimeImmutable` 或框架日期辅助类，明确时区。 | `// 推荐<br>$dt = new DateTimeImmutable($date . ' ' . $time, new DateTimeZone('Asia/Shanghai'));<br>$timestamp = $dt->getTimestamp();` |
| 🟡 建议 | `throwError()` 调用 (~L210) | **非标准错误处理**：`throwError()` 为全局函数，不符合现代 PHP 异常处理规范，不利于上层捕获与统一响应。 | 改用 PHP 原生异常或框架标准错误抛出机制。 | `if (!$date) {<br> throw new \InvalidArgumentException('请选择预订日期');<br>}` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **拆分核心大方法**：立即将 `get_book_day_time_info` 拆分为职责单一的私有方法，降低圈复杂度（Cyclomatic Complexity），便于编写单元测试。
2. **消除静态缓存隐患**：将 `self::$xxx` 静态缓存替换为带业务维度的实例缓存或 Redis 缓存，防止多租户/多门店数据串扰。
3. **统一魔法值为常量**：提取所有场景标识、状态码、请求来源为 `const`，并在逻辑判断中全面替换。
4. **优化数组区间计算**：替换 `array_intersect(...$arr)` 展开操作，改用安全的迭代交集或引入 `nesbot/carbon` + 区间计算库处理时间重叠逻辑。
### 🛠 后续重构与优化方向
- **引入策略模式 (Strategy Pattern)**：当前 `book_room_operational_scene` 分支逻辑（KTV/台球/棋牌/酒馆）高度耦合。建议为每个场景创建独立的策略类（如 `KtvBookingStrategy`, `BilliardsBookingStrategy`），通过工厂类动态加载，彻底解耦核心计算逻辑。
- **时间区间值对象化**：将 `start_time`、`end_time`、`status` 封装为 `TimeSlot` 值对象，提供 `overlaps()`, `merge()`, `subtract()` 等方法，替代散落的数组操作。
- **配置加载优化**：`ahead_shop_config_second_model->get_shop_setting` 被多次调用。建议在初始化阶段一次性批量拉取配置，或使用配置缓存层，减少 DB 查询次数。
- **补充边界测试**：重点覆盖跨天营业（如 08:00-次日 02:00）、24小时营业、套餐时长不足、最低预订时长与清扫时间叠加、并发预订冲突等场景。
### 📌 框架适配说明
> 注：当前代码结构、`get_instance()`、`$this->load->model()` 等用法高度符合 **CodeIgniter 3** 规范。若贵司使用的 `phpci` 为 CI3 的定制分支或内部框架，请确认其模型生命周期、缓存驱动及错误处理机制是否与上述建议兼容。若 `phpci` 为全新架构，建议逐步迁移至现代 PHP 依赖注入容器（如 PSR-11）与标准异常处理机制。
*注：由于提供的代码在 `_get_un_book_time` 方法末尾截断，部分后续逻辑（如下一天不可用时间合并、最终结果返回）未能完整审查。建议补充完整文件后再次进行深度复核。*
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780369869
|
1780369869
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
454
|
21
|
167
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `961209555 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `96120955537949907abcd3c939ded9d03fea8ed1`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 11:10:34
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该模型承载了极其复杂的预订时间计算逻辑，涉及多场景、跨天、团购券、清扫时间、最低时长等多重规则交织。代码能实现业务目标，但存在严重的**职责过载、全局状态依赖、静态缓存未隔离、循环内修改数组**等问题。可维护性、健壮性与性能均有较大优化空间。
- **风险等级**：🟠 中高（存在运行时异常隐患、数据串扰风险及性能瓶颈）
> 📌 **框架说明**：根据 `get_instance()`、`$this->load->model()`、`system/` 目录结构判断，该代码实际基于 **CodeIgniter 3** 架构。若 `phpci` 为贵司内部定制框架，请结合其特定生命周期调整以下建议。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_day_time_info()` 循环内 | `foreach ($time_info as $k => &$v)` 中直接使用 `unset($time_info[$k])`。在引用遍历中修改原数组会导致内部指针错乱，可能跳过元素或引发未定义行为。 | 移除循环内的 `unset`，改用 `array_filter` 或在循环结束后统一过滤无效时间段。 | `// 循环结束后统一过滤<br>$time_info = array_filter($time_info, function($v) {<br> return $v['status'] !== '-1';<br>});` |
| 🔴 严重 | 全局静态缓存属性 | `self::$book_days_info`、`self::$shop_data` 等静态属性未做商户/门店隔离。同一 PHP 进程复用该模型实例时，会返回其他商户的缓存数据，导致**严重的数据串扰**。 | 为静态缓存增加复合键（如 `merchant_id_shop_id`），或改为实例属性缓存。 | `self::$book_days_info["{$merchant_id}_{$shop_id}"] ??= $result;` |
| 🟠 警告 | `get_book_day_time_info()` 中段 | `array_intersect(...array_values($all_room_book_time))` 当 `$all_room_book_time` 元素数量 `< 2` 时，PHP 8+ 会抛出 `ArgumentCountError`。 | 增加数组长度判断，安全处理交集计算。 | `$count = count($all_room_book_time);<br>$un_book_time = $count >= 2 ? array_intersect(...array_values($all_room_book_time)) : ($count === 1 ? $all_room_book_time[0] : []);` |
| 🟠 警告 | 多处方法内部 | 频繁重复调用 `$CI = &get_instance();`。违反 DRY 原则，且在 CI3 中多次获取实例会增加微小开销，降低可读性。 | 在构造函数中统一获取并赋值给实例属性，后续统一使用 `$this->ci`。 | `protected $ci;<br>public function __construct() {<br> parent::__construct();<br> $this->ci =& get_instance();<br>}` |
| 🟠 警告 | 全文件 | 大量魔法数字与硬编码状态值（如 `86400`, `3600`, `'1'`, `'-1'`, `'2'`, `'7'`）。可读性差，后期维护极易出错。 | 提取为类常量，明确业务语义。 | `const SECONDS_PER_DAY = 86400;<br>const STATUS_AVAILABLE = '1';<br>const STATUS_UNAVAILABLE = '-1';` |
| 🟡 建议 | `get_book_day_time_info()` | 方法长度超 300 行，混合了数据查询、时间计算、券规则校验、营业时间过滤、状态标记等。严重违反单一职责原则(SRP)。 | 拆分为多个私有方法，如 `calculateAvailableSlots()`, `applyVoucherConstraints()`, `checkBusinessHours()`。 | 将 `foreach` 内的多段 `if` 逻辑抽离为独立方法，主方法仅负责流程编排。 |
| 🟡 建议 | 类属性定义区 | 所有业务属性均为 `public`，破坏封装性，外部可随意篡改内部状态。 | 改为 `protected` 或 `private`，通过 Getter/Setter 或构造参数注入。 | `protected $book_time_limit = 3600;<br>protected $book_days = 7;` |
| 🟡 建议 | 全局函数依赖 | 依赖 `throwError`, `returnWeek`, `timeToHour`, `mergeTimeRanges` 等全局函数。未命名空间化，易产生命名冲突且不利于单元测试。 | 将通用工具函数迁移至 `application/libraries/` 或 `application/helpers/` 并封装为静态类方法。 | `TimeHelper::toHour($time);<br>ArrayHelper::mergeRanges($ranges);` |
## 3. 总结与行动建议
### 🔑 优先修复项（P0/P1）
1. **修复静态缓存串扰**：立即为 `self::$book_days_info`、`self::$shop_data` 等静态属性添加 `merchant_id` 与 `shop_id` 作为缓存键，或改为实例级缓存。否则在多租户/批量处理场景下必现数据错乱。
2. **修复循环内 `unset` 与 `array_intersect` 报错**：替换为安全的数组过滤逻辑，并增加参数数量校验，避免 PHP 8+ 环境直接崩溃。
3. **统一 CI 实例获取**：在 `__construct` 中初始化 `$this->ci`，移除方法内冗余的 `&get_instance()` 调用。
### 🛠 后续重构与优化方向
1. **方法拆分与职责解耦**：`get_book_day_time_info` 是典型的“上帝方法”。建议按业务规则拆分为：
- `fetchBookingData()`：负责查库、解析 JSON、获取前后天数据。
- `calculateTimeWindows()`：负责生成基础时间段数组。
- `applyConstraints()`：负责依次应用营业时间、券规则、清扫时间、最低时长等过滤器。
2. **引入强类型与常量**：利用 PHP 7.4+ 类型声明规范属性，将状态码、时间单位提取为 `const`，提升 IDE 提示与静态分析能力。
3. **性能优化**：
- 前后天预订数据查询可合并为一次 `WHERE IN` 查询，减少 DB 往返。
- 避免在 `foreach` 中重复调用 `strtotime`、`date`，可预先计算基准时间戳。
4. **安全与输入校验**：对 `$params` 中的 `merchant_id`、`shop_id`、`date` 增加类型强转与格式校验（如 `ctype_digit`、`DateTime::createFromFormat`），防止非法输入穿透至底层查询。
> ⚠️ **局限性说明**：您提供的代码在 `get_book_day_time_info()` 方法末尾被截断，未包含完整逻辑与类闭合。若截断部分包含关键的状态提交、事务处理或异常捕获逻辑，请补充完整代码以便进行更精准的闭环审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780369834
|
1780369834
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
453
|
21
|
166
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `a06788a8f ## 自动代码审查报告
**分支**: pay-260616
**提交**: `a06788a8fe4f2bc3ce849b73dd1f28c0be458120`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 10:55:36
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该模型承载了极其复杂的门店预订时间计算逻辑，业务覆盖全面（含跨天、套餐、团购券、清扫时间、包厢锁定等）。但代码存在**严重的静态缓存缺陷**、**实例状态污染**、**时间计算脆弱性**以及**方法过长违反单一职责原则**等问题。整体可维护性与健壮性亟待提升。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_days_info` 方法开头 | **静态缓存未区分参数**：`self::$book_days_info` 作为静态缓存，未考虑 `$merchant_id`、`$shop_id`、`$check_date`、`$add_day` 的差异，会导致不同门店/日期请求返回脏数据。<br>**实例属性污染**：`$this->book_days += 1;` 直接修改类属性，后续调用将基于错误的基础天数计算。 | 1. 移除静态缓存或改用参数哈希作为 Key。<br>2. 禁止在方法内修改 `$this->book_days`，改用局部变量 `$days = $this->book_days + ($add_day ? 1 : 0);`。 | `private static $cache = [];<br>$key = md5(implode('_', func_get_args()));<br>if (isset(self::$cache[$key])) return self::$cache[$key];` |
| 🔴 严重 | `get_book_day_time_info` 中 `array_intersect(...array_values($all_room_book_time))` | **PHP 8+ 兼容性崩溃**：`array_intersect` 至少需要传入两个数组。当 `$room_type_room_ids` 数量为 1 时，解包操作会抛出 `ValueError` 或 `Warning`，导致接口 500。 | 增加数组数量判断，为 1 时直接赋值，大于 1 时才使用解包求交集。 | `if (count($all_room_book_time) === 1) {<br> $un_book_time = reset($all_room_book_time) ?? [];<br>} else {<br> $un_book_time = array_intersect(...array_values($all_room_book_time));<br>}` |
| 🟠 警告 | 全局多处 `strtotime`/`date` 及 `86400` 硬编码 | **跨天时间计算隐患**：大量使用 `+86400`、`-86400` 处理跨天逻辑，未考虑夏令时(DST)、闰秒或时区切换，极易在边界时间（如 23:55-00:05）产生计算偏差。 | 废弃手动秒数偏移，全面改用 `DateTime` 或 `Carbon` 进行时间运算，利用 `modify()` 和 `diff()` 保证准确性。 | `$end = (new DateTime($date))->modify('+1 day')->setTime(0,0);<br>$diff = $start->diff($end)->getTimestamp();` |
| 🟠 警告 | `json_decode($book_time_info['_time_info_new'], 1)` | **未校验 JSON 有效性**：若数据库字段损坏或为空，`json_decode` 返回 `null`，后续 `['room_book_time']` 访问将触发 `TypeError` 或 `Warning`。 | 增加 JSON 解析错误处理，或使用 PHP 7.3+ 的 `JSON_THROW_ON_ERROR` 标志。 | `$data = json_decode($json, true, 512, JSON_THROW_ON_ERROR);<br>// 或兼容写法：<br>$data = json_decode($json, true);<br>if (json_last_error() !== JSON_ERROR_NONE) { $data = []; }` |
| 🟠 警告 | `set_shop_config` / `_get_un_book_time` 中多次调用 `get_shop_setting` | **重复查询性能损耗**：同一方法内多次调用 `get_shop_setting` 获取不同配置，增加数据库/Redis 往返开销。 | 改为批量获取配置，或在模型层引入配置缓存层（如 `get_shop_settings_batch`）。 | `$keys = ['book_minute_unit', 'book_hour_options', 'book_max_days'];<br>$configs = $this->ahead_shop_config_second_model->get_shop_settings_batch($merchant_id, $shop_id, $keys);` |
| 🟡 建议 | 整个文件 | **缺乏类型声明与封装**：大量 `public` 属性暴露内部状态，方法参数无类型提示，违反 PSR-12 及现代 PHP 规范。 | 为属性添加 `private/protected` 修饰符并提供 Getter/Setter；为方法参数和返回值添加 PHP 7.4+ 类型声明。 | `private int $book_time_limit = 3600;<br>public function getBookDaysInfo(int $merchantId, int $shopId, string $checkDate = '', bool $addDay = false): array` |
| 🟡 建议 | 多处硬编码 `'1'`, `'-1'`, `'7'`, `'2'` 等 | **魔法值泛滥**：状态码、场景码、业务规则硬编码在逻辑中，可读性差且极易引发维护错误。 | 提取为类常量或枚举（PHP 8.1+），统一状态管理。 | `const SCENE_KTV = '1';<br>const SCENE_BILLIARDS = '2';<br>const STATUS_AVAILABLE = '1';<br>const STATUS_UNAVAILABLE = '-1';` |
| 🟡 建议 | `get_book_day_time_info` 方法（超 300 行） | **违反单一职责原则 (SRP)**：该方法同时负责：日期校验、营业时间计算、包厢锁定查询、套餐时间过滤、不可用时间合并、状态标记等，圈复杂度过高。 | 拆分为多个私有方法，如 `calculateBusinessHours()`, `mergeUnavailableTimes()`, `applyPackageRules()`, `markTimeSlotStatus()`。 | 见下方重构建议 |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复静态缓存与属性污染**：立即移除 `self::$book_days_info` 的无参缓存逻辑，并将 `$this->book_days += 1` 改为局部变量计算。此问题会导致多租户/多日期请求数据串扰，属于线上高危缺陷。
2. **修复 `array_intersect` 解包崩溃**：在 PHP 8 环境下，单数组解包会直接中断执行。需增加 `count()` 判断分支。
3. **增强 JSON 解析容错**：所有 `json_decode` 调用必须增加 `json_last_error()` 校验或 `try-catch`，防止脏数据引发连锁崩溃。
### 🛠 后续重构与优化方向
1. **时间计算现代化**：全面替换 `strtotime` + `86400` 的原始计算方式。建议引入 `nesbot/carbon` 库，利用 `Carbon::parse()->addHours()->isBetween()` 等语义化 API，彻底解决跨天、夏令时边界问题。
2. **方法拆分与职责收敛**：`get_book_day_time_info` 已演变为“上帝方法”。建议按业务阶段拆分为：
- `resolveBaseTimeSlots()`：生成基础时间段
- `applyBusinessRules()`：应用营业/清扫/最低时长限制
- `applyPackageVoucherRules()`：应用团购券/套餐规则
- `mergeAndMarkStatus()`：合并不可用区间并标记最终状态
3. **依赖注入替代全局获取**：当前大量使用 `$CI = &get_instance()` 和 `$this->load->model()`。若 `phpci` 框架支持 DI 容器，建议通过构造函数注入核心依赖（如 `ConfigService`, `RoomLockService`, `VoucherService`），提升可测试性。
4. **补充单元测试**：该模型逻辑分支极多，强烈建议针对 `get_book_days_info` 和 `_get_un_book_time` 编写 PHPUnit 用例，覆盖：跨天、空数据、单包厢、多包厢交集、套餐时长不足、静态缓存隔离等场景。
> 📌 **框架适配说明**：当前代码大量使用 `get_instance()`、`$this->load->model()` 等典型 **CodeIgniter 3** 模式。若您实际使用的是内部定制版 `phpci` 框架，请确认其是否兼容 CI3 生命周期。若 `phpci` 已转向现代 DI/Service 架构，建议逐步将 `load->` 调用替换为构造函数注入，以符合现代 PHP 框架最佳实践。
>
> ⚠️ **局限性提示**：您提供的代码在 `_get_un_book_time` 方法末尾被截断，未能完整审查该方法的后续逻辑（如次日时间计算、最终返回结构）。建议补充完整代码以便进行闭环审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780368936
|
1780368936
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
452
|
21
|
165
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616 🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616' of https://gitea.g-hi.co...
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `51396af20 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `51396af20d63f5ecaa946dff708621123f051ed2`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 10:53:56
---
## 📋 审查摘要
- **变更文件数**: 5
- **严重问题**: 2
- **高危问题**: 5
- **中危问题**: 3
- **建议优化**: 4
## 🐛 发现的问题
### <font color="red">[语法错误] 模型文件顶部直接执行代码，可能导致致命错误</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: `application/models/Ahead_shop_book_time_info_model.php`
- **行号**: 第 2-3 行
- **问题描述**: 在 PHP 类定义外部直接执行 `$CI = &get_instance();` 和 `$CI->load->model('Simple_model');`。在 CodeIgniter 框架中，模型文件被 `include/require` 时会立即执行顶层代码。如果此时 CI 核心尚未完全初始化，或该文件被自动加载器提前解析，将直接抛出 `Fatal error: Call to undefined function get_instance()` 或加载失败。
- **修复建议**: 移除文件顶层的这两行代码。模型加载应放在类的 `__construct()` 方法中，或通过 CI 的自动加载配置完成。
```php
// 删除顶部这两行：
// $CI = &get_instance();
// $CI->load->model('Simple_model');
// 在 __construct 中按需加载（如果 Simple_model 是基类，直接 extends 即可，无需 load）
public function __construct()
{
parent::__construct();
// 其他初始化逻辑...
}
```
### <font color="red">[跨文件调用] 引用了未定义的基类 Simple_model</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `application/models/Ahead_shop_book_time_info_model.php`
- **行号**: 第 6 行
- **问题描述**: 类声明为 `class Ahead_shop_book_time_info_model extends Simple_model`，但在提供的项目结构及变更文件中均未发现 `Simple_model.php` 或 `Simple_model` 类的定义。若该类不存在，将导致 `Class 'Simple_model' not found` 致命错误。
- **修复建议**: 确认 `application/models/Simple_model.php` 是否存在。若存在，请确保文件路径正确且命名符合 CI 规范；若不存在，请改为继承 CI 核心模型 `CI_Model`。
### <font color="red">[跨文件调用] 调用了多个未定义的全局辅助函数</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `application/models/Ahead_shop_book_time_info_model.php`
- **行号**: 多处（如 `throwError`, `returnWeek`, `timeToHour`, `hourToTime`, `mergeTimeRanges`, `shiftTimeRange`, `minutesToUnits`, `minToStr`, `mintoStr`, `getPrevUnitTime`）
- **问题描述**: 代码中大量使用了自定义全局函数，但提供的项目结构 `system/helpers/` 中并未包含这些函数对应的 Helper 文件。若未正确加载或定义，将触发 `Call to undefined function` 错误。
- **修复建议**:
1. 检查 `application/helpers/` 或 `system/helpers/` 中是否存在包含这些函数的自定义 Helper 文件。
2. 在控制器或自动加载配置中通过 `$this->load->helper('your_custom_helper')` 显式加载。
3. 建议将全局函数重构为静态工具类方法，提高可测试性和命名空间隔离性。
### <font color="red">[跨文件调用] 加载了未定义的 Tuangou 类库</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `application/models/Ahead_shop_book_time_info_model.php`
- **行号**: 第 118 行
- **问题描述**: `$this->load->library('Tuangou');` 尝试加载 `Tuangou` 类库，但项目结构 `system/libraries/` 中不存在该文件。后续代码大量调用 `$this->tuangou->...` 属性与方法，若类库缺失将导致运行时崩溃。
- **修复建议**: 确认 `application/libraries/Tuangou.php` 是否存在。若存在，请检查文件名大小写是否与 CI 加载规则一致（CI3 对大小写敏感）。若不存在，需补充该类库或移除相关调用。
### [逻辑 BUG] 静态缓存与实例属性修改产生状态污染
- **严重程度**: 高危
- **文件**: `application/models/Ahead_shop_book_time_info_model.php`
- **行号**: 第 138-140 行 (`get_book_days_info` 方法)
- **问题描述**: 方法开头使用 `if (!empty(self::$book_days_info)) { return self::$book_days_info; }` 进行静态缓存拦截，但在后续逻辑中执行了 `$this->book_days += 1;`。静态缓存会跳过实例属性的修改，导致多次调用时 `$this->book_days` 状态不一致，且缓存返回的数据可能未包含 `add_day` 逻辑。
- **修复建议**: 移除静态缓存，或改为基于参数（如 `$check_date`, `$add_day`）的缓存键。若需保留实例状态，不应在缓存命中后直接返回。
```php
// 建议改为实例级缓存或移除静态缓存
if (empty($this->_book_days_info_cache)) {
// 计算逻辑...
$this->_book_days_info_cache = $result;
}
return $this->_book_days_info_cache;
```
### [逻辑 BUG] 前端可能触发空指针/类型错误
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 第 68 行
- **问题描述**: `const uid = wx.getStorageSync('userInfo').uid || ''`。若本地存储中 `userInfo` 为 `null`、`undefined` 或非对象类型，直接访问 `.uid` 会抛出 `TypeError: Cannot read properties of null (reading 'uid')`，导致页面白屏。
- **修复建议**: 使用可选链或安全取值。
```javascript
const userInfo = wx.getStorageSync('userInfo') || {};
const uid = userInfo.uid || '';
```
### [安全隐患] 前端 URL 参数拼接未完全过滤
- **严重程度**: 中危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 多处 `wx.navigateTo` URL 拼接
- **问题描述**: 使用字符串拼接构建跳转 URL，如 `url: '/pages/...?order_id=' + this.data.order_id`。虽然部分参数使用了 `encodeURIComponent`，但如 `shop_id`、`room_id` 等未编码。若数据源被恶意注入特殊字符（如 `&`、`#`、`/`），可能破坏路由结构或引发参数覆盖。
- **修复建议**: 统一使用 `encodeURIComponent()` 包裹所有动态参数，或使用小程序官方推荐的 URL 构建工具函数。
### [代码质量] PHP 核心方法过长且嵌套过深
- **严重程度**: 中危
- **文件**: `application/models/Ahead_shop_book_time_info_model.php`
- **行号**: `get_book_day_time_info` 方法（约 150 行以上）
- **问题描述**: 该方法承担了数据查询、时间计算、状态过滤、套餐校验、跨天逻辑等过多职责。嵌套的 `if/else` 和 `foreach` 超过 5 层，圈复杂度过高，极难维护和单元测试。
- **修复建议**: 遵循单一职责原则（SRP），将逻辑拆分为独立私有方法：
- `_calculate_business_hours()`
- `_filter_unavailable_times()`
- `_validate_tuangou_constraints()`
- `_merge_time_ranges()`
## ✅ 代码亮点
1. **前端模型封装规范**：`reserve.js` 采用了清晰的 ES6 Class 继承结构，将 HTTP 请求统一封装，回调处理（success/error/complete）结构一致，便于维护。
2. **参数安全处理意识**：在 `order-detail.js` 中跳转 URL 时，对部分文本参数使用了 `encodeURIComponent`，体现了基础的安全防范意识。
3. **业务逻辑注释详细**：PHP 模型中对 `operational_scene`、`book_model` 等业务枚举值添加了清晰的注释，降低了后续开发者的理解成本。
## 📝 总体建议
1. **严格遵循 CI 框架规范**：PHP 模型文件**绝对禁止**在类外部执行框架核心方法（如 `get_instance()`、`load->model()`）。所有依赖加载必须收敛至 `__construct()` 或具体业务方法内。
2. **完善依赖与辅助函数管理**：当前代码强依赖多个未在结构中体现的类库（`Tuangou`、`Simple_model`）和全局函数。建议建立 `composer.json` 或统一的 `helpers/autoload.php` 进行依赖声明，避免“隐式依赖”导致线上崩溃。
3. **重构超长方法**：`get_book_day_time_info` 是典型的“上帝方法”。建议按“数据获取 -> 规则计算 -> 状态过滤 -> 结果格式化”的流程拆分为 4-5 个独立方法，并补充单元测试覆盖边界条件（如跨天、24小时营业、套餐时长不足等）。
4. **前端防御性编程**：小程序端对 `wx.getStorageSync`、API 返回的 `res.result` 等外部数据必须进行类型校验和空值兜底，避免弱类型语言特性引发的运行时异常。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780368836
|
1780368836
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
451
|
21
|
164
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `473df92ce ## 自动代码审查报告
**分支**: pay-260519
**提交**: `473df92ce3abc56c6dcc8b61b18f91afcca7a540`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 10:14:47
---
## 1. 审查摘要
- **代码质量评分**：4.5 / 10 分
- **总体评价**：该文件承载了核心订单计价与组装逻辑，业务场景复杂。但代码存在**财务精度计算隐患、SQL注入风险、调试代码残留、重复赋值覆盖**等严重问题。方法体极度臃肿，违反单一职责原则，且大量使用魔法数字与不规范命名，可维护性与扩展性较差。
- **风险等级**：🔴 高
> 📌 **框架说明**：代码中 `defined('BASEPATH')`、`get_instance()`、`$this->CI->load->model()` 等特征高度符合 **CodeIgniter 3** 架构规范，与提示中的 `phpci` 框架可能存在差异。以下审查基于 CI3 最佳实践及现代 PHP 标准。代码末尾存在截断（`$result['have_good`），部分逻辑未完全展示，审查基于已提供内容。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | ~第380行 | **生产环境残留调试输出**：`echo $vip_upgrade_data_actual_pay;` 会破坏 HTTP 响应流，导致 JSON/XML 解析失败或前端白屏。 | 立即移除 `echo`，改用框架日志记录。 | `log_message('debug', 'VIP升级计算金额: ' . $vip_upgrade_data_actual_pay);` |
| 🔴 严重 | 全文多处 | **浮点数精度丢失风险**：金额计算直接使用 `* / +`（如 `$goods_actual_pay * $vip_discount_rate`），PHP 浮点运算易产生 `0.0000000001` 误差，财务场景致命。 | 统一使用 `bcmath` 扩展函数，并在累加/返回前严格保留2位小数。 | `$actual_pay = bcadd($actual_pay, $goods_actual_pay, 2);`<br>`$discounted = bcmul($price, $rate, 2);` |
| 🔴 严重 | ~第265行 | **SQL 注入隐患**：`"wares_package._package_id in (" . implode(",", $id_array['package_id']) . ")"` 未对输入做类型强转，恶意构造可注入 SQL。 | 强制转为整型数组，或使用 CI3 查询构造器 `where_in()`。 | `$ids = array_map('intval', $id_array['package_id']);`<br>`$pack_goods_where = "wares_package._package_id IN (" . implode(',', $ids) . ")";` |
| 🟠 警告 | ~第225-227行 | **逻辑覆盖错误**：`$order['_prime_service_charge']` 被连续赋值两次，后者 `$service_charge` 覆盖前者 `$prime_after_paid_service_charge`，导致业务数据错乱。 | 核对业务意图，删除冗余赋值，保留正确变量。 | `$order['_prime_service_charge'] = $prime_after_paid_service_charge;`<br>`// 删除下方重复的 $order['_prime_service_charge'] = $service_charge;` |
| 🟠 警告 | 全文多处 | **重复加载模型**：在循环/分支内频繁调用 `$this->CI->load->model()`，增加不必要的 I/O 与内存开销。 | 统一在 `__construct()` 或方法入口处加载，CI3 模型加载本身具备懒加载特性，无需重复调用。 | `public function __construct() {`<br>` $this->CI =& get_instance();`<br>` $this->CI->load->model(['Ahead_vip_level_model', 'Ahead_merchant_goods_model', 'Ahead_goods_price_rooms_model']);`<br>`}` |
| 🟠 警告 | ~第130行 | **魔法数字泛滥**：`100`, `-1`, `1`, `7`, `9999999999999` 等硬编码散落各处，业务规则变更时极易遗漏。 | 提取为类常量，增强语义与可维护性。 | `private const DISCOUNT_BASE = 100;`<br>`private const STATUS_DISABLED = -1;`<br>`private const MAX_REWARD_AMOUNT = 9999999999999;` |
| 🟡 建议 | 全文 | **违反 PSR-12 规范**：属性命名混用驼峰与下划线（`$supermarketRoomName` vs `$room_id`），方法带 `_` 前缀，大量 `public` 属性暴露内部状态。 | 统一使用驼峰命名，将非接口属性改为 `private/protected`，移除方法名前缀。 | `private $supermarketRoomName = '自助扫码厅';`<br>`private $roomId = 0;`<br>`private function createInsertInfosData(...)` |
| 🟡 建议 | `getOrderTypeInfo` | **方法过长且职责混杂**：单方法超 500 行，混合了商品查询、套餐计算、VIP折扣、服务费、优惠券抵扣、免单逻辑等，违反 SRP。 | 按业务域拆分为独立私有方法或策略类，如 `calculateGoodsPrice()`, `applyVipDiscount()`, `computeServiceCharge()`。 | 使用提取方法重构（Extract Method），保持单方法行数 < 80。 |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题（P0）
1. **立即删除 `echo` 调试语句**，避免线上接口响应污染。
2. **修复 SQL 注入风险**：对所有动态拼接的 `IN` 条件执行 `array_map('intval', $ids)` 过滤。
3. **修正重复赋值逻辑**：确认 `$order['_prime_service_charge']` 的正确业务含义，删除覆盖代码。
4. **引入 `bcmath` 金额计算规范**：所有涉及价格的乘除加减必须使用 `bcmul`/`bcadd`/`bcsub`，并在最终返回前统一 `round($val, 2)`。
### 🛠 后续重构与优化方向
1. **架构拆分（策略模式/职责分离）**：
- 将 `getOrderTypeInfo` 拆分为 `OrderCalculator` 服务类。
- 使用策略模式处理不同订单类型（`case '1'`, `case '2'` 等），避免巨型 `switch`。
- 示例结构：
```php
interface OrderTypeStrategy { public function calculate(array $params): array; }
class GoodsOrderStrategy implements OrderTypeStrategy { ... }
class RoomPackageStrategy implements OrderTypeStrategy { ... }
```
2. **数据校验与异常处理**：
- 使用 CI3 的 `Form_validation` 或自定义 DTO 对 `$id_array`, `$goods_quantity` 进行强类型校验。
- 将 `throwError()` 替换为抛出标准异常（如 `throw new \InvalidArgumentException(...)`），便于全局捕获与日志追踪。
3. **框架规范对齐**：
- 若确为 CI3 环境，建议将模型加载移至 `config/autoload.php` 或构造函数中。
- 数据库查询优先使用 `$this->CI->db->where_in()` 等 Query Builder 方法，彻底杜绝字符串拼接。
4. **代码规范升级**：
- 逐步引入 PHP 7+ 类型声明（如 `public function getOrderTypeInfo(string $type, array $idArray, array $goodsQuantity, int $getActualPay = -1, array &$goodsReward = []): array`）。
- 清理历史注释（如 `//add by nan 22.07.11`），改用 Git 提交记录追溯变更。
> 💡 **提示**：由于代码在末尾被截断，部分订单组装逻辑（如 `have_goods` 字段赋值、最终返回结构）未完整展示。建议在修复上述高危问题后，补充完整代码进行二次审查，并补充单元测试覆盖核心计价分支。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780366487
|
1780366487
|
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
|
|
449
|
21
|
163
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 自助转房
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `cca7cf312 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `cca7cf312430664913047350139e806b3f97f518`
**提交人**: linyangrui (yangruilin888@gmail.com)
**时间**: 2026-06-02 10:12:16
---
## 📋 审查摘要
- **变更文件数**: 4
- **严重问题**: 1
- **高危问题**: 3
- **中危问题**: 3
- **建议优化**: 4
## 🐛 发现的问题
### <font color="red">[跨文件调用] 调用了不存在的 OrderModel 和 CabinetModel 类</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 第 3-4 行
- **问题描述**: 代码中通过 `import {OrderModel} from '../../../models/order.js'` 和 `import {CabinetModel} from '../../../models/cabinet.js'` 引入了两个模型，但在提供的项目结构及变更文件中均未找到这两个文件的定义。若文件实际不存在，将直接导致模块加载失败、页面白屏。
- **修复建议**: 确认 `order.js` 和 `cabinet.js` 是否已存在于 `models/` 目录下。若未创建，需补充对应文件；若已废弃，请移除相关 `import` 及实例化代码。
### <font color="red">[语法错误] 未处理空值导致潜在 TypeError 崩溃</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 第 38 行
- **问题描述**: `const uid = wx.getStorageSync('userInfo').uid || ''` 直接访问了 `userInfo` 的 `uid` 属性。当本地缓存中不存在 `userInfo`（返回 `null` 或 `undefined`）时，会抛出 `TypeError: Cannot read properties of null (reading 'uid')`，导致 `onLoad` 生命周期中断。
- **修复建议**: 使用可选链操作符或安全取值：`const uid = wx.getStorageSync('userInfo')?.uid || ''`
### [安全隐患] URL 参数未编码导致路由解析错误
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 第 118、155、188、205 行等多处
- **问题描述**: 多处 `wx.navigateTo` 拼接路由 URL 时，直接使用字符串拼接动态参数（如 `voucher_name`, `msg`, `shelf_name` 等）。若参数值中包含 `&`、`?`、`#`、`=` 或特殊字符/中文，会导致 URL 参数截断、键值对错位或路由解析失败。
- **修复建议**: 对所有动态参数使用 `encodeURIComponent()` 进行编码。例如：
```javascript
url: `/pages/community-reserve/apply-refund/apply-refund?order_id=${this.data.order_id}&actual_pay=${this.data.order_detail.actual_pay}&voucher_name=${encodeURIComponent(this.data.order_detail.voucher_name)}&voucher_can_refund=${this.data.order_detail.voucher_can_refund}`
```
### [逻辑 BUG] API 响应未做空值防御导致潜在崩溃
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 第 58-60 行、第 135-140 行
- **问题描述**: `getOrderDetail` 和 `handleOpenMachineResult` 方法中直接访问 `res.result.xxx`。若后端接口异常、网络超时或返回格式不符合预期（如 `res` 为 `{code: 500, msg: 'error'}`），`res.result` 将为 `undefined`，后续的属性访问（如 `res.result.refund_time_limit`）会直接抛出 TypeError 导致页面崩溃。
- **修复建议**: 在访问 `res.result` 前增加安全校验，或使用可选链：
```javascript
if (!res || !res.result) {
wx.showToast({ title: '数据加载失败', icon: 'none' });
return;
}
// 或统一使用 res?.result?.xxx
```
### [跨文件调用] 后端接口 URL 存在拼写错误风险
- **严重程度**: 中危
- **文件**: `web/Hi-Zan/Hi-Zan/models/reserve.js`
- **行号**: 第 385 行、第 398 行
- **问题描述**: `getRoomPackgeTimePriceInfo` 和 `openRoomCheckPackageTime` 方法请求的 URL 分别为 `hz/Book/getRoomPackgeTimePriceInfo` 和 `hz/Book/openRoomCheckPakcageTime`。其中 `Packge` 和 `Pakcage` 明显为 `Package` 的拼写错误。若后端路由未做兼容，将直接返回 404。
- **修复建议**: 与后端开发确认接口路径。若确为拼写错误，请统一修正为 `Package`；若后端已按此错误路径发布，建议在代码注释中明确标注“历史遗留拼写，需与后端保持一致”。
### [代码质量] data 对象中存在重复定义的属性
- **严重程度**: 中危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 第 28 行
- **问题描述**: 在 `Page` 的 `data` 对象中，`showCancelBtn: false` 被连续定义了两次。虽然 JavaScript 引擎会以后面的值覆盖前面的值，但这属于冗余代码，容易在后续维护中引发状态覆盖的误解。
- **修复建议**: 删除重复的 `showCancelBtn: false` 定义，保持 `data` 结构清晰。
### [逻辑 BUG] 异常情况下 Loading 状态未正确关闭
- **严重程度**: 中危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 第 55、70 行
- **问题描述**: 在调用 `wx.showLoading()` 后，完全依赖 `reserveModel` 内部封装的 `complete` 回调来执行 `wx.hideLoading()`。若请求在 `complete` 触发前发生同步异常，或 `HTTP` 基类未正确捕获所有错误路径，Loading 遮罩将永久停留在页面上，阻塞用户操作。
- **修复建议**: 建议在发起请求前使用 `try...catch`，或在 `reserve.js` 的 `HTTP` 基类中确保 `fail` 和 `complete` 逻辑能覆盖所有异常分支。也可在页面层增加兜底逻辑。
## ✅ 代码亮点
1. **模块化设计良好**：`reserve.js` 将网络请求高度封装，业务逻辑与数据请求分离，符合 MVVM 架构规范，便于后续维护和单元测试。
2. **状态管理清晰**：`order-detail.js` 的 `data` 对象对弹窗状态（如 `showScanPop`, `showConfirm`, `showChangeRoomPop`）进行了集中管理，配合 `setData` 更新，符合微信小程序最佳实践。
3. **用户体验细节到位**：针对“未清扫开房”、“提前开机”、“碎片时段推荐”等复杂业务场景，提供了完整的交互分支和提示文案，逻辑闭环较为完整。
## 📝 总体建议
1. **强化防御性编程**：小程序端极易受网络波动和后端数据结构变更影响。建议在所有 API 回调入口处统一增加 `if (!res || res.code !== 200) return;` 的校验逻辑，避免空指针异常。
2. **统一路由参数处理**：建议封装一个全局的 `navigateTo` 工具函数，自动对传入的 `query` 对象进行 `encodeURIComponent` 处理，彻底杜绝 URL 拼接带来的安全隐患。
3. **完善错误边界**：当前代码在 `error` 回调中仅做了 `console.log(err)`。建议接入全局错误上报系统（如 Sentry 或自研监控），并在 UI 层给予用户明确的“网络异常/重试”提示，提升产品健壮性。
4. **依赖文件核对**：请重点确认 `models/order.js` 和 `models/cabinet.js` 的实际存在性。跨文件引用是本次审查中最高优先级的风险点，务必在构建/发布前验证。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780366336
|
1780366336
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
448
|
21
|
162
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `b6a3e45d9 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `b6a3e45d9d19643b2f7e246d9fb2b6ff14c40f18`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 10:04:48
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该 Model 承载了复杂的订单查询、账单聚合与状态流转逻辑，业务覆盖全面。但存在明显的 **SQL 注入风险**、**N+1 查询性能瓶颈**、**方法职责过重** 以及 **框架使用不规范** 等问题。硬编码与魔法数字泛滥，可维护性与扩展性较低。
- **风险等级**：🔴 高
> 📌 **框架适配说明**：代码中大量使用 `get_instance()`、`$this->load->model()`、`select()`、`get_one()` 等语法，高度符合 **CodeIgniter 3** 规范。若 `phpci` 为内部定制框架，请确保以下优化建议与框架底层兼容。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_bill_goods_info` (~L285) | **SQL 注入风险**：直接拼接 `$unique_key` 与时间戳到 SQL 字符串中，未做转义或参数绑定。 | 使用框架查询构造器或参数绑定，严禁字符串拼接。 | `$this->db->where('_unique_key', $unique_key)->where_in('_status', [1,4])->where('_timestamp >', time() - 7*86400)->get($this->table_name)->result_array();` |
| 🔴 严重 | `get_list` / `get_detail` (~L115-145, L190-210) | **N+1 查询性能瓶颈**：在 `foreach` 循环中反复 `load->model()` 并执行 `get_one()`，数据量稍大即导致数据库连接耗尽与响应超时。 | 收集所有关联 ID 后使用 `WHERE IN` 批量查询，或在主查询中使用 `JOIN`，再在内存中映射关联数据。 | `$ids = array_column($order_info, 'package_id'); $packages = $this->db->where_in('_id', $ids)->get('ahead_room_package')->result_array(); $map = array_column($packages, null, '_id');` |
| 🔴 严重 | `encode_group_buying_order` (~L435) | **弱加密与密钥硬编码**：使用已淘汰的 `md5()` 生成签名，且加密串直接写在类属性中，易被逆向或碰撞伪造。 | 改用 `hash_hmac('sha256', ...)`，密钥移至配置文件或环境变量。 | `return hash_hmac('sha256', $order_id, config_item('order_sign_key'));` |
| 🟠 警告 | 文件顶部 (~L4-L5) | **框架生命周期违规**：在类外部直接调用 `get_instance()` 并加载模型。文件被 `include` 时即执行，破坏框架单例与自动加载机制。 | 移除顶部代码，将模型加载移至构造函数或按需调用。 | `public function __construct() { parent::__construct(); $this->load->model('Simple_model'); }` |
| 🟠 警告 | `get_bill_goods_info` (~L260-L450) | **上帝方法/逻辑臃肿**：单方法超 300 行，混合了金额计算、商品聚合、退款处理、特殊平台判断，违反单一职责原则。 | 拆分为独立计算类（如 `OrderBillCalculator`），按订单类型提取私有方法处理。 | 创建 `class OrderBillAggregator`，将 `price_total`、`goods_merge` 等逻辑抽离，Model 仅负责数据获取。 |
| 🟠 警告 | 全局多处 | **魔法数字泛滥**：大量直接使用 `1`, `10`, `14` 等数字判断状态/支付方式，虽定义了部分常量但未统一使用。 | 全面替换为类常量，提升可读性与防错能力。 | `if ($order['_pay_platform'] == self::ORDER_AFTER_PAY_PAYPLATFORM) { ... }` |
| 🟡 建议 | `get_bill_goods_info` (~L295) | **调试残留代码**：存在 `if (1) {` 死代码块，影响代码整洁度。 | 移除无用条件判断，保留核心逻辑。 | 直接删除 `if (1) {` 及对应闭合括号。 |
| 🟡 建议 | 类属性定义 (~L15-L45) | **常量与属性重复**：`$pay_platform_arr` 与 `const ORDER_PAY_PLATFORM_ARR` 内容高度重合，且命名风格不统一（下划线 vs 驼峰）。 | 统一使用 `const` 定义映射表，或移至 `config/order.php` 配置文件中。 | `const PAY_PLATFORM_MAP = [1 => '微信支付', 2 => '支付宝', ...];` |
| 🟡 建议 | `confirm_receipt` / `binding_order_check` | **错误处理不规范**：依赖全局函数 `throwError()`，且各方法返回格式不一致（部分返回数组，部分直接中断）。 | 采用标准 `Exception` 或框架统一响应格式，保持接口契约一致。 | `throw new \InvalidArgumentException('订单不存在');` |
## 3. 总结与行动建议
### 🔑 优先修复项（P0/P1）
1. **修复 SQL 注入漏洞**：立即将 `get_bill_goods_info` 中的原始 SQL 拼接替换为查询构造器或参数绑定，这是最高安全风险。
2. **消除 N+1 查询**：重构 `get_list` 与 `get_detail` 中的循环查询逻辑，改为批量查询或 `JOIN`，预计可提升列表接口性能 5~10 倍。
3. **升级签名算法**：废弃 `md5`，采用 `hash_hmac` + 配置化密钥，防止团购核销接口被恶意伪造。
### 🛠 后续重构方向
1. **拆分巨型方法**：`get_bill_goods_info` 已严重超出合理长度。建议引入 **策略模式** 或 **计算服务类**，按 `pay_platform` 和 `type` 拆分账单聚合逻辑，降低圈复杂度。
2. **统一数据契约**：定义统一的 `OrderDTO` 或返回结构，规范 `code/msg/data` 格式，避免前端适配混乱。
3. **配置化管理**：将订单状态、支付方式、场景映射等硬编码数组全部迁移至 `config/` 目录或数据库字典表，便于运营动态调整。
4. **框架规范对齐**：遵循 CI/PHP 最佳实践，模型仅负责数据访问，业务逻辑应下沉至 `Service` 层；构造函数中统一加载依赖模型。
> ⚠️ **局限性说明**：提供的代码在 `get_timing_order` 方法末尾被截断，未能审查完整逻辑。若该方法涉及敏感数据查询或状态更新，请补充完整代码以便进行二次深度审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780365888
|
1780365888
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
447
|
22
|
50
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 1
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `968ac094f ## 自动代码审查报告
**分支**: app-260616
**提交**: `968ac094f22bcb20643193e3370a6e503bce9135`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-02 10:01:39
---
## 1. 审查摘要
- **代码质量评分**：4/10 分
- **总体评价**：该模型类承载了大量核心订单查询、报表统计与分页逻辑，业务覆盖面广。但代码存在**严重的 SQL 注入风险**、**硬编码敏感信息**、**分页逻辑重复造轮子**及**模型职责过重**等问题。整体风格偏向早期 PHP 开发模式，未遵循现代 PSR-12 规范与框架最佳实践，可维护性与安全性亟待提升。
- **风险等级**：🔴 高
> 📌 **框架说明**：根据代码结构（`$CI =& get_instance()`、`$this->load->model()`、`system/` 目录规范等），该代码实际基于 **CodeIgniter 3** 框架。若确为内部定制版 `phpci` 框架，请对照其官方文档调整底层组件调用方式。以下审查基于 CI3 标准及通用 PHP 最佳实践。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 多处（如 `get_order_manage`, `get_consumption_trend_data`, `cjy_get_other_order_info` 等） | **SQL 注入漏洞**：大量使用 `$addsql`、`$shop_ids` 直接拼接 SQL 字符串，未做参数绑定或白名单过滤。攻击者可传入恶意闭合语句执行任意 SQL。 | 1. 废弃字符串拼接，全面改用 CI3 Query Builder (`$this->db->where()`, `where_in()`)。<br>2. 若必须使用原生 SQL，严格使用 `?` 占位符。<br>3. 在 Controller 层对传入参数进行类型强校验。 | `$this->db->where_in('_shop_id', array_map('intval', explode(',', $shop_ids)));`<br>`$this->db->where($validated_addsql_array);` |
| 🔴 严重 | 第 23 行 | **敏感信息硬编码**：加密串 `public $encrypt = "Vs!Fs7VT";` 直接暴露在类属性中，易随代码库泄露或被反编译获取。 | 移至 `application/config/config.php` 或环境变量，通过配置项读取。 | `// config.php<br>$config['order_encrypt_key'] = 'Vs!Fs7VT';`<br>`// Model内<br>$this->config->item('order_encrypt_key');` |
| 🟠 警告 | `get_business` 方法 | **除零异常风险**：`$sum = array_sum(...)` 可能为 `0`，后续 `$tmp['actual_pay'] / $sum` 将触发 `DivisionByZeroError` 或返回 `NaN`。 | 增加安全除法判断，或使用 `bcdiv` 处理浮点精度。 | `if ($sum > 0) { $tmp['percent'] = number_format($tmp['actual_pay'] / $sum, 4) * 100; } else { $tmp['percent'] = 0; }` |
| 🟠 警告 | 文件顶部 & 全局 | **框架生命周期误用**：文件顶部直接调用 `$CI =& get_instance(); $CI->load->model('Simple_model');` 违反 CI 依赖加载规范，易导致内存泄漏或实例冲突。 | 移除全局 `$CI` 调用，在 `__construct()` 中按需加载依赖。 | `public function __construct() { parent::__construct(); $this->load->model('Simple_model'); }` |
| 🟠 警告 | `set_page_info`, `get_page_info`, `cjy_get_page_info` | **重复造轮子（分页逻辑）**：多处手写分页计算，状态判断（`over_page`/`last_page`）不一致，且未利用框架内置组件，维护成本极高。 | 统一使用 CI3 `Pagination` 库，或封装独立 `PaginationService`。 | `$this->load->library('pagination'); $this->pagination->initialize($config); $data['links'] = $this->pagination->create_links();` |
| 🟡 建议 | 全文 | **返回类型不一致**：部分方法返回 `array`，部分返回 `false`，部分返回 `-1`，部分直接返回 `json_encode()` 字符串。增加调用方处理成本。 | 统一返回结构化数组，**JSON 序列化应移至 Controller/View 层**。 | `return ['status' => true, 'data' => $result, 'msg' => ''];` |
| 🟡 建议 | `get_consumption_trend_data` 等 | **日期处理缺乏边界校验**：直接使用 `strtotime()` 转换外部日期，若格式非法将返回 `false`，导致 SQL 语法错误或逻辑异常。 | 增加日期格式校验，或使用 `DateTimeImmutable` 处理。 | `if (!strtotime($start_date)) { throw new InvalidArgumentException('Invalid start_date format'); }` |
| 🟡 建议 | 全文 | **不符合 PSR-12 规范 & 违反单一职责**：方法过长（如 `cjy_get_other_order_info` 超 80 行），变量命名混用下划线与驼峰，注释陈旧。 | 遵循 PSR-12，拆分大方法为独立私有方法，使用 PHP 7.4+ 类型声明。 | `public function getOrderInfo(int $merchantId, string $orderId = ''): array` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即修复 SQL 注入**：全局排查 `$addsql`、`$shop_ids`、`$_order_id` 等外部参数拼接点，替换为 Query Builder 或参数化查询。这是当前最高危的安全漏洞。
2. **移除硬编码密钥**：将 `$encrypt` 迁移至配置文件或环境变量，避免敏感信息随版本控制系统泄露。
3. **统一数据返回格式**：废除模型层直接返回 `json_encode()` 或混合返回 `false/-1` 的做法，统一使用 `['code' => 0, 'data' => [], 'msg' => '']` 结构，由 Controller 层负责序列化。
### 🛠 后续重构与优化方向
1. **模型职责拆分（SRP）**：当前 `Ahead_yc_order_model` 承担了订单查询、报表统计、分页计算、退款调用、权限校验等职责。建议拆分为：
- `OrderRepository`：专注数据查询与构建
- `OrderReportService`：专注统计与聚合逻辑
- `OrderRefundService`：专注支付退款流程
2. **全面拥抱 Query Builder**：逐步替换原生 SQL。CI3 的 Query Builder 已足够应对复杂查询，且能自动防注入、支持缓存、便于单元测试。
3. **性能优化策略**：
- 移除手动 `force index`，通过 `EXPLAIN` 分析慢查询并建立复合索引。
- 报表类查询建议引入读写分离或定时任务预聚合（如 ClickHouse/ES 或 MySQL 汇总表），避免实时 `GROUP BY` 拖垮主库。
- 避免在循环或高频方法中重复调用 `strtotime()` 或 `load->model()`。
4. **代码规范升级**：
- 启用 PHP-CS-Fixer 自动格式化至 PSR-12。
- 为所有公开方法添加 `@param`、`@return` 类型声明，逐步迁移至 PHP 8.1+ 的强类型语法。
- 清理 2016 年遗留注释，改用 PHPDoc 规范。
> ⚠️ **局限性说明**：您提供的代码在 `get_goods_sales` 方法末尾被截断（`$this->ahead_yc_merchant_user_model->get_one(['_id' => $para`）。若该方法涉及复杂联表或动态条件拼接，可能存在与上述相同的注入或逻辑隐患，建议补充完整代码后二次审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780365699
|
1780365699
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
446
|
21
|
161
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `5d1687ffb ## 自动代码审查报告
**分支**: pay-260616
**提交**: `5d1687ffb7e751baa60b13d4a503086d9ee7e658`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 20:03:38
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了较为复杂的包厢预订时间窗口计算逻辑，业务覆盖全面。但存在**严重的状态管理缺陷**（静态缓存未区分参数、实例属性被意外污染）、**方法职责过重**（单方法超 300 行）、**性能隐患**（重复加载模型、数组操作冗余）及**规范缺失**（魔法值硬编码、缺乏类型声明）。整体可维护性与健壮性较低，需重点重构。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_days_info()` 方法开头 | **静态缓存键缺失**：`self::$book_days_info` 未将 `$merchant_id`、`$shop_id`、`$check_date` 等参数纳入缓存键。首次调用后，后续不同商户/门店的请求将直接返回脏数据，导致业务逻辑错乱。 | 使用参数组合生成唯一缓存键，或移除静态缓存改为实例级/Redis缓存。 | `private static $book_days_info = [];`<br>`$cache_key = "{$merchant_id}_{$shop_id}_{$check_date}_{$add_day}";`<br>`if (isset(self::$book_days_info[$cache_key])) return self::$book_days_info[$cache_key];`<br>`// ... 计算逻辑 ...`<br>`return self::$book_days_info[$cache_key] = $result;` |
| 🔴 严重 | `get_book_days_info()` 方法内 | **实例状态污染**：`$this->book_days += 1;` 直接修改了类属性。在 CI 等框架中模型对象常被复用，多次调用 `$add_day=true` 会导致天数无限累加，引发后续时间计算越界。 | 使用局部变量进行计算，严禁在业务方法中直接修改核心配置属性。 | `$calc_days = $this->book_days + ($add_day ? 1 : 0);`<br>`for ($i = 0; $i < $calc_days; $i++) { ... }` |
| 🔴 严重 | `get_book_day_time_info()` 方法内 | **空数组展开致命错误**：`array_intersect(...array_values($all_room_book_time))` 当 `$all_room_book_time` 元素数量 `<2` 时，PHP 8+ 会抛出 `ArgumentCountError` 致命错误。 | 增加元素数量校验，或使用 `array_reduce` 安全求交集。 | `$room_times = array_values($all_room_book_time);`<br>`if (count($room_times) >= 2) {`<br>` $un_book_time = array_intersect(...$room_times);`<br>`} else {`<br>` $un_book_time = $room_times[0] ?? [];`<br>`}` |
| 🟠 警告 | `get_book_day_time_info()` 方法 | **违反单一职责原则**：该方法超 300 行，混合了日期校验、配置加载、时间区间计算、套餐规则校验、状态标记等逻辑。极难单元测试，且后续迭代极易引入回归 Bug。 | 拆分为独立的服务类（如 `BookingTimeCalculator`），按职责分离：数据获取、时间计算、规则校验。 | 提取 `calculateAvailableTimeSlots()`, `validatePackageRules()`, `mergeUnavailableRanges()` 等私有方法或独立类。 |
| 🟠 警告 | 全局多处 | **依赖重复加载与性能损耗**：频繁调用 `$CI = &get_instance();` 及 `$this->load->model()`。在循环或高频请求中会造成不必要的 I/O 开销与内存分配。 | 在 `__construct()` 中统一预加载依赖，或使用依赖注入容器。若 `phpci` 支持，建议通过构造函数注入。 | `public function __construct() {`<br>` parent::__construct();`<br>` $this->load->model(['ahead_shop_config_second_model', 'ahead_family_servers_model', 'ahead_room_discontinue_rule_model']);`<br>`}` |
| 🟠 警告 | 类属性定义区 | **内部状态暴露**：大量计算中间态属性（如 `$book_time_limit_un_book_time`, `$next_un_book_time`）声明为 `public`，易被外部控制器意外覆盖，破坏封装性。 | 改为 `private` 或 `protected`，必要时提供只读 `getter` 方法。 | `private $book_time_limit_un_book_time = [];`<br>`public function getBookTimeLimitUnBookTime(): array { return $this->book_time_limit_un_book_time; }` |
| 🟡 建议 | 全局多处 | **魔法值硬编码**：大量使用 `'1'`, `'-1'`, `'merchantApp'`, `'7'` 等字符串/数字，降低可读性且易出错。 | 使用类常量或 PHP 8.1+ 枚举（Enum）定义业务状态。 | `const STATUS_AVAILABLE = '1';`<br>`const STATUS_UNAVAILABLE = '-1';`<br>`const REQUEST_SOURCE_MERCHANT_APP = 'merchantApp';` |
| 🟡 建议 | `set_shop_config()` 与 `set_room_info()` | **代码重复**：两个方法中场景判断 (`billiards_`, `card_`, `tavern_`) 与配置加载逻辑高度一致。 | 提取私有辅助方法复用逻辑。 | `private function getScenePrefix($scene): string {`<br>` return match($scene) { '2' => 'billiards_', '3' => 'card_', '4' => 'tavern_', default => '' };`<br>`}` |
| 🟡 建议 | 全局方法签名 | **缺乏类型声明**：未使用 PHP 7+ 类型提示，降低 IDE 支持度与静态分析能力。 | 为参数和返回值添加严格类型声明，开启 `declare(strict_types=1);`。 | `public function get_book_days_info(int $merchant_id, int $shop_id, string $check_date = '', bool $add_day = false): array` |
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **修复缓存与状态污染**：立即修正 `self::$book_days_info` 的缓存键逻辑，并将 `$this->book_days += 1` 改为局部变量计算。这两个问题在生产环境中极易引发**数据错乱与越界预订**。
2. **防御性编程**：为 `array_intersect(...)`、`explode('-')`、`json_decode()` 等易崩溃操作增加前置校验与默认值处理，避免线上 Fatal Error。
3. **依赖预加载**：将分散在方法中的 `$this->load->model()` 收敛至构造函数，减少运行时开销。
### 🛠 后续重构与优化方向
1. **架构拆分（SRP 落地）**：将 `get_book_day_time_info` 拆分为 `DataFetcher`（获取门店/包厢/预订数据）、`TimeCalculator`（计算可用/不可用时间窗）、`RuleValidator`（校验套餐/营业/停用规则）。通过组合模式或策略模式注入，提升可测试性。
2. **缓存策略升级**：当前静态缓存仅适用于单次请求。建议引入 Redis 缓存层，以 `book_time:{merchant_id}:{shop_id}:{date}` 为键，设置合理 TTL，避免长连接/CLI 环境下的内存泄漏。
3. **规范与现代化**：
- 全面启用 PHP 8 特性（类型声明、Match 表达式、命名参数）。
- 遵循 PSR-12 规范，统一缩进、空格与注释格式。
- 使用常量/枚举替代魔法值，提升代码自解释能力。
4. **框架适配说明**：代码呈现典型的 CodeIgniter 3 风格（`$CI = &get_instance()`、`$this->load->model()`）。若 `phpci` 为定制框架或已升级至 CI4，建议逐步迁移至**依赖注入（DI）与服务容器**模式，移除全局实例引用，以符合现代 PHP 框架最佳实践。具体组件加载方式请查阅 `phpci` 官方文档。
> 💡 **局限性说明**：本次审查基于提供的单文件代码片段。部分全局函数（如 `throwError`, `mergeTimeRanges`, `timeToHour` 等）及父类 `Simple_model` 的实现未提供，可能影响对完整调用链与异常处理机制的评估。建议补充相关上下文以便进行更精准的静态分析与性能剖析。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780315418
|
1780315418
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
445
|
21
|
160
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `07ec3b591 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `07ec3b59147682933f558d7b84f1de5ec605c784`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 20:03:20
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：代码业务逻辑完整，覆盖了预订、支付回调、退款、消息推送等核心链路，具备较强的工程落地能力。但存在**事务管理不规范、SQL 拼接注入风险、循环内查询（N+1）、魔法数字泛滥**等典型问题。部分支付回调逻辑缺乏安全校验，静态缓存使用方式在特定运行环境下存在隐患。
- **风险等级**：🟠 中高风险（主要源于 SQL 注入隐患、支付回调安全缺失及事务状态机冲突）
> 📌 **框架说明**：根据目录结构（`system/`、`application/models/`）及 `$CI =& get_instance()`、`$this->load->model()` 等特征，判定该项目实际基于 **CodeIgniter 3.x** 框架。以下审查将基于 CI3 最佳实践进行。若实际为其他框架，请补充说明。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`refund_by_notify` 方法 | **SQL 注入风险**：使用字符串拼接构造 `WHERE` 条件与 `UPDATE` 字段（如 `$log_where = '_relation_id="' . $order_data['_id'] . '"...'`），若上游数据未严格过滤，将导致注入。 | 废弃字符串拼接，全面改用 CI 查询构建器（Query Builder）或参数绑定。 | `$this->ahead_pay_log_model->where('_relation_id', $order_data['_id'])<br> ->where('_status', 1)<br> ->where_in('_type', [5, 13])<br> ->update(['_status' => 4, '_refund_amount' => '_actual_pay', ...]);` |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`check_notify` 方法 | **事务状态机冲突**：CI3 的 `trans_start()` 与 `trans_complete()` 为配对设计，内部已自动处理回滚。在 `try` 块中手动调用 `trans_rollback()` 会破坏 CI 事务状态机，可能导致后续 `trans_complete()` 误提交或抛出异常。 | 改用 `trans_begin()` 显式控制，或移除 `try-catch` 中的手动回滚，依赖 `trans_complete()` 自动回滚机制。 | `$this->db->trans_begin();<br>try {<br> // 业务逻辑...<br> if (!$success) { $this->db->trans_rollback(); return [...]; }<br> $this->db->trans_commit();<br>} catch (\Exception $e) {<br> $this->db->trans_rollback();<br> return [...];<br>}` |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`check_notify` 方法 | **支付回调缺乏签名校验**：直接处理 `$order_id` 和 `$transaction_id` 并执行退款/入库，未体现支付平台签名验证逻辑，易受伪造回调攻击导致资损。 | 在方法入口处增加支付网关签名校验，校验失败直接返回并记录日志。 | `if (!$this->verify_pay_sign($this->input->post())) {<br> doLog('支付回调签名验证失败', 'pay_callback');<br> return ['status' => false, 'msg' => '签名错误'];<br>}` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`get_list` 方法 | **N+1 查询性能瓶颈**：在 `foreach` 循环中调用 `$this->ahead_merchant_model->get_one()`，订单量增大时将导致数据库连接数飙升与响应延迟。 | 提取所有 `merchant_id`，使用 `where_in` 批量查询后构建映射数组。 | `$ids = array_column($order_info, 'merchant_id');<br>$merchants = $this->ahead_merchant_model->where_in('_id', $ids)->get()->result_array();<br>$merchant_map = array_column($merchants, '_business_model', '_id');<br>foreach ($order_info as &$v) { $v['business_model'] = $merchant_map[$v['merchant_id']] ?? '1'; }` |
| 🟠 警告 | `Ahead_shop_book_time_info_model.php`<br>全局静态属性 | **静态缓存潜在内存泄漏/脏数据**：大量使用 `self::$shop_data`、`self::$date_room_book_time_info` 等静态属性缓存。在 PHP-FPM 下虽随请求重置，但在 CLI 任务、Swoole/Workerman 长连接或单元测试中极易引发内存溢出或数据串扰。 | 改为实例属性（`private $xxx = []`），或统一使用 CI Cache 驱动（Redis/Memcached）管理。 | `private $shop_data = [];<br>// 在方法中通过 $this->shop_data 读写，避免跨请求污染。` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`send_success_msg` 方法 | **敏感信息日志泄露**：`doLog('支付失败' . json_encode($e->getTrace(), 256), 'book_order')` 会打印完整堆栈，可能暴露服务器路径、数据库结构或内部配置。 | 仅记录异常消息与关键业务标识，堆栈信息应脱敏或仅输出到调试环境。 | `doLog('支付失败: ' . $e->getMessage() . ' | OrderID: ' . ($order_data['_id'] ?? 'unknown'), 'book_order');` |
| 🟡 建议 | 全局 | **魔法数字泛滥**：状态码 `-1, 1, 2, 3, 4, 5`、支付平台 `1, 3, 14`、时间常量 `3600, 86400` 硬编码在业务逻辑中，可读性与可维护性差。 | 提取为类常量或独立配置文件，统一维护。 | `const STATUS_PENDING = -1; const STATUS_PAID = 1; const REFUND_LIMIT_HOURS = 1;` |
| 🟡 建议 | `Ahead_book_order_model.php`<br>文件顶部 | **CI 实例获取位置不当**：`$CI = &get_instance();` 放在类外部，每次 `include` 该文件都会执行一次，违反 CI 生命周期规范且浪费性能。 | 移至构造函数或具体方法内部按需获取。 | `public function __construct() {<br> parent::__construct();<br> $this->ci = &get_instance();<br>}` |
| 🟡 建议 | 全局 | **冗余代码与过时注释**：存在大量注释掉的代码块（如 `send_success_msg` 中的旧版短信逻辑）及带人名的历史注释（`//add by nan 18.1.22`）。 | 使用 Git 管理历史，清理无用注释，保持代码库整洁。 | 直接删除 `/* ... */` 及 `//add by...` 注释块。 |
---
## 3. 总结与行动建议
### 🔑 优先修复项（P0/P1）
1. **修复 SQL 拼接漏洞**：立即将 `refund_by_notify` 中的 `$log_where` 和 `$log_up` 字符串拼接替换为 CI Query Builder 链式调用，彻底阻断注入路径。
2. **规范事务管理**：统一使用 `$this->db->trans_begin()` / `trans_commit()` / `trans_rollback()` 显式控制事务，避免与 CI 自动事务机制冲突导致数据不一致。
3. **补充支付回调验签**：在 `check_notify` 入口增加支付平台签名校验逻辑，确保回调请求来源合法后再执行订单状态变更。
### 🛠 后续重构与优化方向
1. **架构解耦**：当前 Model 承载了过多业务逻辑（支付、退款、短信、微信模板消息、库存扣减）。建议将支付网关交互、消息推送、库存校验抽离至独立的 `Service` 层，Model 仅负责数据持久化。
2. **性能治理**：
- 消除 `get_list` 等方法的循环查询，全面采用批量查询+内存映射。
- `Ahead_shop_book_time_info_model` 中的时间区间计算逻辑极其复杂，建议引入 `DateInterval` 或专业时间处理库（如 `nesbot/carbon`），并将高频计算结果缓存至 Redis。
3. **规范与可维护性**：
- 建立项目级常量文件（如 `application/config/constants.php`）统一管理状态码、支付渠道、时间阈值。
- 统一错误处理机制，避免混用 `return ['status'=>false]` 与 `throwError()`，建议封装统一的 `ApiResponse` 类。
4. **框架适配提示**：若项目计划升级至 CI4 或迁移至现代框架（如 Laravel/Symfony），当前大量依赖 `$CI =& get_instance()` 和全局静态缓存的代码将面临较大重构成本。建议尽早向依赖注入（DI）与实例化设计模式靠拢。
> ⚠️ **局限性说明**：提供的代码片段在 `create_community_shop_book_order` 与 `get_book_day_time_info` 方法末尾被截断，部分边界条件处理、异常捕获及完整事务链路未能全面评估。建议补充完整代码或提供对应方法的上下文以便进行深度复核。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780315401
|
1780315401
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
444
|
21
|
159
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 预订消息新增包厢信息
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `8e299d5dd ## 自动代码审查报告
**分支**: pay-260616
**提交**: `8e299d5ddd437524ee365ab1fc794cbbc5f549a5`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 19:40:30
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：业务逻辑覆盖完整，实现了支付回调、退款、消息通知及订单创建等核心流程。但存在事务控制不规范、N+1 查询性能瓶颈、全局变量滥用、硬编码魔法值及潜在的数据安全风险。部分核心方法（如 `refund_by_notify`）过于臃肿，可维护性与扩展性较弱。
- **风险等级**：🔴 高（涉及资金流转、支付回调与数据库事务，逻辑瑕疵易导致资损、数据不一致或接口阻塞）
> 📌 **框架说明**：根据目录结构、`$CI =& get_instance()`、`$this->load->model()` 等特征，判定项目基于 **CodeIgniter 3.x**（或高度兼容其规范的自研框架 `phpci`）。以下建议均基于 CI3 最佳实践与 PHP 现代编码规范。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`check_notify` 方法 | **事务状态机混乱**：使用 `$this->db->trans_start()` 后，在失败分支手动调用 `$this->db->trans_rollback()` 并直接 `return`，导致 CI 事务状态未正确重置。后续 DB 操作可能脱离事务或引发锁残留。 | 改用 `$this->db->trans_begin()` 配合显式 `trans_commit()`/`trans_rollback()`，或统一使用 `trans_start()` + `trans_complete()` 且不在内部手动回滚。 | ```php<br>$this->db->trans_begin();<br>try {<br> // 业务逻辑<br> if (!$success) {<br> $this->db->trans_rollback();<br> return ['status'=>false];<br> }<br> $this->db->trans_commit();<br>} catch (\Exception $e) {<br> $this->db->trans_rollback();<br> throw $e;<br>}``` |
| 🔴 严重 | `Ahead_yc_notice_model.php`<br>`after_order` 方法 | **未定义变量直接访问**：`$data['_nickname'] = $admin_data['_admin_name'] ?? '';` 中 `$admin_data` 从未定义，将触发 `PHP Warning/Notice`，导致通知内容异常或日志报错。 | 明确 `$admin_data` 来源（如从参数传入或查询数据库），或提供安全的默认值。 | ```php<br>// 假设从调用方传入或查询<br>$admin_data = $this->get_admin_info($order_data['_admin_id'] ?? 0);<br>$data['_nickname'] = $admin_data['_admin_name'] ?? '系统';``` |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`refund_by_notify` 方法 | **SQL 注入与并发覆盖风险**：`$log_where = '_relation_id="' . $order_data['_id'] . '" and _status=1...'` 使用字符串拼接构造条件。若底层 `up()` 未严格转义，存在注入风险；且直接更新状态易在并发退款时产生覆盖。 | 使用 CI Query Builder 或参数化查询；增加乐观锁或状态前置校验。 | ```php<br>$this->db->where('_relation_id', $order_data['_id'])<br> ->where('_status', 1)<br> ->where_in('_type', [5, 13])<br> ->update('pay_log_table', $log_up);``` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`get_list` 方法 | **N+1 查询性能瓶颈**：在 `foreach` 循环中逐条查询商户信息 `$this->ahead_merchant_model->get_one()`，数据量增大时数据库压力呈指数级上升。 | 提取所有 `merchant_id` 后使用 `WHERE IN` 批量查询，或使用 `JOIN` 一次性获取。 | ```php<br>$merchant_ids = array_column($order_info, 'merchant_id');<br>$merchants = $this->ahead_merchant_model->get_batch(['_id' => $merchant_ids], '_id,_business_model');<br>$merchant_map = array_column($merchants, '_business_model', '_id');<br>// 循环中直接 $merchant_map[$v['merchant_id']]``` |
| 🟠 警告 | `Ahead_yc_notice_model.php`<br>`push_notice` 方法 | **同步阻塞第三方请求**：`curlRequest()` 同步调用推送接口，若第三方服务响应慢或超时，将直接拖垮支付回调/下单接口，导致请求堆积。 | 将非核心推送逻辑（微信模板消息、短信、App推送）剥离至消息队列（Redis/RabbitMQ）异步处理。 | ```php<br>// 控制器/模型中<br>$this->load->library('queue');<br>$this->queue->push('push_notice', $notice_data);<br>// 消费者中执行 curlRequest()``` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>全局/多处 | **全局作用域滥用 CI 实例**：文件顶部 `$CI = &get_instance();` 在类外赋值，在 CLI 脚本、单元测试或某些 Swoole 环境下会引发致命错误。 | 遵循 CI 规范，在模型构造函数中获取实例，或优先使用 `$this->ci`。 | ```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>}``` |
| 🟡 建议 | 全局多处 | **魔法数字散落**：状态码 `-1,1,2,3,4,5`、支付平台 `1,3,14`、短信模板 `58,56` 等硬编码遍布逻辑，极易误改且难以维护。 | 提取为类常量或独立配置类，提升可读性与可维护性。 | ```php<br>class Ahead_book_order_model extends Simple_model {<br> const STATUS_PENDING = -1;<br> const STATUS_PAID = 1;<br> const PAY_SCENE_WECHAT = '5';<br> // ...<br>}``` |
| 🟡 建议 | 全局多处 | **日志敏感数据泄露**：`doLog(var_export($input, true) . var_export($res, true))` 打印完整支付请求/响应对象，可能包含商户密钥、用户手机号等敏感信息。 | 仅记录关键字段，或对敏感字段进行脱敏处理。 | ```php<br>doLog('RefundReq: txn_id='.$input->GetTransaction_id().', res_code='.$res['result_code'], 'BookOrderWxRefund');``` |
| 🟡 建议 | 全局多处 | **代码规范与模型加载**：混用 `array()` 与 `[]`；频繁在方法内 `$this->load->model()`。 | 统一使用 `[]` 符合 PSR-12；依赖模型建议在 `__construct()` 中集中加载。 | `// 构造函数中统一加载：<br>$this->load->model(['ahead_book_model', 'ahead_vip_model', ...]);` |
> ⚠️ **局限性说明**：`create_community_shop_book_order` 方法末尾代码被截断（`if ($this->tuangou->verify_token) {` 后缺失），无法完整评估该分支的事务提交、异常处理及返回值逻辑。请补充完整代码以便二次审查。
## 3. 总结与行动建议
### 🔑 优先修复项（P0）
1. **修正事务控制逻辑**：统一使用 `$this->db->trans_begin()` + `trans_commit()`/`trans_rollback()`，确保支付回调与退款流程的原子性，避免资损或脏数据。
2. **修复未定义变量**：立即处理 `Ahead_yc_notice_model::after_order` 中的 `$admin_data` 引用，防止线上 Notice 报错污染日志。
3. **消除 SQL 拼接隐患**：将 `refund_by_notify` 中的字符串条件改为 CI Query Builder 链式调用或参数化查询，杜绝注入风险。
### 🛠 性能与架构优化方向
1. **解决 N+1 查询**：重构 `get_list` 方法，采用批量查询或关联查询，预计可降低 70%+ 的数据库交互次数。
2. **异步化非核心链路**：将微信模板消息、短信发送、日志记录等从主流程剥离，引入消息队列异步消费，提升核心接口（支付回调/下单）的响应速度与吞吐量。
3. **拆分超长方法**：`refund_by_notify` 超过 200 行，职责过重。建议按支付渠道（微信、银联、组合支付）拆分为独立策略类（Strategy Pattern），通过工厂方法路由，符合开闭原则。
### 📐 规范与可维护性提升
1. **常量/枚举化管理**：建立 `OrderStatus`、`PayPlatform`、`SmsTemplate` 等常量类，替换散落各处的魔法数字。
2. **统一 CI 实例获取**：移除文件顶部的全局 `$CI`，改为构造函数注入或按需 `$this->ci =& get_instance()`，提升代码在 CLI/测试环境的兼容性。
3. **类型声明与 PSR-12**：逐步为方法签名添加 PHP 7+ 类型提示（如 `array`, `string`, `int`），统一数组语法为 `[]`，完善 PHPDoc 注释。
> 💡 **后续建议**：若项目计划长期维护，建议引入静态分析工具（如 `PHPStan` 或 `Psalm`）与 CI/CD 自动化代码检查流水线，在合并前拦截低级语法错误与潜在逻辑漏洞。支付与资金相关模块务必补充单元测试（PHPUnit）覆盖核心分支。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780314031
|
1780314031
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
443
|
21
|
158
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 标记清扫时间，可预订
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `31998ab2f ## 自动代码审查报告
**分支**: pay-260616
**提交**: `31998ab2f5cd19ac60553c26f5a43358634419e8`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 19:26:32
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：业务逻辑覆盖较全面（涵盖跨天、套餐、最低时长、清扫时间、停用规则等），但核心方法过于臃肿，存在静态缓存污染风险，且大量混合数据查询、时间计算与状态判定逻辑。代码可维护性与性能有较大优化空间。
- **风险等级**：🟠 中（存在逻辑隐患与性能瓶颈，暂无直接高危安全漏洞）
> 📌 **框架说明**：根据目录结构（`system/`, `application/`）及 `$CI = &get_instance()` 语法，判定该代码基于 **CodeIgniter 3.x** 架构。若 `phpci` 为贵司内部定制框架，请确认以下 CI3 规范是否适用。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_days_info` 开头 | **静态缓存未区分参数**：`if (!empty(self::$book_days_info)) { return self::$book_days_info; }` 会忽略后续传入的 `$check_date` 与 `$add_day`，导致不同请求返回脏数据。 | 将缓存键改为参数组合的哈希值，或移除静态缓存改用实例属性/Redis缓存。 | `private static $book_days_info = [];<br>public function get_book_days_info(...) {<br> $cache_key = md5($merchant_id . '_' . $shop_id . '_' . $check_date . '_' . (int)$add_day);<br> if (isset(self::$book_days_info[$cache_key])) {<br> return self::$book_days_info[$cache_key];<br> }<br> // ... 计算逻辑 ...<br> self::$book_days_info[$cache_key] = $result;<br> return $result;<br>}` |
| 🔴 严重 | `get_book_day_time_info` | **违反单一职责原则**：该方法超 300 行，混合了数据拉取、时间区间计算、套餐规则校验、状态标记与 UI 提示生成。极易引发逻辑冲突与回归 BUG。 | 将时间计算与规则校验剥离至独立的 `BookingTimeCalculatorService`，Model 仅负责数据存取与基础组装。 | *(见第3节重构建议)* |
| 🟠 警告 | 多处方法内 | **频繁调用 `&get_instance()`**：在 `__construct`、`set_shop_config`、`_get_un_book_time` 等位置重复获取 CI 实例，增加开销且不符合 CI 最佳实践。 | 在 `__construct` 中统一获取并赋值给实例属性，后续直接使用 `$this->ci`。 | `protected $ci;<br>public function __construct() {<br> parent::__construct();<br> $this->ci = &get_instance();<br> // ...<br>}` |
| 🟠 警告 | `set_shop_config` & `set_room_info` | **逻辑高度重复**：场景判断 (`billiards_`, `card_`, `tavern_`) 与配置加载代码在两个方法中几乎完全一致。 | 提取为私有方法 `_resolve_shop_config_scene($scene)` 统一调用。 | `private function _resolve_shop_config_scene(string $scene): string {<br> return match($scene) {<br> '2' => 'billiards_',<br> '3' => 'card_',<br> '4' => 'tavern_',<br> default => ''<br> };<br>}` |
| 🟠 警告 | 类属性定义 | **拼写错误**：`$opreational_scene` 存在拼写错误（应为 `operational`），易导致后续维护或前端对接时字段不一致。 | 全局搜索替换为 `$operational_scene`，并在属性声明处添加类型提示。 | `/** @var string 1:ktv, 2:billiards, 3:card, 4:tavern */<br>public string $operational_scene = '1';` |
| 🟡 建议 | 全局 | **大量魔法数字与硬编码**：`86400`, `3600`, `'1'`, `'-1'` 等散落在代码中，降低可读性且易引发状态误判。 | 定义为类常量，如 `const STATUS_AVAILABLE = '1'; const STATUS_UNAVAILABLE = '-1'; const SECONDS_PER_DAY = 86400;` | `const STATUS_AVAILABLE = '1';<br>const STATUS_UNAVAILABLE = '-1';<br>// 替换所有 '1' / '-1' 状态赋值` |
| 🟡 建议 | `get_book_day_time_info` 循环内 | **循环内高频数组操作**：`array_intersect`, `array_merge`, `array_unique`, `sort` 在 `foreach ($time_info)` 中反复执行，时间复杂度偏高。 | 预计算不可用时间区间树（Interval Tree）或使用位图标记；将重复的 `strtotime`/`date` 计算移至循环外。 | *(建议引入 `DatePeriod` 或区间合并算法预处理 `$un_book_time`，循环内仅做 O(1) 范围比对)* |
| 🟡 建议 | 全局 | **缺乏现代 PHP 类型声明**：未使用 PHP 7.4+/8.x 的类型提示，不利于 IDE 静态分析与团队协作。 | 为方法参数、返回值及类属性添加严格类型声明。 | `public function get_book_days_info(int $merchant_id, int $shop_id, string $check_date = '', bool $add_day = false): array` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复静态缓存污染**：立即修改 `get_book_days_info` 的缓存键生成逻辑，否则在多条件并发请求下必现数据错乱。
2. **拆分巨型方法**：`get_book_day_time_info` 已超出合理维护边界。建议按职责拆分为：
- `fetchBookingData()`：负责拉取门店、包厢、历史预订数据。
- `calculateAvailableSlots()`：负责时间区间计算、规则过滤。
- `formatSlotStatus()`：负责最终状态标记与 UI 提示组装。
3. **统一 CI 实例获取**：消除冗余的 `&get_instance()` 调用，提升运行效率与代码整洁度。
### 🛠 后续重构与优化方向
1. **引入服务层（Service Layer）**：将复杂的业务规则（套餐时长校验、跨天逻辑、最低开房时长限制）从 Model 中剥离，放入 `app/services/BookingTimeService.php`。Model 仅保留 `get_one`, `insert`, `update` 等数据操作。
2. **时间计算算法优化**：当前使用 `array_intersect` 判断时间交集，在时间片粒度较细（如 5 分钟）时数组体积庞大。建议改用 **区间重叠算法** 或 **时间轴位图**，将复杂度从 `O(N*M)` 降至 `O(N log N)`。
3. **配置集中化管理**：将 `book_time_limit`, `minute_unit`, `book_days` 等硬编码默认值移至配置文件或数据库配置表，通过 `config()` 函数读取，避免代码级修改。
4. **补充输入校验**：在方法入口处对 `$params` 进行严格校验（如 `ctype_digit`, `preg_match('/^\d{8}$/', $date)`），防止非法参数穿透至底层模型引发 SQL 异常或逻辑崩溃。
5. **代码规范对齐**：使用 `php-cs-fixer` 或 `PHP_CodeSniffer` 配置 PSR-12 规则集进行自动化格式化，补充缺失的 `@throws`、`@return` 注释，并统一错误处理机制（建议统一抛出 `InvalidArgumentException` 或自定义 `BookingException`，替代全局 `throwError`）。
> ⚠️ **局限性说明**：提供的代码在 `get_book_day_time_info` 末尾处截断，未包含完整的方法闭合与后续逻辑。若截断部分包含关键的状态回写或事务处理，请补充完整代码以便进行闭环审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780313192
|
1780313192
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
442
|
21
|
157
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `49815ee06 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `49815ee063afc9e9ce372297e070928d101fe75d`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 19:24:58
---
## 1. 审查摘要
- **代码质量评分**：5/10 分
- **总体评价**：代码承载了复杂的门店预订时间计算与配置读取逻辑，业务覆盖全面。但整体呈现典型的“上帝类/上帝方法”特征，大量业务规则、时间计算、数据查询耦合在单一方法中。存在**实例状态污染**、**静态缓存失效**、**文件级非法代码**等严重缺陷。注：代码实际使用的是 `CodeIgniter 3` 语法架构（如 `$CI = &get_instance()`、`$this->load->model()`），而非 `phpci`，以下审查将基于 CI3 最佳实践与通用 PHP 规范进行。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_shop_book_time_info_model.php` 顶部 | 文件顶部在类定义外直接执行 `$CI = &get_instance();` 和 `$CI->load->model()`。在 PHP/CI3 中，模型文件不应包含类外可执行代码，会导致 Fatal Error 或加载时序异常。 | 移除文件顶部代码，将实例获取与依赖加载移至 `__construct()` 方法内。 | `// 删除顶部代码<br>class Ahead_shop_book_time_info_model extends Simple_model {<br> public function __construct() {<br> parent::__construct();<br> $this->load->model('Simple_model');<br> // ...<br> }<br>}` |
| 🔴 严重 | `get_book_days_info` 方法内 | `$this->book_days += 1;` 直接修改了类的公共属性。若模型实例被复用（CI3 默认单例复用），多次调用会导致天数无限累加，引发严重业务逻辑错误。 | 使用局部变量计算，禁止修改类属性。若需扩展天数，应通过参数传递或返回新数组。 | `$days = $this->book_days + ($add_day ? 1 : 0);<br>for ($i = 0; $i < $days; $i++) { ... }` |
| 🔴 严重 | `get_book_days_info` 方法内 | `self::$book_days_info` 静态缓存未区分 `$add_day` 参数。首次以 `$add_day=true` 调用后，缓存被写入；后续 `$add_day=false` 调用将直接返回错误缓存，导致日期状态错乱。 | 缓存 Key 需包含参数特征，或仅在 `$add_day=false` 时缓存。 | `$cache_key = 'book_days_' . ($add_day ? '1' : '0');<br>if (!empty(self::$book_days_info[$cache_key])) return self::$book_days_info[$cache_key];<br>// ...<br>self::$book_days_info[$cache_key] = $result;` |
| 🟠 警告 | `get_book_day_time_info` 方法 | 方法体超 300 行，混合了 DB 查询、时间区间计算、套餐规则校验、状态标记、数组过滤等。违反单一职责原则，极难单元测试与维护。 | 按职责拆分：1. `fetchBookingData()` 2. `calculateTimeRanges()` 3. `applyVoucherRules()` 4. `formatResponse()`。引入独立的时间计算服务类。 | *(架构级建议，见第3节)* |
| 🟠 警告 | `_get_un_book_time` 方法 | 频繁调用 `get_one()` 查询前一天/后一天数据，且未使用批量查询。在高并发预订场景下易引发 N+1 查询瓶颈。 | 使用 `where_in` 批量查询前后日期数据，或在内存中一次性加载多日缓存。 | `$dates = [$prev_date, $date, $next_date];<br>$this->db->where_in('_date', $dates);<br>$all_data = $this->get();` |
| 🟠 警告 | `Ahead_shop_config_second_model.php` `get_shop_setting` | `switch` 语句超 200 行，大量分支逻辑高度重复（如 KTV/台球/棋牌/酒馆的退款、变更、时长限制）。违反开闭原则，新增场景需修改核心方法。 | 提取配置映射表或使用策略模式。将重复逻辑抽象为 `get_scene_setting($scene_prefix, $field, $default)`。 | `private function get_scene_setting($prefix, $field, $default) {<br> $key = $prefix . $field;<br> return $this->data[$key] ?? $default;<br>}` |
| 🟠 警告 | 全局辅助函数依赖 | 大量使用 `throwError()`, `timeToHour()`, `hourToTime()`, `minToStr()` 等未声明命名空间的全局函数。若环境未加载对应 helper，将直接崩溃。 | 明确引入 `helper('custom_time')`，或封装为 `TimeHelper` 静态类。对关键函数添加 `function_exists()` 防御或依赖注入。 | `if (!function_exists('throwError')) { throw new \RuntimeException('Helper not loaded'); }` |
| 🟡 建议 | 两个模型文件 | 属性全部声明为 `public`，且缺乏类型声明（PHP 7.4+ 支持）。外部可直接篡改 `$book_time_limit`、`$tuangou` 等核心状态，破坏封装性。 | 改为 `protected`/`private`，提供 `get/set` 方法。为属性添加类型提示（如 `public int $book_time_limit = 3600;`）。 | `protected int $book_time_limit = 3600;<br>public function getBookTimeLimit(): int { return $this->book_time_limit; }` |
| 🟡 建议 | `Ahead_shop_config_second_model.php` | `case 'book_trial_time': $result = 0;//$data['book_trial_time'] ?? 0;` 存在注释掉的旧逻辑。`deal_audio_content_params` 中 `$params_map` 末尾有多余分号 `;;`。 | 清理死代码与语法冗余。遵循 PSR-12 规范，移除无用注释。 | `case 'book_trial_time':<br> $result = 0; // 251021版本已废弃<br> break;` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即修复状态污染**：移除 `get_book_days_info` 中的 `$this->book_days += 1;`，改用局部变量。修复静态缓存 Key 未区分参数的问题，防止跨请求数据串扰。
2. **清理非法文件头代码**：将 `Ahead_shop_book_time_info_model.php` 顶部的 `$CI = &get_instance();` 及 `load->model()` 移入构造函数，确保符合 PHP 类加载规范。
3. **防御性编程**：对 `$this->tuangou` 等动态加载的库增加 `if (property_exists($this, 'tuangou'))` 或 `instanceof` 校验，避免未加载时触发 `Call to a member function on null` 致命错误。
### 🛠 后续重构与优化方向
1. **架构拆分（SRP 原则）**：
- 将 `get_book_day_time_info` 拆分为 **数据层**（查询预订记录、门店配置）、**规则层**（时长限制、套餐校验、跨天逻辑）、**表现层**（状态标记、格式化输出）。
- 建议引入 `BookingTimeCalculator` 服务类，专门处理时间区间交集、差集、合并算法（当前大量使用 `array_intersect`/`array_merge` 处理时间字符串，性能与可读性均不佳）。
2. **配置读取优化**：
- `Ahead_shop_config_second_model` 的 `switch` 可重构为配置映射数组。例如：
```php
protected $config_map = [
'book_refund_time_limit' => ['status_field' => 'book_refund_time_limit_status', 'default' => 2],
// ...
];
```
- 利用 CI3 的 `Cache` 驱动（如 Redis/Memcached）缓存门店配置，替代仅存在于请求生命周期的 `static $shop_config`，降低 DB 压力。
3. **安全与规范**：
- 所有外部传入的 `$params` 数组应在入口处进行类型校验与过滤（可使用 CI3 的 `Form_validation` 或自定义 DTO）。
- 统一时间处理：建议全局使用 `DateTimeImmutable` 或统一转换为 Unix 时间戳进行计算，避免 `YmdHi` 字符串比较带来的边界错误（如 `23:59` 与 `00:00` 跨天问题）。
- 若项目确需迁移至 `phpci` 或现代 PHP 框架，建议逐步将 `$CI = &get_instance()` 替换为依赖注入（DI）容器，并启用严格类型模式 `declare(strict_types=1);`。
> 💡 **局限性说明**：本次审查基于提供的两个模型文件。由于时间计算强依赖未提供的全局 Helper（如 `timeToHour`, `mergeTimeRanges`）及 `Tuangou` 库的内部实现，部分边界条件（如跨天套餐时长计算、并发锁机制）的准确性需结合完整上下文进行集成测试验证。建议补充单元测试覆盖核心时间区间算法。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780313098
|
1780313098
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
441
|
21
|
156
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `5d6471809 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `5d64718097ef068b041584656af3d3a783e63391`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 19:17:49
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该模型承载了极其复杂的预订时间计算与状态过滤逻辑，业务覆盖全面，但代码结构严重臃肿。存在明显的状态管理缺陷、硬编码泛滥、方法过长及潜在的性能瓶颈。整体可读性与可维护性较差，需进行系统性重构。
- **风险等级**：🔴 高
## 2. 问题详情
> 注：因原始代码未提供行号，下表以 `方法名/代码块` 定位。代码末尾存在截断，部分逻辑未完整审查。
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_days_info()` 方法内 | `$this->book_days += 1;` 直接修改类属性。若该方法被多次调用，天数会持续累加，导致后续查询范围错误。 | 使用局部变量进行计算，禁止直接修改实例属性。 | `$days = $add_day ? $this->book_days + 1 : $this->book_days;`<br>`for ($i = 0; $i < $days; $i++) { ... }` |
| 🔴 严重 | 全局静态属性 `self::$xxx` | 静态缓存变量（如 `self::$book_days_info`）未设置失效机制。在 PHP-FPM 长连接或 CLI 环境下，会导致脏数据跨请求污染，引发严重业务错乱。 | 增加缓存键隔离（如按商户/日期），或在请求生命周期结束/关键节点提供 `clearStaticCache()` 清理方法。 | `public static function clearCache(): void { self::$book_days_info = []; self::$shop_data = []; ... }` |
| 🔴 严重 | `get_book_day_time_info()` 内 `array_intersect(...)` | `array_intersect(...array_values($all_room_book_time))` 使用展开运算符。若数组为空或仅含1个元素，PHP 8+ 会抛出 `ArgumentCountError`，PHP 7 行为不可控。 | 增加元素数量判断，安全调用。 | `if (count($all_room_book_time) > 1) { $un_book_time = array_intersect(...array_values($all_room_book_time)); }` |
| 🟠 警告 | `get_book_day_time_info()` 方法体 | 方法体超 300 行，嵌套层级深，混合了时间计算、状态过滤、套餐校验、营业时间判断等职责。违反单一职责原则，极易产生边界 Bug。 | 拆分为多个私有方法，如 `calculatePackageAvailability()`, `checkBusinessHoursOverlap()`, `filterUnbookableTimes()`。 | *(见下方重构建议)* |
| 🟠 警告 | 全局多处 | 大量使用魔法字符串/数字（如 `'1'`, `'2'`, `'merchantApp'`, `'-1'`, `'7'`），缺乏语义化，后期维护极易出错。 | 提取为类常量，统一状态与场景枚举。 | `const SCENE_KTV = '1'; const SCENE_BILLIARDS = '2'; const STATUS_AVAILABLE = '1'; const STATUS_UNAVAILABLE = '-1';` |
| 🟠 警告 | 构造函数 & `set_shop_config()` | `$CI = &get_instance();` 被重复调用 4 次以上；模型/库在构造函数和配置方法中重复加载。增加不必要的开销。 | 在构造函数顶部统一获取实例并赋值给 `$this->ci`；利用 CI 的自动加载或懒加载机制。 | `protected $ci; public function __construct() { parent::__construct(); $this->ci =& get_instance(); }` |
| 🟡 建议 | 类属性定义区 | 30+ 个属性全部声明为 `public`，外部可直接篡改内部状态，破坏封装性，且 IDE 无法提供类型提示。 | 改为 `private`/`protected`，按需暴露 `getter/setter`，并补充 PHP 7+ 类型声明。 | `private int $book_room_id = 0; public function getBookRoomId(): int { return $this->book_room_id; }` |
| 🟡 建议 | 时间处理逻辑 | 频繁使用 `date()`、`strtotime()` 进行字符串与时间戳互转，易受服务器时区/DST 影响，且循环内调用性能较差。 | 引入 `DateTime` 对象或 `nesbot/carbon` 库，统一时间计算与格式化。 | `$dt = new DateTime($date); $ts = $dt->getTimestamp();` |
| 🟡 建议 | 输入参数 `$params` | 直接使用 `$params['date']`、`$params['merchant_id']` 等，未做类型校验或空值防御。若上游传入非法值，将导致 `strtotime` 警告或 SQL 异常。 | 在方法入口增加基础校验，或使用 DTO 对象接收参数。 | `if (empty($params['date']) || !preg_match('/^\d{8}$/', $params['date'])) { throwError('日期格式错误'); }` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复状态累加 Bug**：立即将 `get_book_days_info()` 中的 `$this->book_days += 1;` 改为局部变量计算，避免多调用场景下的数据污染。
2. **防御静态缓存泄漏**：为所有 `self::$xxx` 静态属性增加请求级清理机制（如注册 `register_shutdown_function` 或在控制器基类中统一清理），防止 PHP-FPM 环境下的跨请求脏数据。
3. **修复数组展开异常**：对 `array_intersect(...)` 及类似展开操作增加 `count() > 1` 的前置判断，兼容 PHP 7/8 运行环境。
### 🛠 后续重构与优化方向
1. **拆分巨型方法（SRP 原则）**：`get_book_day_time_info()` 承担了数据获取、时间计算、规则过滤、状态标记等 5 种以上职责。建议提取为独立的 `BookingTimeCalculator` 服务类，模型仅负责数据读写。
2. **统一时间处理策略**：废弃散落的 `strtotime`/`date` 字符串操作，封装 `TimeRange` 值对象，使用 `DateTimeImmutable` 进行区间交集/差集计算，彻底解决时区与跨天逻辑隐患。
3. **规范化与类型安全**：
- 遵循 PSR-12 规范，统一缩进、命名与括号风格。
- 全面启用 PHP 7.4+ 类型声明（属性类型、参数类型、返回值类型）。
- 将魔法值替换为 `const` 枚举，提升代码自解释能力。
4. **框架适配说明**：代码结构高度符合 **CodeIgniter 3** 规范（`$CI =& get_instance()`、`system/` 目录、`$this->load->`）。若 `phpci` 为内部定制框架，请核对：
- 是否支持依赖注入（DI）替代 `get_instance()`？
- 模型基类 `Simple_model` 是否已实现查询缓存或防 SQL 注入的预处理机制？
- 建议查阅 `phpci` 官方文档确认生命周期钩子，将静态缓存清理移至框架请求结束阶段。
> ⚠️ **局限性提示**：提供的代码在 `$this->next_date_room_book_time` 赋值处截断，后续可能存在的数据库写入、事务控制或最终返回逻辑未纳入审查。建议补充完整文件后再次进行深度审计。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780312669
|
1780312669
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
440
|
21
|
155
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `db9455197 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `db94551970c84e1423f30ec7f4ae272a73e73a4f`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 18:45:41
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码覆盖了包厢管理、扫码登录、激活注册、智能控制等核心业务，逻辑链路相对完整。但存在明显的架构反模式：模型职责过重（God Object）、频繁重复加载组件、事务控制与异常中断机制不匹配、循环内查询导致 N+1 性能瓶颈。同时存在多处拼写错误、魔法数字硬编码及未声明的全局函数依赖，可维护性与健壮性有待提升。
- **风险等级**：🔴 高（事务回滚隐患、性能雪崩风险、强依赖未定义全局函数）
> 📌 **框架适配说明**：提交代码呈现典型的 **CodeIgniter 3** 架构特征（如 `get_instance()`、`$this->load->model()`、Query Builder 链式调用等）。若实际项目确为 `phpci` 框架，请核对两者在生命周期、组件加载及事务管理上的差异。以下审查基于 CI3 规范与通用 PHP 最佳实践。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `activation_data` (约 230-280 行) | **事务控制与异常中断不匹配**。使用 `trans_begin()` 配合 `try-catch`，但业务校验依赖 `throwError()`。若该函数内部执行 `exit/die` 或 `show_error()`，将直接跳过 `catch` 块，导致事务无法显式回滚，在并发或复杂流程下极易产生脏数据。 | 改用 CI 推荐的自动事务管理 `$this->db->trans_start()` / `$this->db->trans_complete()`，或确保 `throwError()` 抛出 `\Exception`。在 `catch` 中必须显式回滚。 | `$this->db->trans_start();<br>// 业务逻辑...<br>if ($this->db->trans_status() === FALSE) {<br> $this->db->trans_rollback();<br> return ['status'=>false, 'msg'=>'系统繁忙'];<br>}<br>$this->db->trans_commit();` |
| 🔴 严重 | 全文件多处 (`scan_screen_url`, `activation_data` 等) | **强依赖未声明的全局函数**。如 `throwError()`, `get_mac_by_url()`, `aliOssTurnCdn()`, `hourToTime()` 等。若这些函数未正确加载或内部直接终止脚本，将导致流程中断、内存泄漏或安全绕过。 | 将全局函数收敛至 Helper 或 Service 类，通过 `$this->load->helper()` 或依赖注入规范引入。对核心函数补充类型声明与单元测试。 | `// 替换前<br>throwError("参数错误");<br>// 替换后<br>$this->load->helper('common');<br>throw_error('参数错误', 400);` |
| 🟠 警告 | `get_community_shop_room_show_list` (约 550-600 行) | **N+1 查询性能瓶颈**。在 `foreach ($room_data as $k => &$v)` 循环中调用 `get_now_price()` 和 `get_lowest_price()`。若门店包厢数 >50，将触发数十次独立 DB 查询，严重拖慢接口响应。 | 将价格查询逻辑下沉至模型层，使用 `WHERE IN` 批量获取，或在应用层构建内存映射表。 | `$room_ids = array_column($room_data, 'room_id');<br>$price_map = $this->ahead_room_timing_model->get_batch_prices($merchant_id, $shop_id, $room_ids, $date);<br>// 循环内直接读取 $price_map[$v['room_id']]` |
| 🟠 警告 | 全文件多处 (`update_room_status`, `scan_screen_url` 等) | **重复加载模型/库**。在多个方法内部频繁调用 `$this->load->model()` 和 `$this->load->library()`。CI 框架虽会缓存实例，但重复调用仍消耗 CPU 解析开销，且破坏代码可读性。 | 将高频依赖的模型/库统一移至 `__construct()` 中加载，或配置 `config/autoload.php`。 | `public function __construct() {<br> parent::__construct();<br> $this->load->model(['Ahead_shop_model', 'Ahead_open_room_log_model', 'Ahead_switch_control_model']);<br>}` |
| 🟠 警告 | `close_power`, `open_power`, `check_room_consume` | **魔法数字与硬编码错误码**。大量使用 `1`, `2`, `3`, `2333`, `4403`, `4404` 等字面量，缺乏语义化，后期维护极易混淆或误改。 | 定义类常量或枚举（PHP 8.1+）集中管理状态与错误码。 | `const STATUS_CONSUMING = 1;<br>const STATUS_FREE = 0;<br>const ERR_PARAM_MISSING = 4403;` |
| 🟡 建议 | 全文件 | **拼写错误与命名不规范**。如 `contorl_data` (应为 `control_data`)、`fileds` (应为 `fields`)、`Ahead_famaily_version_model` (应为 `family`)。数组语法 `array()` 与 `[]` 混用，未遵循 PSR-12。 | 全局检索修正拼写错误。统一使用短数组语法 `[]`。遵循 PSR-12 缩进、命名与注释规范。 | `protected $control_data = [];`<br>`protected $fields = '';` |
| 🟡 建议 | `scan_screen_url` (约 120-200 行) | **单一职责原则（SRP）违背**。该方法混合了二维码解析、房态判断、好友关系更新、埋点统计、页面路由分发等 5+ 个职责，代码超 100 行，难以测试与复用。 | 拆分为独立的私有方法或提取至 `RoomScanService` 类。主方法仅负责流程编排。 | `private function handleRoomScanLogic($param, $uid) { ... }`<br>`private function updateFriendRelation($uid, $openData) { ... }` |
| 🟡 建议 | `get_list_by_ids` | **非标准 Query Builder 用法**。`$where['where_in'] = array("_id", $ids);` 依赖自定义 `select` 方法兼容。若底层未处理，将导致 SQL 语法错误或注入风险。 | 使用 CI 标准链式调用，确保类型安全。 | `$this->db->where_in('_id', (array)$ids);<br>$res = $this->db->get($this->table_name)->result_array();` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **事务一致性保障**：立即将 `activation_data` 等涉及多表写入的方法改为 `$this->db->trans_start()` / `$trans_complete()` 模式，或确保所有中断点均抛出 `\Exception`，杜绝脏数据风险。
2. **消除 N+1 查询**：重构 `get_community_shop_room_show_list` 中的价格获取逻辑，采用批量查询（`WHERE IN`）+ 内存映射，预计可将接口耗时降低 60% 以上。
3. **全局函数治理**：梳理 `throwError`、`get_mac_by_url` 等全局函数的定义位置与行为，统一封装为 Helper 或 Service，避免隐式依赖与不可控的脚本终止。
### 🛠 后续重构与优化方向
- **架构分层**：当前 Model 承担了过多业务逻辑（扫码、激活、开关电、预订计算）。建议引入 `Service` 层处理复杂业务流程，Model 仅保留数据访问与基础校验，Controller 负责参数接收与响应组装。
- **输入校验与类型安全**：在方法入口补充参数类型声明（PHP 7.4+ 支持属性类型提示）与基础校验（如 `filter_var`、`ctype_digit`），避免非法数据穿透至 DB 层。
- **配置与常量集中化**：将房态枚举、错误码、业务开关（如 `intelligent_control`）抽离至 `config/room_constants.php`，提升多环境部署与后期迭代的灵活性。
- **代码规范自动化**：接入 `PHP_CodeSniffer` (PSR-12) 与 `PHPStan` 静态分析工具，在 CI/CD 流水线中拦截拼写错误、未定义变量与类型不匹配问题。
> ⚠️ **局限性说明**：提供的代码片段在 `get_community_shop_room_show_list` 方法末尾截断，未能完整审查该方法后续逻辑及类末尾结构。建议补充完整文件后再次进行深度审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780310742
|
1780310742
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
439
|
21
|
154
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `1548e48b4 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `1548e48b428bbaff5484712a4c296b313bf4c25b`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 18:43:20
---
## 1. 审查摘要
- **代码质量评分**：4.5 / 10 分
- **总体评价**：代码整体呈现“测试调试接口与生产业务逻辑混杂”的状态。`TestHlj.php` 存在大量硬编码、越权风险及不规范的输出控制；`Book.php` 业务逻辑相对完整但存在冗余与框架误用；`Ahead_family_servers_model.php` 数据库操作基本规范，但存在潜在 SQL 语法错误与循环内查询隐患。整体可维护性、安全性与框架适配度亟待提升。
- **风险等级**：🔴 高（若未做环境隔离直接部署，将导致严重越权、数据泄露及 SQL 报错）
> 📌 **框架说明**：代码实际基于 **CodeIgniter 3.x** 架构开发（特征：`BASEPATH`、`$this->load->`、`get_instance()`）。若 `phpci` 为贵司内部定制框架，请对照官方文档调整组件调用方式。以下建议基于 CI3 最佳实践。
> ⚠️ **局限性提示**：`TestHlj.php` 与 `Ahead_family_servers_model.php` 文件末尾被截断，部分深层逻辑未完全展示，审查仅基于可见代码。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `TestHlj.php` 多处 | **缺乏鉴权与越权风险**：硬编码 `uid=66`、`merchant_id=1281`，且未校验请求身份。若部署至生产环境，攻击者可伪造参数直接操作任意商户数据。 | 1. 移除硬编码，统一从 Session/Token 解析用户身份。<br>2. 测试控制器应通过 `ENVIRONMENT` 限制访问，或添加 IP/Token 白名单。 | `if (ENVIRONMENT !== 'development') { show_error('接口已关闭'); }`<br>`$this->uid = $this->session->userdata('uid') ?? 0;` |
| 🔴 严重 | `Ahead_family_servers_model.php` `getMerchantShopByFamily` | **SQL 语法错误隐患**：`$field` 字符串末尾存在多余逗号 `shop._logo_url as shop_img, '`，直接传入 `$this->db->select()` 会生成非法 SQL 导致查询失败。 | 移除字段定义末尾的逗号，或使用 CI 数组格式传参。 | `$field = 'servers._family_server_id as family_server_id, ..., shop._logo_url as shop_img';` |
| 🟠 警告 | `TestHlj.php` `jsonEcho` | **输出缓冲控制混乱**：连续调用 `ob_end_clean()` → `ob_start()` → `ob_end_flush()` → `flush()` → `die()`，易引发 `Headers already sent` 或重复输出，且绕过 CI 生命周期。 | 移除冗余 OB 操作，直接使用 CI 输出类或标准 `exit()`。 | `$this->output->set_status_header($code)<br> ->set_content_type('application/json')<br> ->set_output(json_encode($result, JSON_UNESCAPED_UNICODE))<br> ->_display(); exit;` |
| 🟠 警告 | `TestHlj.php` `getCommunityShopBookHours` | **敏感数据硬编码与性能浪费**：方法内直接粘贴超长 JSON 字符串（含 `verify_token` 等敏感信息），每次请求均执行 `json_decode`，浪费内存且易泄露凭证。 | 将测试数据移至 `application/config/test_data.php` 或独立 JSON 文件，按需加载。 | `$voucher_info = $this->config->item('test_voucher_info');`<br>`$data = json_decode($voucher_info, true);` |
| 🟠 警告 | `TestHlj.php` / `Book.php` 多处 | **未使用 CI 输入过滤**：直接使用 `$_GET`、`$_REQUEST`、`php://input` 获取参数，未启用 XSS 过滤与类型校验，存在注入风险。 | 统一使用 `$this->input->get('key', true)` 或 `$this->input->post()`，关键参数配合 `form_validation`。 | `$order_id = $this->input->get('order_id', true);`<br>`if (!ctype_digit($order_id)) { $this->error_response('订单号格式错误'); }` |
| 🟠 警告 | `TestHlj.php` `updateShopShiftTurnoverCount` | **服务端逻辑依赖浏览器环境**：使用 JS `window.location.href` 实现分页/循环处理，无法兼容 CLI 定时任务或 API 调用。 | 改为服务端游标/分页逻辑，返回 JSON 状态供前端轮询或 CLI 脚本处理。 | `return $this->success_response(['next_url' => site_url('TestHlj/updateShopShiftTurnoverCount?last_id='.$res['last_id'])]);` |
| 🟡 建议 | `Book.php` `__construct` 及多处 | **重复的场景映射逻辑**：多次出现 `if ($operational_scene == '2') { $shop_config_scene = 'billiards_'; } ...`，违反 DRY 原则。 | 提取为私有方法或使用配置数组映射。 | `private function getShopConfigScene($scene) { return ['2'=>'billiards_', '3'=>'card_', '4'=>'tavern_'][$scene] ?? ''; }` |
| 🟡 建议 | `Ahead_family_servers_model.php` `get_community_shop_room_show_list` | **潜在 N+1 查询**：`foreach ($room_data as $k => &$v)` 内部多次调用模型方法（如 `get_now_price`、`get_package_list_in_time`），数据量大时性能骤降。 | 提前批量查询价格/套餐数据，或使用静态缓存/Redis 缓存热点数据。 | `$room_ids = array_column($room_data, 'room_id');`<br>`$prices = $this->ahead_room_timing_model->get_batch_price($room_ids, $book_time);` |
| 🟡 建议 | 全局 | **代码规范与魔法数字**：类名 `TestHlj`、方法名 `niubilityTest` 不符合 PSR-12；大量 `'1'`、`'2'`、`66` 等魔法数字散落，降低可读性。 | 1. 统一驼峰命名，移除不雅命名。<br>2. 提取业务常量/枚举。<br>3. 补充标准 PHPDoc。 | `const SCENE_KTV = '1'; const SCENE_BILLIARDS = '2';`<br>`const TEST_UID = 66;` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **安全隔离**：立即将 `TestHlj.php` 标记为调试专用，通过 `ENVIRONMENT` 或 `.htaccess` 限制公网访问。移除所有硬编码的 `uid`、`merchant_id` 及敏感 Token。
2. **修复 SQL 语法**：修正 `Ahead_family_servers_model::getMerchantShopByFamily` 中 `$field` 字符串末尾的逗号，避免线上 500 错误。
3. **规范输入输出**：全面替换 `$_GET`/`$_REQUEST` 为 `$this->input->get()`，重构 `jsonEcho` 使用 CI 原生输出机制，避免缓冲区污染。
### 🛠 后续重构与优化方向
- **架构分层**：将测试/调试接口与生产业务接口物理分离（如 `application/controllers/debug/` 与 `application/controllers/api/`）。生产控制器应继承统一的 `BaseController` 处理鉴权、参数过滤、统一响应格式。
- **框架适配优化**：
- 避免在控制器中 `include FCPATH...` 加载 Library，统一使用 `$this->load->library()`。
- 避免直接操作 `$CI->property`，改用 `$this->config->set_item()` 或 Session 传递上下文。
- 事务处理建议结合 `try-catch` 与 `$this->db->trans_start()`，确保异常时自动回滚。
- **性能提升**：
- 对高频查询的包厢状态、价格、套餐数据引入 Redis 缓存（TTL 5~10分钟）。
- 批量操作使用 `where_in` 替代循环单条查询，减少 DB 连接开销。
- **规范落地**：引入 `PHP_CodeSniffer` 配置 PSR-12 规则，配合 CI/CD 流水线进行静态扫描；建立业务常量字典，逐步替换魔法数字。
> 💡 **提示**：若需对截断部分（如 `TestHlj::get_room_info` 及 Model 末尾循环）进行深度审查，请提供完整代码片段。当前建议已覆盖可见代码的核心风险点，按优先级修复后可显著提升系统稳定性与安全性。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780310600
|
1780310600
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
438
|
21
|
153
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `a4715b3e4 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `a4715b3e4dca441726b9b4a85548ee4e09643643`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 18:39:34
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码整体实现了核心业务流转，但存在明显的**测试代码与生产逻辑混杂**、**参数处理不规范**、**事务与响应机制偏离框架最佳实践**等问题。部分方法直接暴露敏感测试接口，且缺乏统一的安全校验与性能优化设计，技术债务较重。
- **风险等级**：🔴 高（存在硬编码凭证、未过滤的输入源、事务状态不一致风险及潜在的性能瓶颈）
> 📌 **框架说明**：提交代码的语法特征（`BASEPATH`、`get_instance()`、`$this->load->model()`、`$this->db->trans_begin()` 等）高度符合 **CodeIgniter 3** 架构规范。本次审查将基于 CI3 最佳实践进行，若 `phpci` 为内部定制分支，请结合其官方文档微调适配建议。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `TestHlj.php` 多处 | 生产控制器中混入大量调试接口（如 `niubilityTest`、`jhGiftTest`、`pushTest`），且硬编码敏感数据（`uid=66`、完整团购券 JSON、固定商户 ID）。若误部署将导致越权测试、数据污染或凭证泄露。 | 1. 将测试代码剥离至独立 `DebugController` 或 CLI 脚本，并强制添加 IP 白名单/Token 鉴权。<br>2. 移除所有硬编码业务值，改为从配置或动态请求中获取。 | `// 移除或添加鉴权中间件<br>if (!in_array($_SERVER['REMOTE_ADDR'], ['127.0.0.1'])) exit('Forbidden');` |
| 🔴 严重 | `TestHlj.php` / `Book.php` | 直接使用 `$_GET`、`$_REQUEST` 获取参数并透传至 Model，缺乏类型校验与安全过滤。虽 CI3 Query Builder 会转义，但逻辑层未做边界检查，易引发越权或异常崩溃。 | 在基类或方法入口处统一进行参数清洗与类型强转，关键 ID 使用 `intval()`，字符串使用 `trim()`，必要时引入 `form_validation`。 | `$order_id = isset($_GET['order_id']) ? intval($_GET['order_id']) : 0;` |
| 🔴 严重 | `Ahead_family_servers_model.php` `activation_data()` | 混用 `trans_begin()` 与 `try-catch` 手动回滚/提交，未使用 CI3 推荐的 `trans_start()`/`trans_complete()` 自动事务管理机制，异常分支易导致事务悬挂或连接池泄漏。 | 统一改用 CI3 标准事务写法，利用 `trans_complete()` 自动判断执行状态。 | `$this->db->trans_start();<br>try { /* 业务逻辑 */ } catch(\Exception $e) { $this->db->trans_rollback(); throw $e; }<br>$this->db->trans_complete();` |
| 🟠 警告 | `TestHlj.php` `jsonEcho()` | 使用 `ob_end_clean(); ob_start(); ... ob_end_flush(); flush(); die();` 强制控制输出缓冲，破坏框架生命周期，且 `flush()` 在部分 SAPI（如 PHP-FPM）下无效，易引发 Headers 冲突。 | 使用 CI3 标准输出组件，移除冗余缓冲操作，交由框架统一处理响应头。 | `$this->output->set_content_type('application/json')<br> ->set_output(json_encode($result, JSON_UNESCAPED_UNICODE))<br> ->_display(); exit;` |
| 🟠 警告 | `Ahead_family_servers_model.php` `get_community_shop_room_show_list()` | `foreach` 循环内频繁调用模型方法（如 `get_now_price`、`get_shop_setting`、`get_package_list_in_time`），极易引发 **N+1 查询** 与 Redis 重复连接，导致高并发下响应超时。 | 提前批量查询所需数据（价格、配置、套餐），在循环外构建 `[$room_id => $data]` 映射数组，循环内仅做数据组装。 | `// 循环外批量获取<br>$prices = $this->ahead_room_timing_model->get_batch_price($all_room_id_arr, $date);<br>foreach ($room_data as &$v) { $v['price'] = $prices[$v['room_id']] ?? 0; }` |
| 🟠 警告 | `TestHlj.php` / `Book.php` | 参数属性命名不一致（`$this->params` vs `$this->param`），且未声明属性直接赋值，在严格模式下会触发 `Undefined property` 警告，增加维护成本。 | 在父类控制器中统一定义并初始化参数容器，子类仅做读取或覆盖。 | `// BaseController.php<br>protected $param = [];<br>public function __construct() { $this->param = $this->input->get_post(); }` |
| 🟡 建议 | 全局多处 | 大量使用魔法数字与字符串（如 `66`、`2333`、`'1'`、`'2'`、`'xxxx'`），业务语义不清晰，后续修改易遗漏。 | 提取为类常量或独立配置文件（如 `config/booking_constants.php`），使用枚举或语义化命名。 | `const STATUS_SUCCESS = 0;<br>const STATUS_ERROR = 2333;<br>const DEFAULT_UID = 66;` |
| 🟡 建议 | `TestHlj.php` `updateShopShiftTurnoverCount()` | 使用 JS `window.location.href` 实现服务端循环批处理，强依赖客户端环境，易被拦截或中断，且无法记录服务端执行日志。 | 改为异步任务队列（如 Redis Queue + Supervisor/Cron）或 CLI 脚本执行长耗时批处理。 | `// CLI: php index.php cli batch update_shift_turnover --merchant_id=1` |
> ⚠️ **局限性说明**：`Ahead_family_servers_model.php` 代码在末尾被截断，未能完整审查 `get_community_shop_room_show_list()` 后续逻辑及类尾部结构。若存在未闭合的 `foreach` 或事务块，请补充完整代码以便二次评估。
---
## 3. 总结与行动建议
### 🚨 优先修复项（P0）
1. **清理测试与调试代码**：立即将 `TestHlj.php` 中的 `niubilityTest`、`jhGiftTest`、`pushTest`、`unsetSessionTest` 等接口移出生产环境，或添加严格的 IP/Token 鉴权中间件。
2. **统一参数校验机制**：禁止直接透传 `$_GET`/`$_REQUEST`。建议在基类控制器中封装 `validateParams()` 方法，对 `merchant_id`、`shop_id`、`order_id` 等关键参数进行类型强转与范围校验。
3. **修复事务处理规范**：将 `activation_data()` 及其他涉及多表写入的方法统一改为 `$this->db->trans_start()` + `$this->db->trans_complete()` 模式，避免手动 `trans_begin/commit/rollback` 导致的状态不一致。
### 🛠 后续重构方向
1. **响应层标准化**：废弃 `jsonEcho()` 中的 `ob_*` 操作，统一使用基类提供的 `success_response()` / `error_response()` 返回数组，由框架自动序列化并设置 `Content-Type`。
2. **性能优化（N+1 治理）**：针对 `get_community_shop_room_show_list()` 等列表接口，采用 `WHERE IN` 批量查询替代循环内单条查询。对高频读取的配置项（如门店设置、包厢状态）引入 Redis 缓存，设置合理 TTL。
3. **常量与配置抽离**：建立 `config/constants.php` 或 `config/booking.php`，集中管理业务状态码、场景标识（KTV/台球/棋牌）、默认值等。消除魔法数字，提升代码可读性与可维护性。
4. **安全加固**：
- 对涉及金额、订单状态变更的接口增加 **幂等性校验**（如基于 `order_id` + `token` 的 Redis 锁）。
- 敏感操作（如退款、开房、关房）记录操作日志，并校验当前用户权限与订单归属关系，防止水平越权。
如需针对特定方法（如 `activation_data` 事务重构或 `get_community_shop_room_show_list` 批量查询优化）提供完整可替换代码片段，可提供完整文件内容，我将为您输出精准的重构方案。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780310374
|
1780310374
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
437
|
21
|
152
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 切换支付方式时更新页面优惠券列表
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `f32131c65 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `f32131c65de891d3fc755a6e9511b716d7eec12d`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 18:07:49
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了较为完整的小程序首页、包厢预订、订单支付等核心业务链路，但存在明显的架构耦合、安全漏洞与逻辑隐患。大量硬编码、全局实例属性污染、未严格校验的输入参数以及原始 SQL 拼接降低了系统的可维护性与安全性。整体处于“能跑但脆弱”的状态，亟需安全加固与规范化重构。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_yc_order_model.php`<br>`get_bill_goods_info` 方法内 | **SQL 注入漏洞**：使用字符串拼接构造查询条件 `$sql = '_unique_key="' . $unique_key . '" ...'`，若 `$unique_key` 未严格过滤，将导致数据库被恶意查询或篡改。 | 废弃手动拼接 SQL，全面改用 CI Query Builder 或预处理语句。 | `$this->db->where('_unique_key', $unique_key)->where_in('_status', [1,4])->get($this->table_name)->result_array();` |
| 🔴 严重 | `Index.php`<br>`getRoomInfo` 方法 | **逻辑分支未终止**：`if (empty($open_room_log))` 块内调用 `$this->success_response()` 后未 `return` 或 `exit`。若响应函数未中断脚本，后续代码将尝试访问空数组键值导致 `Fatal Error`。 | 在条件分支末尾显式添加 `return;`，确保控制流正确终止。 | `if (empty($open_room_log)) { ... $this->success_response(); return; }` |
| 🔴 严重 | `Index.php`<br>`__construct` 方法 | **横向越权风险 (IDOR)**：直接信任客户端传入的 `$this->param['spe_merchant_id']` 并赋值给核心业务变量，未校验当前用户是否有权访问该商家数据。 | 增加权限校验中间件或模型层校验，确保 `spe_merchant_id` 与当前登录用户/会话绑定。 | `if (!$this->auth->check_merchant_access($this->spe_merchant_id)) { throwError('无权访问该商家'); }` |
| 🟠 警告 | `Index.php`<br>`getConfig` 方法 | **重复加载模型**：构造函数已加载 `ahead_merchant_wx_min_set_model`，方法内再次 `$this->load->model()` 造成冗余调用（虽 CI 会缓存，但违背规范）。 | 移除方法内的重复加载，直接使用构造函数已加载的实例。 | 删除 `$this->load->model('Ahead_merchant_wx_min_set_model');` |
| 🟠 警告 | `Ahead_billiards_model.php`<br>`check_room` 方法 | **全局实例属性污染**：直接修改 `$CI->merchant_id`、`$CI->operational_scene` 等全局属性，破坏封装性，易引发并发请求下的状态串扰。 | 将状态数据封装至 Model 自身属性或通过方法参数/返回值传递，避免污染 CI 超全局实例。 | `private $merchant_id; private $operational_scene; // 使用 $this->merchant_id 替代 $CI->xxx` |
| 🟠 警告 | `Ahead_shop_book_time_info_model.php`<br>多处静态属性 | **静态缓存生命周期风险**：大量使用 `self::$book_days_info`、`self::$shop_data` 等静态变量缓存数据。在 PHP-FPM 长连接或 CLI 模式下可能导致跨请求脏数据，且难以清理。 | 改用 CI 内置缓存组件 `$this->cache->save()` 或实例属性，并在请求结束时重置。 | `if (empty($this->cache->get('book_days_'.$merchant_id))) { ... $this->cache->save(...); }` |
| 🟡 建议 | 全局多处 | **魔法数字/硬编码泛滥**：大量使用 `'-1'`、`'1'`、`'2'`、`33424` 等字面量，业务含义不透明，后期维护成本极高。 | 提取为类常量或独立配置类，统一命名管理。 | `class OrderStatus { const PENDING = -1; const PAID = 1; }` |
| 🟡 建议 | `Index.php` / `Ahead_billiards_model.php` | **命名规范不一致**：方法名混用驼峰 (`getRoomInfo`)、下划线 (`get_room_info`) 及自定义前缀 (`public_getIndex`)，不符合 PSR-12。 | 统一采用驼峰命名法，路由前缀建议通过路由配置文件处理，而非硬编码在方法名中。 | `public function getIndex()`, `public function getRoomInfo()` |
| 🟡 建议 | 全局 | **框架适配说明**：代码特征（`get_instance()`, `$this->load->model()`, `BASEPATH`）高度符合 **CodeIgniter 3** 架构。若 `phpci` 为内部定制框架或笔误，请确认其生命周期与 CI3 是否一致。 | 建议查阅 `phpci` 官方文档确认模型加载、路由解析及请求生命周期差异，必要时适配对应框架的依赖注入容器。 | 无 |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即修复 SQL 注入**：替换 `Ahead_yc_order_model.php` 中所有手动拼接的 `$sql` 字符串，全面启用 CI Query Builder (`$this->db->where()`, `$this->db->select()`) 或 PDO 预处理。
2. **阻断逻辑穿透**：在 `Index.php::getRoomInfo` 的空结果判断块末尾补充 `return;`，防止空指针异常。
3. **实施商家权限校验**：在控制器层或中间件层增加 `spe_merchant_id` 的归属权校验，严禁直接信任前端传入的商户标识。
### 🛠 后续重构与优化方向
1. **解耦全局状态**：将 `Ahead_billiards_model` 中对 `$CI` 实例属性的直接读写改为依赖注入或方法参数传递。Model 应保持无状态或仅维护自身实例属性，提升单元测试可行性。
2. **统一配置与常量管理**：建立 `config/constants.php` 或独立 `Enum` 类，集中管理订单状态、支付场景、运营场景等魔法值。例如：`const SCENE_KTV = '1'; const SCENE_BILLIARDS = '2';`。
3. **规范模型加载与缓存策略**：
- 将频繁使用的 Model 移至控制器 `__construct` 中加载。
- 替换 `self::$` 静态缓存为 CI 原生缓存驱动（Redis/Memcached/File），并设置合理的 TTL，避免内存泄漏或脏读。
4. **强化输入验证层**：在控制器入口统一使用 CI 的 `form_validation` 或自定义 `RequestValidator` 对 `$this->param` 进行类型转换、范围校验与 XSS 过滤，避免业务代码中散落 `intval()`、`empty()` 判断。
5. **框架适配确认**：若项目确为 `phpci` 框架，请核对其是否兼容 CI3 的 `load` 机制。若为自研框架，建议逐步迁移至现代 PHP 架构（如 PSR-4 自动加载、依赖注入容器、中间件管道），以提升长期可维护性。
> 💡 **提示**：本次审查基于提供的代码片段。若涉及核心支付、用户鉴权或高并发预订场景，建议补充单元测试覆盖率，并引入静态分析工具（如 PHPStan / Psalm）进行自动化质量门禁。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780308469
|
1780308469
|
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
|
|
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
|
|
434
|
21
|
151
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `458a39729 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `458a3972979ee6f5c5f24a92d7fa12a2688dc780`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 17:32:08
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该 Model 承载了订单查询、详情组装、账单计算、状态流转等核心业务，功能覆盖全面。但存在明显的架构设计问题：方法职责过重（如 `get_bill_goods_info` 超 300 行）、循环内重复加载模型、硬编码魔法数字泛滥、缺乏事务控制与安全签名机制。代码整体可维护性较低，存在数据不一致与潜在注入风险。
- **风险等级**：🔴 高
- **⚠️ 局限性说明**：代码在 `get_timing_order()` 方法末尾被截断（`return ['success' => false, 'msg' => '订单`），无法对该方法及后续逻辑进行完整评估。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_detail()` ~L150 | **变量赋值错误/数据丢失**：`$order_data['before_payment']` 赋值给了未定义的 `$order_data` 数组，且未合并至最终返回的 `$data['order_info']` 中，导致转房前金额无法展示。 | 修正目标数组为 `$order_info`，并确保在返回前正确赋值。 | `$order_info['before_payment'] = $before_order_info_data['_actual_pay'] ?? '';` |
| 🔴 严重 | `get_bill_goods_info()` ~L200 | **SQL 注入隐患**：使用字符串拼接构建 `$sql` 条件（`'_unique_key="' . $unique_key . '"...'`），若底层 `select()` 未做严格转义，将直接暴露注入风险。 | 废弃字符串拼接，改用框架查询构建器或参数化数组条件。 | `$where['_unique_key'] = $unique_key; $where['_timestamp >'] = time() - 7 * 86400;` |
| 🟠 警告 | `confirm_receipt()` ~L250 | **缺乏事务控制**：连续插入状态 `7` 和 `8` 两条流程记录。若第二条插入失败，第一条已落库，导致订单状态不一致。 | 使用数据库事务包裹连续写入操作，失败时自动回滚。 | `$this->db->trans_start(); /* 两次 insert */ $this->db->trans_complete();` |
| 🟠 警告 | `get_list()` / `get_detail()` 多处 | **循环内加载模型**：在 `foreach` 中频繁调用 `$this->load->model()`，CI 框架会重复解析与实例化，造成严重性能损耗。 | 将模型加载统一移至方法开头或类的 `__construct()` 中。 | `$this->load->model(['ahead_room_package_model', 'ahead_wares_package_model']);` |
| 🟠 警告 | 类属性 `$encrypt` | **硬编码敏感密钥**：`public $encrypt = "Vs!Fs7VT";` 直接暴露在源码中，易随版本库泄露，违反安全基线。 | 移至配置文件或环境变量，通过配置项读取。 | `protected $encrypt; public function __construct(){ $this->encrypt = config_item('order_sign_key'); }` |
| 🟠 警告 | `encode_group_buying_order()` | **弱签名算法**：使用 `md5()` 进行订单签名验证，易受彩虹表与碰撞攻击，不符合现代安全规范。 | 改用 `hash_hmac` 或框架内置加密组件，并使用 `hash_equals` 防时序攻击。 | `return hash_equals(hash_hmac('sha256', $order_id, $this->encrypt), $sign);` |
| 🟡 建议 | 全局/多处 | **魔法数字泛滥**：大量使用 `1, 2, 9, 10` 等硬编码数字判断业务类型，虽已定义常量但未统一替换，可读性差。 | 全面替换为已定义的 `self::CONST_NAME`，提升语义化与后期维护效率。 | `if ($order_info['pay_platform'] == self::ORDER_EXCHANGE_PAYPLATFORM)` |
| 🟡 建议 | `get_bill_goods_info()` | **严重违反单一职责原则**：超 300 行，混合了数据查询、金额聚合、商品合并、格式化展示等逻辑，难以测试与扩展。 | 拆分为独立私有方法（如 `calculateBillTotals()`, `mergeGoodsList()`, `formatGoodsDisplay()`）。 | 主方法仅负责流程编排，具体计算逻辑下沉至独立方法。 |
| 🟡 建议 | `binding_order_check()` | **隐式依赖未定义属性**：直接使用 `$this->uid` 但未在类中声明或初始化，依赖外部隐式上下文，易引发 `Undefined property` 警告。 | 明确通过参数传入 `$uid`，或从 Session/父类安全获取。 | `public function binding_order_check($order_id, $sign, $uid = null)` |
| 🟡 建议 | 类定义顶部 | **破坏封装的实例化**：`$CI = &get_instance();` 放在类外部，违反面向对象设计原则，且 CI 推荐在类内部按需获取。 | 移除顶部全局代码，在需要时使用 `$this->ci =& get_instance();` 或依赖注入。 | 删除顶部 `$CI = &get_instance();` 及 `$CI->load->model()` 调用。 |
| 🟡 建议 | 常量定义区 | **拼写错误与命名不一致**：`ORDRE_WARES_TPE` 拼写错误；`ORDER_CASH_PAYPLATFORM` 缺少下划线分隔；部分使用 `array()` 部分使用 `[]`。 | 修正拼写，统一使用 `[]` 语法，遵循 PSR-12 常量命名规范。 | `const ORDER_WARES_TYPE = 2;` |
---
## 3. 总结与行动建议
### 🚨 优先修复项（P0/P1）
1. **修复数据丢失 Bug**：立即修正 `get_detail()` 中 `$order_data` 误赋值问题，确保转房前金额正确返回。
2. **消除 SQL 拼接风险**：将 `get_bill_goods_info()` 中的 `$sql` 字符串替换为框架安全的数组条件或 Query Builder 链式调用。
3. **引入事务机制**：为 `confirm_receipt()` 及涉及多表写入的操作添加 `trans_start()/trans_complete()` 事务控制，保障数据一致性。
4. **密钥与签名升级**：将 `$encrypt` 移至配置中心，并将 `md5` 签名升级为 `HMAC-SHA256`，防止伪造订单请求。
### 🛠 后续重构与优化方向
1. **拆分巨型方法**：`get_bill_goods_info()` 建议按职责拆分为：
- `fetchBillOrders()`：负责查询与过滤
- `aggregateBillAmounts()`：负责金额计算与汇总
- `mergeAndFormatGoods()`：负责商品去重、合并与展示格式化
2. **统一常量与魔法值治理**：建立全局订单状态/支付类型枚举类（或集中常量文件），全面替换硬编码数字。修复 `ORDRE_WARES_TPE` 等拼写错误。
3. **模型加载优化**：遵循 CI 规范，将频繁使用的关联 Model 在 `__construct()` 中预加载，或使用自动加载配置，杜绝循环内 `load->model()`。
4. **框架适配说明**：注：根据目录结构（`system/helpers/`, `application/models/`）及语法特征（`$this->load->model()`, `get_instance()`），该代码高度符合 **CodeIgniter 3.x** 规范。若 `phpci` 为内部定制框架，请确保 `Simple_model` 的 `select()`/`get_one()` 底层已实现参数化查询，否则上述 SQL 注入风险需由框架层兜底。建议查阅 `phpci` 官方文档确认查询构建器的安全实现方式。
> 💡 **审查提示**：代码整体业务逻辑复杂度高，建议在重构前补充单元测试（尤其是账单计算与状态流转逻辑），并引入静态分析工具（如 PHPStan / Psalm）进行类型与边界条件校验。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780306328
|
1780306328
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
433
|
22
|
47
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 1
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `d902d4fde ## 自动代码审查报告
**分支**: app-260616
**提交**: `d902d4fdef9704aefae650e66d50f6945216c525`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 17:28:47
---
## 1. 审查摘要
- **代码质量评分**：4/10 分
- **总体评价**：代码实现了订单查询、报表统计、退款等核心业务，但存在严重的架构与安全缺陷。大量使用字符串拼接 SQL、模型职责过重、混合原始 SQL 与 Query Builder、敏感信息硬编码。部分 SQL 语法错误将直接导致运行时崩溃，整体可维护性与安全性较低。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 全局多处 (`$addsql` 拼接) | **SQL 注入漏洞**：`$addsql` 参数直接拼接入 SQL 字符串。若该参数由前端或外部接口传入，攻击者可构造恶意条件绕过权限或拖库。 | 彻底废弃 `$addsql` 拼接模式。统一使用 CI3 Query Builder 或参数化查询 (`$this->db->query($sql, $params)`)。将动态条件转为数组传入。 | `$this->db->where($conditions)->get('ahead_yc_order');` |
| 🔴 严重 | `get_new_add_people_trend_data` | **SQL 语法错误/崩溃**：子查询 `NOT IN (select DISTINCT(_ahead_user_id))` 缺失表名，执行必报 `SQLSTATE[42000]` 错误。 | 补全子查询表名，或改用 `LEFT JOIN` + `IS NULL` 提升性能。 | `... AND _ahead_user_id NOT IN (SELECT _ahead_user_id FROM ahead_user WHERE _merchant_id = ?)` |
| 🔴 严重 | `refund()` | **超额退款/资损风险**：未校验 `$refund_amount` 是否合法（如负数、大于实付金额 `_actual_pay`），直接调用支付网关退款。 | 增加金额边界校验，确保退款金额在合理区间内，并记录操作日志。 | `if ($refund_amount <= 0 || $refund_amount > $order_info['_actual_pay']) { return ['status'=>false, 'msg'=>'退款金额无效']; }` |
| 🟠 警告 | `get_consumption_trend_data` 等 | **模型层越权序列化**：在 Model 中直接调用 `json_encode()` 返回数据，破坏 MVC 分层，导致 Controller 无法二次处理或统一格式化。 | Model 仅返回原生数组/对象。序列化、格式化逻辑移至 Controller 或 Service 层。 | 移除 `json_encode()`，直接 `return $this->db->query(...)->result_array();` |
| 🟠 警告 | 类属性 `$encrypt` | **敏感信息硬编码**：加密串 `"Vs!Fs7VT"` 直接暴露在类属性中，违反安全基线，易随代码库泄露。 | 移至 `application/config/config.php` 或环境变量，通过 `$this->config->item()` 读取。 | `protected $encrypt_key; public function __construct() { parent::__construct(); $this->encrypt_key = $this->config->item('order_encrypt_key'); }` |
| 🟠 警告 | `cjy_get_other_order_info` | **不安全的转义处理**：使用 `addslashes()` 防御注入已过时且不可靠，且正则校验后仍手动拼接 SQL。 | 使用 CI3 内置的 `$this->db->like()` 或参数绑定，移除 `addslashes()`。 | `$this->db->like('_id', $_order_id, 'after');` |
| 🟠 警告 | `get_order_manage_by_page` | **强制索引滥用**：硬编码 `force index(_merchant_id)` 可能在数据分布变化后导致查询计划劣化，且未处理索引不存在的情况。 | 移除硬编码 `force index`，依赖数据库优化器。通过 `EXPLAIN` 验证实际执行计划，必要时在 DBA 层面优化复合索引。 | 删除 `force index` 片段，确保 `_merchant_id, _timestamp` 已建立联合索引。 |
| 🟡 建议 | 全局 | **违反 PSR-12 与单一职责**：命名混乱（`$_merchant_id` vs `$merchantId`），模型承担查询、报表、退款、分页等多重职责，文件过长。 | 拆分模型（如 `OrderQueryModel`, `OrderReportModel`, `RefundService`），统一使用 `camelCase`，移除 `// echo $this->db->last_query();` 等调试注释。 | 提取公共分页逻辑至 `BaseModel`，统一参数命名规范。 |
| 🟡 建议 | 文件头部 | **冗余的实例化调用**：`$CI =& get_instance(); $CI->load->model('Simple_model');` 在 CI 模型中无需手动加载，且父类应在 `extends` 时自动解析。 | 移除头部冗余代码，依赖框架自动加载机制。 | 直接 `class Ahead_yc_order_model extends Simple_model { ... }` |
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **阻断 SQL 注入路径**：立即审查所有传入 `$addsql` 的调用链，确保其来源绝对可信。短期内可使用 `$this->db->escape_str()` 过滤，中长期必须重构为 Query Builder 或预处理参数数组。
2. **修复致命 SQL 语法错误**：修正 `get_new_add_people_trend_data` 中缺失表名的子查询，避免线上 500 错误。
3. **增加退款金额校验**：在 `refund()` 方法入口增加 `0 < $refund_amount <= _actual_pay` 校验，防止资损。
### 🛠 后续重构与优化方向
1. **架构分层与职责拆分**：当前模型严重违反单一职责原则（SRP）。建议按业务域拆分为：
- `OrderRepository`：负责基础 CRUD 与复杂查询
- `OrderReportService`：负责数据魔方、营收统计等聚合逻辑
- `RefundService`：封装退款网关调用、状态机与日志记录
2. **统一数据访问层 (DAL)**：全面迁移至 CI3 Query Builder。避免原始 SQL 与 Builder 混用，提升可读性与可维护性。对于极复杂的报表 SQL，建议移至数据库视图 (View) 或存储过程，并在 PHP 层仅做参数绑定。
3. **性能优化策略**：
- 移除 Model 层的 `json_encode()`，减少内存开销。
- 针对高频查询（如 `_merchant_id`, `_shop_id`, `_timestamp`）建立复合索引。
- 对统计类接口引入 Redis 缓存（如 `Cache::remember()`），设置合理的 TTL。
4. **规范与安全基线**：
- 严格遵循 PSR-12，统一变量命名、方法命名与注释规范。
- 敏感配置（加密串、支付密钥、DB 切换标识）全部外置至 `config/` 或 `.env`。
- 清理所有 `// echo $this->db->last_query();` 及历史注释。
> 📌 **注**：您提供的代码在末尾处被截断（`$this->ahead_yc_merchant_user_model->get_one(['_id' => $para`），本次审查基于已提供内容。若需完整评估，请补充完整代码。此外，代码语法特征高度符合 **CodeIgniter 3** 规范，若实际运行环境为其他框架（如 phpci/Laravel），请同步调整数据库组件调用方式。建议查阅对应框架官方文档中的 `Query Builder` 与 `Security` 章节进行适配。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780306127
|
1780306127
|
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
|
|
431
|
21
|
150
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `63f723481 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `63f7234819a09ce60e0220fa5c8a5ac2e2cf619a`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 17:23:21
---
## 1. 审查摘要
- **代码质量评分**：4/10 分
- **总体评价**：该文件是一个典型的“上帝 Helper”，承载了短信、微信、OSS、Redis、WebSocket、打印机路由、日志、时间转换等大量异构业务逻辑。代码存在**严重的安全隐患**（硬编码密钥、SQL 拼接注入、关闭 SSL 验证）、**现代 PHP 兼容性问题**（使用已废弃的 `create_function`）、**性能瓶颈**（重复建连、低效去重算法）以及**架构反模式**（Helper 中重度耦合 CI 超对象与数据库操作）。整体可维护性与扩展性较差，亟需重构。
- **风险等级**：🔴 高
> 📌 **框架适配说明**：根据代码特征（`defined('BASEPATH')`、`&get_instance()`、`system/helpers/` 目录结构等），该代码实际基于 **CodeIgniter 3 (CI3)** 架构。若 `phpci` 为贵司内部定制框架，请参照其官方文档对组件加载与生命周期进行对齐。以下审查基于 CI3 最佳实践与 PHP 7.4+ 标准。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `decodeUnicode` 函数 | 使用了 PHP 7.2 已废弃、8.0 已移除的 `create_function`，会导致生产环境 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);` |
| 🔴 严重 | `alioss_addObject` | **硬编码云厂商 AccessKey/Secret**，极易泄露至版本库，造成数据被恶意篡改或盗刷。 | 移至 `config/oss.php` 或环境变量，通过 `$CI->config->item()` 读取。 | `'accessId' => config_item('oss_access_id'), 'accessKey' => config_item('oss_access_key')` |
| 🔴 严重 | `get_printer` | 多处使用字符串拼接构建 `$where` 条件（如 `'_shop_id= ' . $shop_id`），未做转义，存在 **SQL 注入风险**。 | 全面改用 CI3 Query Builder 或 `$this->db->escape()`。 | `$this->db->where('_shop_id', $shop_id)->where('_status', 1)->where("FIND_IN_SET(?, _checkstand_id)", $checkstand_id)` |
| 🔴 严重 | `curlRequest` | 强制关闭 SSL 证书验证 (`CURLOPT_SSL_VERIFYPEER = false`)，易受中间人攻击 (MITM)。 | 生产环境必须开启验证，或配置可信 CA 证书路径。 | `curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, true); curl_setopt($curl, CURLOPT_CAINFO, '/path/to/cacert.pem');` |
| 🟠 警告 | `generate_code` | 使用 `rand()` 生成验证码，非密码学安全，易被预测或碰撞。 | PHP 7+ 应使用 `random_int()`。 | `return random_int(pow(10, $length - 1), pow(10, $length) - 1);` |
| 🟠 警告 | `get_aliyun_redis_conn` | 每次调用均 `new Redis()` 并执行 `connect/auth`，无连接复用机制，高并发下极易耗尽文件描述符或触发 Redis 连接数限制。 | 使用单例模式或 CI3 Redis 驱动，启用 `persistent` 连接。 | `static $redis; if(!$redis){ $redis = new Redis(); $redis->pconnect(...); } return $redis;` |
| 🟠 警告 | `unique_rand_OutTradeNo` | `while` 循环内反复调用 `array_flip` 去重，时间复杂度 $O(N^2)$，生成量大时严重拖慢性能。 | 使用 `array_keys` 结合 `do-while` 或 `array_unique`。 | `do { $return[] = createOutTradeNo(...); } while(count(array_unique($return)) < $num);` |
| 🟠 警告 | `timeToHour` / `hourToTime` | 依赖硬编码时间戳 `1483200000` (2017-01-01)，跨年份或时区切换时会产生严重逻辑偏差。 | 使用 `DateTime` 对象处理相对时间，或基于当日 `00:00:00` 动态计算基准。 | `$base = strtotime(date('Y-m-d')); return date("H:i", $base + $time);` |
| 🟡 建议 | 全局 | **严重违反单一职责原则 (SRP)**。Helper 文件应仅包含无状态、轻量级工具函数。当前文件耦合了 DB、网络、缓存、第三方 API，难以测试与维护。 | 拆分为独立 Service/Library：`SmsService`、`WechatService`、`PrinterRouter`、`WebSocketManager` 等。 | 遵循 CI3 规范，将业务逻辑移至 `application/libraries/` 或 `application/services/`。 |
| 🟡 建议 | `showErrorView` | 重定向 URL 拼写错误 `eeror.php`，且直接拼接 `$_SERVER['SERVER_NAME']` 未做白名单校验。 | 修正拼写，使用 CI3 的 `site_url()` 或 `base_url()` 生成安全链接。 | `redirect('pay/web/error.php?title=' . urlencode($title) . '&error_msg=' . urlencode($error_msg));` |
| 🟡 建议 | 全局 | 命名风格混乱（`doLog` vs `do_log`、`showErrorVies` 注释拼写错误），且大量函数未声明返回值类型与参数类型。 | 统一遵循 PSR-12 规范，补充 PHPDoc 类型声明，统一错误返回结构（如 `['code'=>0, 'msg'=>'', 'data'=>[]]`）。 | `function do_log(string $text, string $dirname, string $filename = ''): void { ... }` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题（P0/P1）
1. **立即移除硬编码凭证**：将 OSS、微信、短信等所有敏感配置迁移至 `config/` 目录或 `.env` 文件，严禁提交至代码仓库。
2. **修复 SQL 注入漏洞**：`get_printer` 函数中的 `$where` 拼接必须替换为 CI3 Query Builder 链式调用或参数化查询。
3. **兼容现代 PHP 版本**：全局替换 `create_function` 为匿名函数，将 `rand()` 升级为 `random_int()`，确保代码在 PHP 7.4/8.0+ 环境下稳定运行。
4. **开启 SSL 验证**：`curlRequest` 中恢复证书校验，避免第三方 API 通信被劫持。
### 🛠 后续重构与优化方向
1. **架构解耦（核心）**：
- 将当前 `common_helper.php` 拆分为多个独立组件。CI3 的 Helper 仅保留纯字符串/数组/数学计算等无状态函数。
- 涉及状态保持、网络请求、数据库交互的逻辑，统一封装至 `application/libraries/` 下的 Service 类，并通过 CI3 的 `$this->load->library()` 或依赖注入容器管理。
2. **连接资源池化**：
- Redis、WebSocket 客户端应实现单例或连接池管理，避免每次请求重复握手。可考虑使用 `pconnect()` 或引入 `php-redis` 连接池扩展。
3. **统一错误与日志规范**：
- 废弃 `do_log` 直接写文件的方式，接入 CI3 的 `log_message()` 或 Monolog，按级别（ERROR, WARNING, INFO）分类，并支持日志轮转与集中收集。
- 统一 API/内部函数返回格式，避免混用 `false`、`[]`、`true` 和数组，降低调用方判断成本。
4. **补充测试覆盖**：
- 针对 `get_printer` 路由逻辑、`createOutTradeNo` 唯一性、微信 Token 刷新机制编写 PHPUnit 单元测试，确保重构后业务逻辑不回归。
> 💡 **提示**：由于提供的代码在末尾处被截断（`$CI->ahead_shop_confi`），部分订单打印逻辑未能完整评估。建议在完整提交代码后，针对 `order_printer` 函数进行二次专项审查，重点关注事务一致性与并发打印锁机制。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780305801
|
1780305801
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
430
|
21
|
149
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `7611b0455 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `7611b0455ec2701f8e5a7f013783bc5ee996c0a3`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 17:22:29
---
## 1. 审查摘要
- **代码质量评分**：4/10 分
- **总体评价**：该文件是一个典型的“上帝助手（God Helper）”，承载了短信、日志、OSS、微信API、WebSocket、打印机路由等十余个跨域功能。代码存在**硬编码敏感凭证、原始SQL拼接注入风险、已废弃函数调用**等严重问题。整体缺乏现代 PHP 类型约束与 PSR-12 规范，且未充分利用框架提供的安全与查询组件。若直接上线，存在较高安全与稳定性风险。
- **风险等级**：🔴 高
> 📌 **框架说明**：根据代码特征（`defined('BASEPATH')`、`&get_instance()`、`$CI->load->model()` 等），实际框架为 **CodeIgniter 3**。若确为 `phpci`，请核对官方文档，但以下审查基于 CI3 架构与通用 PHP 最佳实践。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `alioss_addObject` | **硬编码云凭证**：`accessId`、`accessKey` 直接写死在代码中，极易导致云存储被盗刷或数据泄露。 | 移至 `application/config/oss.php`，通过 `$CI->config->item()` 读取，并配合环境变量管理。 | `$param = $CI->config->item('ali_oss');`<br>`$obj = new Alioss($param);` |
| 🔴 严重 | `get_printer` (多处) | **SQL 注入风险**：使用字符串拼接构造 `FIND_IN_SET` 等条件（如 `'_shop_id= ' . $shop_id`），未使用参数绑定或查询构造器。 | 使用 CI 查询构造器或参数化查询，避免直接拼接用户/请求输入。 | `$this->db->where('FIND_IN_SET(?, _checkstand_id)', $checkstand_id, FALSE);`<br>`$this->db->where('_status', 1);` |
| 🔴 严重 | `decodeUnicode` | **使用已废弃函数**：`create_function()` 在 PHP 7.2+ 已废弃，PHP 8.0+ 直接致命错误。 | 替换为匿名函数（Closure）或箭头函数。 | `preg_replace_callback('/\\\\u([0-9a-f]{4})/i', fn($m) => mb_convert_encoding(pack('H*', $m[1]), 'UTF-8', 'UCS-2BE'), $str);` |
| 🟠 警告 | `curlRequest` | **关闭 SSL 验证**：`CURLOPT_SSL_VERIFYPEER => false` 使请求易受中间人攻击（MITM）。 | 生产环境必须开启验证，并配置正确的 CA 证书路径。 | `curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, true);`<br>`curl_setopt($curl, CURLOPT_CAINFO, '/path/to/cacert.pem');` |
| 🟠 警告 | `unique_rand_OutTradeNo` | **低效去重算法**：循环内反复执行 `array_flip(array_flip($return))`，时间复杂度趋近 O(N²)，并发或量大时性能骤降。 | 使用 `do-while` 配合 `isset()` 集合或 `array_unique()` 替代。 | `do { $val = createOutTradeNo(...); } while(isset($seen[$val])); $return[] = $val;` |
| 🟠 警告 | `web_socket_client` 系列 | **连接泄漏隐患**：使用 `static` 缓存客户端实例但从未调用 `close()`，长驻进程会导致文件描述符耗尽。 | 增加连接状态检查，或注册 `register_shutdown_function` 统一释放资源。 | `register_shutdown_function(function() use ($client) { if($client) $client->close(); });` |
| 🟡 建议 | 全局函数命名 | **违反 PSR-12 规范**：混用驼峰(`sendSMS`)、下划线(`do_log`)、大小写(`AliSendSMS`)，可读性与自动补全体验差。 | 统一采用 `snake_case` 命名，并补充 PHPDoc 类型声明。 | `function send_sms(string $to, array $msg, int $v = 2): array` |
| 🟡 建议 | `do_log` / `characet` | **错误抑制与不可靠编码检测**：`@mkdir`/`@file_put_contents` 掩盖真实错误；`mb_detect_encoding` 准确率极低。 | 移除 `@`，使用 CI 内置日志 `$CI->log->write_log()`；明确约定输入输出均为 UTF-8。 | `log_message('debug', $text);`<br>`return mb_convert_encoding($data, 'UTF-8', 'auto');` |
| 🟡 建议 | `timeToHour` / `hourToTime` | **魔法数字硬编码**：依赖固定时间戳 `1483200000`（2017-01-01），跨年或时区变更易引发逻辑错乱。 | 使用 `DateTime` 对象或相对时间计算，消除绝对时间戳依赖。 | `$dt = new DateTime('2017-01-01 ' . $time); return $dt->getTimestamp() - 1483200000;` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题（P0）
1. **立即移除硬编码凭证**：将 `alioss_addObject` 中的 `accessId`/`accessKey` 抽离至配置文件，并建议接入 KMS 或环境变量管理。
2. **修复 SQL 注入漏洞**：全面重构 `get_printer` 中的 `$where` 拼接逻辑，强制使用 CI3 的 `$this->db->where()` 或 `$this->db->query($sql, $binds)` 进行参数化查询。
3. **替换 `create_function`**：全局搜索并替换为匿名函数，确保兼容 PHP 7.4+ / 8.x。
### 🛠 后续重构与优化方向
1. **拆分“上帝助手”**：当前文件超 1000 行且职责混杂。建议按业务域拆分为：
- `application/helpers/sms_helper.php`
- `application/helpers/wechat_helper.php`
- `application/helpers/websocket_helper.php`
- `application/helpers/printer_helper.php`
2. **引入现代 PHP 特性**：若项目允许升级至 PHP 7.4+，建议为核心函数添加类型声明（`declare(strict_types=1);`、参数类型、返回类型），大幅提升可维护性与静态分析能力。
3. **规范日志与错误处理**：废弃自定义 `do_log`，全面迁移至 CI3 内置 `log_message()` 或 Monolog；移除 `@` 错误抑制符，通过异常或返回值明确传递失败状态。
4. **框架适配优化**：CI3 中频繁在 Helper 中调用 `$CI->load->model()` 会拖慢性能。建议将高频依赖的 Model 在 Controller 层预加载，或封装为 Service 类（如 `app/services/SmsService.php`）统一管理依赖注入。
> ⚠️ **局限性说明**：您提供的代码在末尾 `order_printer` 函数处被截断（`$CI->ahead_shop_confi`），无法完整评估该函数的逻辑闭环。建议补充完整代码后再次提交审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780305749
|
1780305749
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
429
|
22
|
45
|
1
|
|
0
|
🔍 代码审查报告：app-260616 - 1
|
## 自动代码审查报告
**分支**: app-260616
**提交**: `7b8e8ca40 ## 自动代码审查报告
**分支**: app-260616
**提交**: `7b8e8ca407daaeeab14ece71445ddb0735c73270`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 17:20:06
---
## 1. 审查摘要
- **代码质量评分**：N/A（待提供具体变更代码）
- **总体评价**：当前仅收到项目目录结构，未包含具体的代码变更内容（Diff 或文件片段）。该目录结构高度符合 **CodeIgniter 3** 的核心架构。若 `phpci` 为内部定制或衍生框架，在缺乏实际代码的情况下无法进行实质性审查。
- **风险等级**：未知（需补充代码后评估）
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🟡 建议 | 全局/未提供 | **未提交变更代码内容**，无法执行逻辑、安全、性能及规范维度的深度审查。 | 请提供具体的 `git diff` 输出、修改前后的代码片段或完整文件内容。建议标注修改动机与业务场景。 | - |
| 🟠 警告 | `system/` 目录 | 若本次变更直接修改了 `system/` 下的核心文件（如 `DB_driver.php`, `Session.php`, `Security_helper.php`），将导致框架升级困难且易引发全局副作用。 | 遵循框架扩展规范：将自定义逻辑移至 `application/` 或 `app/` 目录，通过继承核心类或使用 Hook/Event 机制覆盖默认行为。 | `class MY_Session extends CI_Session { ... }` |
## 3. 总结与行动建议
- **优先修复的关键问题**：
1. **补充代码片段**：请提交实际修改的 PHP 文件内容或 Git Diff。建议包含上下文（至少前后 10 行），以便准确评估边界条件与调用链。
2. **避免直接修改核心库**：若变更涉及 `system/` 目录，请评估是否可通过框架提供的扩展点（如自定义 Helper、Library 继承、配置覆盖）实现相同需求。
- **后续重构或优化的方向性指导**：
1. **框架适配提示**：根据目录结构推断，项目可能基于 CI3 架构。若 `phpci` 为独立框架，请以官方文档为准。核心组件（如 `DB_query_builder.php`, `Form_validation.php`）的修改需严格遵循其生命周期，避免破坏自动加载或钩子机制。
2. **安全基线检查清单**（提交代码后我将重点核查）：
- 数据库操作是否全部使用查询构造器或预处理参数绑定（防 SQL 注入）。
- 输出到视图的变量是否经过转义或框架内置过滤（防 XSS）。
- 敏感操作是否包含 CSRF Token 校验与权限中间件/过滤器拦截。
3. **性能与规范**：
- 检查循环内是否包含重复的数据库查询或文件 I/O。
- 确保遵循 PSR-12 规范，推荐在文件头部添加 `declare(strict_types=1);`（若运行环境为 PHP 7.0+）。
- 移除冗余的 `include/require`，优先使用框架的自动加载机制。
> 📌 **下一步**：请回复具体的变更代码内容（支持 Markdown 代码块或 Diff 格式）。收到后我将立即按照上述维度输出完整的深度审查报告与可直接落地的修复代码。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780305606
|
1780305606
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
428
|
21
|
148
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 自助转房
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `15f743dd2 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `15f743dd2010652b7e895a1426cb648718777011`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 17:07:48
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了较为完整的业务链路（预订、支付、日志、配置读取等），但存在明显的历史技术债。核心问题集中在**安全规范缺失**（硬编码密钥、SQL拼接、未过滤输入）、**现代 PHP 兼容性不足**（使用已废弃函数）、**框架生命周期破坏**（滥用 `exit/die` 与输出缓冲）以及**控制器臃肿**。测试代码与生产逻辑高度耦合，需进行架构级梳理。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `common_helper.php`<br>`alioss_addObject` | 硬编码阿里云 OSS `accessId` 与 `accessKey`，极易随代码库泄露，导致云存储被恶意读写或产生高额账单。 | 移至 `application/config/oss.php` 或环境变量，通过 CI 配置类加载。 | `$param = $CI->config->item('ali_oss');`<br>`$obj = new Alioss($param);` |
| 🔴 严重 | `common_helper.php`<br>`get_printer` | 使用字符串直接拼接构建 SQL `WHERE` 条件（如 `'_shop_id= ' . $shop_id`），未使用查询构造器或参数绑定，存在 SQL 注入风险。 | 统一使用 CI 查询构造器数组语法或 `$this->db->where()`，框架会自动转义。 | `$where = ['_shop_id' => $shop_id, '_status' => 1];`<br>`if ($checkstand_id) $where['FIND_IN_SET'] = $checkstand_id;`<br>`$this->db->where($where)->get()->row_array();` |
| 🔴 严重 | `common_helper.php`<br>`decodeUnicode` | 使用 `create_function` 创建匿名函数。该函数在 PHP 7.2 已废弃，PHP 8.0 彻底移除，升级后将直接抛出致命错误。 | 替换为现代 PHP 匿名函数语法。 | `preg_replace_callback('/\\\\u([0-9a-f]{4})/i', function($m) { return mb_convert_encoding(pack("H*", $m[1]), "UTF-8", "UCS-2BE"); }, $str);` |
| 🟠 警告 | `TestHlj.php`<br>`jsonEcho` | 混用 `ob_end_clean()`、`flush()`、`die()` 强行中断执行，破坏 CI 框架的 Output 类、Hook 机制及后续中间件执行，易引发 `Headers already sent` 错误。 | 移除输出缓冲控制，使用 CI 标准输出或封装统一响应组件。 | `$this->output->set_content_type('application/json')->set_output(json_encode($result, JSON_UNESCAPED_UNICODE));` |
| 🟠 警告 | `TestHlj.php` / `Order.php` | 直接读取 `$_GET`、`$_REQUEST`、`php://input`，绕过 CI 输入过滤与 XSS 防护，且未做类型校验或默认值处理。 | 使用 CI 输入类 `$this->input->get()` / `$this->input->post()`，结合 `xss_clean` 或表单验证规则。 | `$this->params = json_decode($this->input->raw_input_stream, true) ?: [];`<br>`$order_id = $this->input->get('order_id', TRUE);` |
| 🟠 警告 | `common_helper.php`<br>`curlRequest` | `CURLOPT_SSL_VERIFYPEER => false` 禁用 SSL 证书验证，在公网环境下易遭受中间人攻击（MITM），导致敏感数据（如支付回调、短信接口）被劫持。 | 生产环境必须开启验证，并配置系统 CA 证书路径。 | `curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, true);`<br>`curl_setopt($curl, CURLOPT_CAINFO, '/etc/ssl/certs/ca-certificates.crt');` |
| 🟡 建议 | `TestHlj.php` | 大量硬编码测试数据（`merchant_id=1281`, `uid=66` 等），且包含 `exit('ok')`、`var_dump` 等调试语句，直接合并至主分支会污染生产环境。 | 测试控制器应增加环境守卫，或迁移至独立测试目录（如 `tests/`），生产代码严禁保留调试输出。 | `if (ENVIRONMENT !== 'testing') { show_error('此接口仅限测试环境'); }` |
| 🟡 建议 | `common_helper.php` | 函数命名风格混乱（`doLog` vs `do_log`、`AliSendSMS` vs `sendSMS`），不符合 PSR-12 及 PHP 社区 `snake_case` 惯例，降低可读性。 | 统一使用 `snake_case`，移除冗余别名函数，保留单一入口。 | 统一为 `do_log()`，删除 `doLog()` 包装层。 |
| 🟡 建议 | `Ahead_shop_config_second_model.php`<br>`get_shop_setting` | `switch` 分支长达 100+ 行，维护成本极高；且静态缓存 `self::$shop_config[$shop_id]` 未区分商户维度，多租户场景下可能串数据。 | 使用配置映射数组或动态属性访问；缓存键改为 `md5($merchant_id . '_' . $shop_id)`。 | `return $data[$field] ?? $default;`<br>`$cacheKey = $merchant_id . '_' . $shop_id;` |
| 🟡 建议 | `Order.php`<br>`buyRenewalPackage` / `createOrder` | 单个方法超过 150 行，混合了参数校验、订单创建、支付路由（微信/国通）、缓存读取等逻辑，违反单一职责原则（SRP）。 | 拆分为独立服务类（如 `PaymentRouterService`、`OrderCreationService`），控制器仅负责接收请求与返回结果。 | `$paymentService = new PaymentService();`<br>`$result = $paymentService->process($param);` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **安全漏洞清零**：立即移除 `common_helper.php` 中的 OSS 硬编码凭证，改用配置中心或 `.env` 管理；修复 `get_printer` 中的 SQL 拼接逻辑，全面切换至 CI 查询构造器。
2. **PHP 版本兼容**：全局替换 `create_function` 为匿名函数，确保代码兼容 PHP 7.4+ / 8.x。
3. **输入过滤与框架规范**：禁止直接使用 `$_GET/$_POST/$_REQUEST`，统一通过 `$this->input->get()` 获取；移除控制器中的 `ob_*` 与 `die()`，改用框架标准输出流。
### 🛠 后续重构与优化方向
1. **控制器瘦身与服务化**：`TestHlj.php` 与 `Order.php` 属于典型的“胖控制器”。建议将支付路由、订单组装、配置读取等逻辑下沉至 `application/services/` 或 `application/libraries/`，控制器仅保留路由分发与响应格式化。
2. **统一响应与异常处理**：当前代码混用 `jsonEcho`、`echo json_encode`、`exit`、`throwError`。建议封装全局 `ApiResponse` 组件，结合 CI 的 `Hooks` 或自定义异常处理器，实现统一的状态码、消息体与日志记录。
3. **配置与缓存优化**：`Ahead_shop_config_second_model` 的静态缓存缺乏失效机制与多租户隔离。建议引入 Redis 缓存层，设置合理的 TTL，并在后台修改配置时主动清除缓存。
4. **测试代码隔离**：`TestHlj.php` 中的大量硬编码与调试逻辑应通过 `ENVIRONMENT` 常量隔离，或迁移至 PHPUnit/Codeception 测试套件，避免测试逻辑侵入生产代码库。
> 💡 **框架适配说明**：从代码结构（`BASEPATH`、`$this->load->`、`Simple_model` 基类等）判断，当前项目实际基于 **CodeIgniter 3** 架构。上述建议均严格遵循 CI3 最佳实践与现代 PHP 开发规范。若项目确为内部定制的 `phpci` 框架，请核对上述 CI3 特性（如 `$this->input`、`$this->output`、查询构造器）是否被完整继承或替换，必要时查阅对应框架的官方文档进行适配。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780304868
|
1780304868
|
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
|
|
426
|
18
|
176
|
1
|
|
0
|
🔍 代码审查报告：pc-260616 - 库存盘点新增支持选择时分
|
## 自动代码审查报告
**分支**: pc-260616
**提交**: `3a8c1d89a6 ## 自动代码审查报告
**分支**: pc-260616
**提交**: `3a8c1d89a6ca3894c1d083879d84d15cee43ee60`
**提交人**: caihongyuchy (1091045324@qq.com)
**时间**: 2026-06-01 15:47:10
---
### 1. 总体评价
> **综合评分：4/10**
> 该组件实现了库存盘点的核心业务逻辑，但属于典型的 **Vue 2 + jQuery 混合架构遗留代码**。整体存在严重的架构反模式（Vue 响应式与 jQuery DOM 操作深度耦合）、命名不规范、魔法值硬编码、异步逻辑缺乏管控等问题。代码可维护性与性能表现较差，后续迭代成本极高。建议优先进行 jQuery 解耦与状态管理重构，逐步迁移至纯 Vue 生态。
---
### 2. 问题详情清单
| 严重等级 | 位置/行号 | 问题分类 | 问题描述 | 建议修改方案 |
| :---: | :---: | :---: | :---: | :---: |
| 🔴 严重 | `methods: getMunu` / `methods: saveGoods` / `methods: getChecksGoods` | 逻辑/规范 | 组件 `name: 'procurement_return'` 与文件名 `stock_checks.vue` 严重不符；多处拼写错误（`getMunu`, `innitDate`, `getDeteil`, `scollPostion`）。 | 统一命名规范，修正拼写错误，确保组件名与文件语义一致。 |
| 🔴 严重 | `methods: saveGoods` / `getChecksGoods` | 逻辑缺陷 | 使用 `$.map` 遍历数组时，内部 `return;` 仅跳出当前回调，**无法中断循环**，导致重复商品校验失效且可能触发多次 `layer.msg`。 | 改用 `Array.prototype.some()` 或 `for...of` 进行存在性校验，校验通过后再执行添加逻辑。 |
| 🔴 严重 | `watch: checks_goods_list` / `type_item` / `export_checkModel` | 性能 | 对数组/对象使用 `deep: true` 监听，任何子属性变更都会触发全量重算与 DOM 更新，极易引发性能瓶颈与无限循环。 | 移除 `deep: true`，改用显式方法调用（如 `updateBtnState()`）或 `computed` 属性派生状态。 |
| 🟡 警告 | `mounted` / 所有 `$.ajax` 调用 | 逻辑/性能 | 大量使用 jQuery 插件（Select2, BootstrapTable, Daterangepicker）直接操作 `this.$refs`，未使用 `this.$nextTick` 或自定义指令封装，易导致 Vue 渲染与 DOM 初始化时序冲突。 | 将 jQuery 插件初始化封装为独立 Vue 指令或组件，统一在 `mounted` + `$nextTick` 中执行，或迁移至 `vue-select`/`element-table` 等原生组件。 |
| 🟡 警告 | `methods: getList` / `getStock` 等 | 错误处理 | 所有 AJAX 错误仅提示 `layer.msg("网络错误")`，未处理 HTTP 状态码、超时、Token 过期等场景；`params.success` 在失败分支仍被调用，可能导致表格渲染异常。 | 统一封装请求拦截器，区分业务错误与网络错误；失败时调用 `params.error()` 或返回空数据，避免状态不一致。 |
| 🟡 警告 | `methods: getMunu` | 安全/可维护性 | 硬编码菜单权限 ID（`'543'`, `'563'`, `'646'`, `'659'`），多层嵌套 `$.each`，可读性差且极易因后台配置变更导致权限失效。 | 提取为常量配置对象（如 `MENU_PERMISSIONS`），使用 `Array.prototype.find()` 扁平化查找逻辑。 |
| 🟢 建议 | `template` 多处 | 规范 | 模板中存在大量注释掉的代码块（如 `<!-- <span class="col-md-3"... -->`），以及未使用的 `data` 字段（`remarkList`）。 | 清理无用注释与死代码，保持模板整洁；使用版本控制系统管理历史代码。 |
| 🟢 建议 | `methods: addExport` | 性能/规范 | 导出逻辑中 `let sheet3 = sheet1 + sheet2;` 为无效字符串拼接，且未处理大数据量导出的内存溢出风险。 | 移除无效代码；若数据量 > 1万行，建议改用流式导出或交由后端生成文件链接。 |
---
### 3. 优化代码示例
以下针对 **核心逻辑缺陷** 与 **Vue/jQuery 混合反模式** 提供重构参考：
```javascript
// 1. 修复 $.map 无法中断循环的致命缺陷 & 统一请求封装
// 原代码：saveGoods / getChecksGoods 中的重复校验与 $.ajax 嵌套
async function addGoodsToCheckList(newItems) {
const existingIds = new Set(this.checks_goods_list.map(item => item.merchant_goods_id));
// 使用 Array.some 正确中断循环，避免重复提示
const hasDuplicate = newItems.some(item => {
if (existingIds.has(item.merchant_goods_id)) {
layer.msg(`商品 ${item.goods_name} 已存在`);
return true;
}
return false;
});
if (hasDuplicate) return;
// 统一数据转换，避免直接修改响应对象
const formattedItems = newItems.map(item => ({
...item,
actual_stock: item.system_stock,
profit_loss: Number(item.system_stock) - Number(item.system_stock), // 初始盈亏为0
remark: ''
}));
this.checks_goods_list.push(...formattedItems);
this.updateBtnState(); // 显式触发状态更新，替代 deep watch
this.initGoodsTable(); // 刷新表格
}
// 2. 替换 jQuery $.ajax 为现代 async/await + 统一请求层
// 建议在 src/utils/request.js 封装 axios 实例，此处为调用示例
async function fetchStockInfo(params) {
try {
const response = await this.$http.post('stock/getStockInfo', params);
if (response.result_code === 'true') {
return response.result.data;
}
throw new Error(response.error_msg || '业务请求失败');
} catch (err) {
layer.msg(err.message || '网络异常，请稍后重试');
throw err;
}
}
// 3. 替代 deep watch 的显式状态管理
// 原 watch: checks_goods_list { deep: true } 性能极差
methods: {
updateBtnState() {
this.btnClickable = this.checks_goods_list.length > 0;
},
// 在每次增删改 checks_goods_list 后手动调用
// 例如：this.checks_goods_list.push(...); this.updateBtnState();
}
```
---
### 4. 总结与行动建议
#### 🚀 最优先改进建议（按实施成本与收益排序）
1. **解耦 jQuery 插件依赖**：将 `Select2`、`BootstrapTable`、`Daterangepicker` 替换为 Vue 生态组件（如 `@vueform/multiselect`、`vxe-table`、`vue-datepicker`），彻底消除 `$(this.$refs)` 操作，恢复 Vue 响应式优势。
2. **统一异步请求与错误处理**：废弃内联 `$.ajax`，引入 `axios` 或 `fetch` 封装全局请求拦截器，集中处理 Token 刷新、Loading 状态、业务码校验与用户提示，消除重复的 `if(data.response.result_code == "true")` 模板代码。
3. **修复状态监听与循环逻辑**：移除所有 `deep: true` 的 `watch`，改用 `computed` 或显式方法调用；修复 `$.map` 中的 `return` 中断失效问题，避免重复数据入库与 UI 闪烁。
#### 🛠 推荐 Lint 规则与配置项
建议在 `.eslintrc.js` / `vue.config.js` 中启用以下规则，强制规范代码质量：
```js
rules: {
// 禁止在 Vue 组件中直接使用 jQuery 全局变量
'no-jquery/no-jquery': 'error',
// 强制组件 name 与文件名 kebab-case 一致
'vue/match-component-file-name': ['error', { extensions: ['vue'], shouldMatchCase: false }],
// 禁止使用 deep watch 监听数组/对象（需配合注释豁免）
'vue/no-deep-watch': 'warn',
// 强制 async 函数必须包含 try-catch 或明确处理 Promise rejection
'require-await': 'error',
// 禁止在模板中使用 v-html 或字符串拼接渲染未转义内容（防 XSS）
'vue/no-v-html': 'error',
// 强制使用 const/let，禁止 var
'no-var': 'error',
'prefer-const': 'error'
}
```
> 💡 **架构演进提示**：若项目短期内无法完全移除 jQuery，建议至少将 DOM 操作封装为 **Vue 自定义指令**（如 `v-select2`、`v-bootstrap-table`），利用 `bind`/`update`/`unbind` 生命周期管理插件实例，避免内存泄漏与渲染冲突。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780300030
|
1780300030
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
425
|
21
|
147
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `7d0d7190c ## 自动代码审查报告
**分支**: pay-260616
**提交**: `7d0d7190cb99439cd503c271e862970f6ac595ce`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 14:38:06
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该 Model 承载了大量核心订单业务逻辑，功能覆盖较全。但存在**高危 SQL 注入风险**、**严重 N+1 查询性能瓶颈**、**事务缺失导致的数据不一致隐患**，且核心方法（如 `get_bill_goods_info`）严重违反单一职责原则。代码风格与 PSR-12 规范存在偏差，框架组件使用不够规范。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_bill_goods_info` | **SQL 注入漏洞**：`$sql = '_unique_key="' . $unique_key . '" ...'` 直接拼接用户/外部传入参数，未做转义或参数绑定。 | 废弃字符串拼接，全面改用框架查询构造器（Query Builder）或参数化查询。 | `$this->db->where('_unique_key', $unique_key)->where_in('_status', [1,4])->get()->result_array();` |
| 🔴 严重 | `confirm_receipt` / `close_room_after` | **事务缺失**：连续执行多次 `insert`/`update` 操作，若中途发生异常或网络中断，将导致订单状态与流水记录不一致。 | 使用数据库事务包裹关键写入操作，失败时自动回滚。 | `$this->db->trans_start(); /* 执行写入 */ if($this->db->trans_status()===FALSE) $this->db->trans_rollback(); else $this->db->trans_commit();` |
| 🔴 严重 | `get_detail` | **逻辑/语法错误**：`$this->ahead_yc_order_model->get_one(...)` 在自身类中调用自身实例，属于冗余或笔误，易引发未定义属性报错。 | 直接调用当前实例方法：`$this->get_one(...)`。 | `$before_order_info_data = $this->get_one(['_id' => $order_info['before_order_id']], '_actual_pay');` |
| 🔴 严重 | `encode_group_buying_order` | **弱加密与硬编码**：使用 `md5` 生成签名，易受碰撞攻击；加密串 `Vs!Fs7VT` 硬编码在类中，泄露风险高。 | 改用 `hash_hmac('sha256', $data, $key, true)`；密钥移至 `config/` 配置文件。 | `$sign = hash_hmac('sha256', $order_id, config_item('group_buying_secret'), true);` |
| 🟠 警告 | `get_list` | **N+1 查询性能瓶颈**：在 `foreach` 循环内动态 `load->model()` 并执行 `get_one()`，订单量稍大即导致数据库连接耗尽。 | 提取所有 `package_id`，使用 `where_in` 批量查询，再通过 PHP 数组映射关联数据。 | `$ids = array_column($order_info, 'package_id'); $pkgs = $this->ahead_room_package_model->get_batch(['_id' => $ids], '_id,_img_url');` |
| 🟠 警告 | `get_bill_goods_info` | **方法过长 & 职责混乱**：单方法超 300 行，混合了数据查询、金额计算、明细合并、特殊支付处理，极难维护与测试。 | 拆分为独立私有方法：`_calc_totals()`, `_merge_goods_details()`, `_handle_special_platform()` 等。 | 见下方重构建议 |
| 🟠 警告 | 类定义/全局 | **隐式依赖与不规范加载**：类外部定义 `$CI = &get_instance();`；`binding_order_check` 中直接使用未声明的 `$this->uid`。 | 移除类外 `$CI`；`$this->uid` 应通过构造函数注入或作为方法参数传入，避免隐式全局依赖。 | `public function __construct() { parent::__construct(); $this->load->model('Simple_model'); }` |
| 🟡 建议 | 全文件 | **命名规范 & 魔法数字**：类名/方法名使用下划线（非 PSR-12 驼峰）；大量硬编码数字（如 `1, 2, -1, 10`）未使用已定义的 `const`。 | 重命名为 `AheadYcOrderModel`；全面替换硬编码数字为类常量；清理过时注释（如 `//add by nan`）。 | `const STATUS_PAID = 1; if ($status === self::STATUS_PAID) { ... }` |
## 3. 总结与行动建议
### 🚨 优先修复项（P0）
1. **修复 SQL 注入**：立即替换 `get_bill_goods_info` 中的字符串拼接 SQL，使用框架提供的 `$this->db->where()` 或预处理语句。
2. **补充事务控制**：为 `confirm_receipt`、`close_room_after`、`bindingOrder` 等涉及多表写入的方法添加 `$this->db->trans_start()/trans_complete()` 机制。
3. **修正自调用错误**：将 `get_detail` 中的 `$this->ahead_yc_order_model->get_one()` 改为 `$this->get_one()`。
### 🛠 性能与架构优化方向
1. **消除 N+1 查询**：将 `get_list` 中的循环内查询改为 `IN` 批量查询。可参考以下模式：
```php
// 优化前：循环内查询
// 优化后：批量获取后内存映射
$package_ids = array_unique(array_column($order_info, 'package_id'));
$packages = $this->db->where_in('_id', $package_ids)->get('ahead_room_package')->result_array();
$pkg_map = array_column($packages, '_img_url', '_id');
foreach ($order_info as &$val) {
$val['img'] = $pkg_map[$val['package_id']] ?? DEFAULTIMG;
}
```
2. **拆分巨型方法**：`get_bill_goods_info` 建议按业务边界拆分为 3~4 个私有方法。例如将商品明细合并逻辑抽离至 `private function _merge_goods_list($raw_data, $merge_flag)`，提升可读性与单元测试覆盖率。
3. **统一配置管理**：将 `$encrypt`、支付平台映射数组、订单类型常量等全部迁移至 `application/config/order_config.php`，通过 `$this->config->item()` 读取，便于多环境部署与热更新。
### 📝 规范与框架适配建议
- **命名规范**：遵循 PSR-12，类名改为 `AheadYcOrderModel`，方法名改为驼峰式（如 `getBillGoodsInfo`）。若受历史包袱限制，至少保证新增代码符合规范。
- **模型加载时机**：避免在业务方法中频繁调用 `$this->load->model()`。建议在 `__construct()` 中统一加载依赖模型，或使用 CI 的自动加载配置。
- **框架说明**：代码结构高度契合 CodeIgniter 3 规范。若 `phpci` 为内部定制框架，请确认 `Simple_model` 的 `select()` 与 `get_one()` 是否已内置防注入与自动转义机制。若未内置，必须手动使用 `$this->db->escape()` 或查询构造器。
- **代码截断提示**：末尾 `get_timing_order` 方法未完整提供，无法评估其返回逻辑与异常处理。请补充完整代码以便进行闭环审查。
> 💡 **下一步行动**：建议先建立自动化测试用例覆盖核心计费与状态流转逻辑，随后按 `安全修复 → 事务补充 → 性能优化 → 代码重构` 的顺序迭代。重构过程中可引入 `PHP_CodeSniffer` 配合 `PSR12` 规则集进行静态检查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780295886
|
1780295886
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
424
|
21
|
146
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `13aa78358 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `13aa7835889440600dc8db917ad5579ec2bd31bf`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 14:32:45
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该模型文件承载了大量核心订单业务逻辑，功能覆盖较全，但存在明显的架构与编码缺陷。主要问题集中在 **循环内重复加载模型/查询（N+1性能瓶颈）**、**SQL条件拼接注入风险**、**变量作用域混淆导致的数据丢失**，以及**硬编码与常量混用**带来的维护成本。整体代码具备可运行性，但距离生产级高可用、高安全标准仍有较大差距。
- **风险等级**：🔴 高（存在SQL注入隐患、严重性能瓶颈及逻辑数据丢失）
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_bill_goods_info` (~L238) | **SQL注入风险**：使用字符串直接拼接构造查询条件 `$sql = '_unique_key="' . $unique_key . '" AND ...'`，未进行参数绑定或转义，恶意输入可破坏SQL结构。 | 废弃字符串拼接，全面使用框架查询构造器（Query Builder）的数组或链式方法传参，由底层驱动自动处理转义。 | `$this->db->where('_unique_key', $unique_key)->where_in('_status', [1,4])->...` |
| 🔴 严重 | `get_detail` (~L138) | **逻辑漏洞/数据丢失**：局部变量 `$order_data['before_payment']` 被赋值，但最终返回的 `$data['order_info']` 仅包含 `$order_info`，导致“转房前需支付金额”完全丢失。 | 将计算结果正确合并至 `$order_info` 数组中，确保返回数据结构完整。 | `$order_info['before_payment'] = $before_order_info_data['_actual_pay'] ?? '';` |
| 🟠 警告 | `get_list` (~L85) | **严重性能瓶颈**：在 `foreach` 循环中重复调用 `$this->load->model()`，且每次循环执行独立查询（N+1问题）。订单量稍大即会导致数据库连接耗尽与响应超时。 | 将模型加载移至方法顶部；收集所有 `package_id` 后使用 `where_in` 批量查询，再在内存中通过键值映射赋值。 | 收集 `$ids` → `$res = $model->where_in('_id', $ids)->get()` → `foreach` 内存匹配 |
| 🟠 警告 | `close_room_after` (~L185) | **性能与事务隐患**：在循环中逐条执行 `update()` 和 `insert()`，缺乏事务控制。若中途失败会导致订单状态与流水记录不一致。 | 使用框架批量操作方法，并包裹在数据库事务中，确保原子性。 | `$this->db->trans_start(); ... $this->db->update_batch(...); $this->db->trans_complete();` |
| 🟠 警告 | `binding_order_check` (~L365) | **隐式依赖/未定义变量**：直接使用 `$this->uid`，该属性未在模型中声明。模型强依赖外部控制器注入，违反单一职责与可测试性原则。 | 通过方法参数显式传入 `$uid`，或在基类 `Simple_model` 中明确定义并初始化。 | `public function binding_order_check($order_id, $sign, $uid)` |
| 🟡 建议 | 文件顶部 (~L4) | **框架规范不符**：在类外部使用 `$CI = &get_instance();` 加载模型。在 CI/类CI 架构中，此写法易引发生命周期冲突，且模型内应直接使用 `$this->load`。 | 移除顶部代码，按需延迟加载或统一在 `__construct()` 中加载依赖模型。 | `public function __construct() { parent::__construct(); $this->load->model('Simple_model'); }` |
| 🟡 建议 | 全局 | **常量与数组混用/魔法数字**：部分映射使用 `public $array`，部分使用 `const`；业务状态码（如 `1, 2, 3`）在多处硬编码，未完全复用已定义的常量。 | 统一使用 `const` 或 `private static` 定义映射；全面替换魔法数字为类常量，提升可读性与可维护性。 | `const STATUS_PAID = 1;` 替代硬编码 `1` |
| 🟡 建议 | `get_timing_order` (~L390) | **代码截断**：方法未完整提供，无法审查后续逻辑与返回结构。 | 请补充完整代码以便进行闭环审查。 | N/A |
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **修复 SQL 注入漏洞**：立即重构 `get_bill_goods_info` 中的 `$sql` 拼接逻辑，改用框架提供的参数化查询或 Query Builder 链式调用。
2. **修复数据丢失 Bug**：修正 `get_detail` 中 `$order_data` 与 `$data` 的变量混淆问题，确保 `before_payment` 字段正确返回至前端。
3. **消除循环内模型加载与查询**：将 `get_list` 和 `get_detail` 中的模型加载移至方法起始处；将循环内的单条查询改为 `IN` 批量查询，预期可将接口响应时间降低 60% 以上。
### 🛠 后续重构与优化方向
- **拆分巨型方法**：`get_bill_goods_info` 方法超过 200 行，嵌套循环与条件分支极多。建议按职责拆分为：`calculate_bill_totals()`、`merge_goods_details()`、`format_bill_response()` 等私有方法，降低圈复杂度。
- **统一状态与映射管理**：将 `public $pay_platform_arr` 等数组迁移为 `const` 或 `private static`，并在业务逻辑中强制使用常量（如 `self::STATUS_PAID`），避免硬编码导致的后期维护灾难。
- **引入事务与批量操作**：涉及多表状态变更的方法（如 `confirm_receipt`、`close_room_after`）必须包裹在 `$this->db->trans_start()` 事务中，并优先使用 `insert_batch()` / `update_batch()`。
- **框架适配说明**：当前代码结构高度契合 **CodeIgniter 3** 规范。若 `phpci` 为内部定制框架，请确认其 `Simple_model` 基类是否已封装 Query Builder 及事务方法。若未封装，建议引入 `doctrine/dbal` 或原生 PDO 预处理语句以保障安全。
> 💡 **提示**：本次审查基于提供的代码片段。若 `phpci` 框架对模型加载、查询构造器或生命周期有特殊约定，请以官方文档为准。建议补充 `get_timing_order` 完整代码及 `Simple_model` 基类实现，以便进行更深度的架构级审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780295565
|
1780295565
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
423
|
21
|
145
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `e1cf253b1 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `e1cf253b16b6c5a3ff838a1e02e432b721f4c54a`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 14:20:58
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该模型类承载了大量核心订单业务逻辑，功能覆盖较全，但存在明显的架构与编码规范问题。核心方法（如 `get_bill_goods_info`）职责过重、循环内频繁加载模型与查询导致严重性能瓶颈，且存在 SQL 拼接、变量未定义、哈希误用为加密等安全与逻辑隐患。代码整体可维护性较低，需进行系统性重构。
- **风险等级**：🔴 高
> 📌 **框架说明**：根据代码结构（`get_instance()`、`$this->load->model()`、`system/` 目录规范等），该代码高度符合 **CodeIgniter 3.x** 规范。若 `phpci` 为内部定制框架，以下建议基于 CI3/通用 PHP 最佳实践，请结合官方文档微调。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_bill_goods_info` (~L330) | **SQL注入风险**：直接字符串拼接构造查询条件 `_unique_key="' . $unique_key . '"`，未使用参数绑定或查询构造器，易受注入攻击。 | 使用框架 Query Builder 或参数化查询，彻底杜绝字符串拼接。 | `$this->db->where('_unique_key', $unique_key)->where_in('_status', [1,4])->...` |
| 🔴 严重 | `get_detail` (~L185) | **逻辑断裂/变量未定义**：`$order_data['before_payment'] = ...` 赋值后未合并至返回数组，且 `$order_data` 变量未初始化，导致数据丢失或 Notice 警告。 | 修正为目标数组 `$order_info`，并确保最终返回结构完整。 | `$order_info['before_payment'] = $before_order_info_data['_actual_pay'] ?? '';` |
| 🔴 严重 | `get_list` / `get_detail` | **N+1 查询与循环内加载模型**：在 `foreach` 中重复 `$this->load->model()` 并执行单条 `get_one()`，数据量稍大即引发数据库连接耗尽与响应超时。 | 提前加载模型，收集所有关联 ID 后使用 `WHERE IN` 批量查询，在内存中通过键值映射组装数据。 | 见下方性能优化示例 |
| 🔴 严重 | `encode_group_buying_order` | **加密概念混淆与安全隐患**：使用 `md5()` 实现“加密/解密”，MD5 为单向哈希不可逆，实际为签名校验。且未使用防时序攻击比较。 | 若需加解密改用 `openssl_encrypt/decrypt`；若为签名校验，重命名方法并使用 `hash_equals()`。 | `public function verify_group_buying_sign($order_id, $sign) { return hash_equals(md5($order_id . $this->encrypt), $sign); }` |
| 🟠 警告 | 文件顶部 (~L4) | **模型加载位置不当**：`$CI = &get_instance(); $CI->load->model('Simple_model');` 违反框架生命周期规范，易引发依赖混乱与内存泄漏。 | 移除顶部代码，在 `__construct()` 中规范初始化父类或按需加载。 | `public function __construct() { parent::__construct(); }` |
| 🟠 警告 | `confirm_receipt` (~L245) | **状态更新逻辑隐患**：复用 `$data` 数组连续两次 `insert()`，仅修改 `_process`，可能将 `_star`、`_ahead_user_name` 等冗余字段写入第二条记录。 | 每次插入前独立构建数据数组，或使用事务保证原子性。 | `$log_data = ['_order_id'=>$order_id, '_process'=>8, '_process_msg'=>'订单完成', '_process_time'=>time()]; $this->...->insert($log_data);` |
| 🟠 警告 | `binding_order_check` (~L415) | **依赖隐式全局状态**：直接使用 `$this->uid`，模型中未声明或初始化，强依赖外部上下文，降低单元测试可行性。 | 将 `$uid` 作为方法参数显式传入，或在构造函数中统一初始化。 | `public function binding_order_check($order_id, $sign, $uid) { ... if ($order_info['_ahead_user_id'] == $uid) ... }` |
| 🟡 建议 | 全文件 | **硬编码与配置散落**：大量业务字典（`$pay_id_arr`、`$type_arr` 等）直接定义在模型中，且与 `const` 常量存在语义重复。 | 将静态映射数组抽离至 `application/config/order_config.php`，通过 `$this->config->item()` 读取。 | `// config/order_config.php<br>$config['pay_platform_map'] = [1=>'微信', 2=>'支付宝', ...];` |
| 🟡 建议 | `get_bill_goods_info` | **方法职责过重**：该方法超 300 行，混合了数据查询、金额计算、商品合并、格式化输出，违反单一职责原则（SRP）。 | 拆分为 `calculate_bill_totals()`、`merge_goods_list()`、`format_bill_output()` 等独立私有方法。 | 略（建议按业务边界拆分） |
| 🟡 建议 | 全文件 | **命名规范不一致**：方法名混用驼峰（`bindingOrder`）与蛇形（`get_list`），不符合 PSR-12 规范。 | 统一采用蛇形命名法（snake_case），如 `binding_order()`。 | `public function binding_order($order_data, $user_data, $type = 2)` |
---
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **消除 SQL 注入风险**：立即替换 `get_bill_goods_info` 中的字符串拼接查询，全面启用框架的 Query Builder 或预处理语句。
2. **修复数据丢失 Bug**：修正 `get_detail` 中 `$order_data['before_payment']` 的赋值错误，确保转房前金额正确返回。
3. **解决 N+1 性能瓶颈**：重构 `get_list` 与 `get_detail` 中的循环查询逻辑，改为批量查询（`WHERE IN`）+ 内存映射。
### 🛠️ 后续重构与优化方向
1. **拆分巨型方法**：`get_bill_goods_info` 已严重超出合理长度。建议按“数据获取 → 规则计算 → 格式组装”三层拆分，提升可读性与可测试性。
2. **配置与逻辑分离**：将所有订单状态、支付类型、场景映射等字典数据迁移至配置文件。模型仅负责数据流转，不承载业务字典。
3. **统一框架规范**：
- 移除文件顶部的 `$CI = &get_instance()`，统一在 `__construct()` 中初始化。
- 规范方法命名风格（推荐全量蛇形命名）。
- 对涉及金额计算的方法，建议引入 `bcmath` 扩展或统一使用 `number_format` 前进行浮点精度控制，避免 `float` 累加误差。
4. **补充缺失代码审查**：当前代码在 `get_timing_order` 方法末尾被截断（`return ['success' => false, 'msg' => '订单`）。请提供完整代码以便评估该方法的异常处理与返回结构是否规范。
> 💡 **提示**：若 `phpci` 框架对模型加载、查询构造器有特殊封装，请优先遵循其官方文档。上述建议基于行业通用 PHP 安全与性能标准，可直接落地实施。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780294858
|
1780294858
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
422
|
21
|
144
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `b472d90b6 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `b472d90b63161ba7e55aa8d788d794d5418d42d0`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 14:20:36
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该 Model 承载了极其复杂的订单查询、账单聚合、状态流转与绑定逻辑，业务覆盖全面。但存在**高危 SQL 注入风险**、**缺乏数据库事务保护**、**严重的 N+1 查询与循环内加载模型**等性能瓶颈。代码风格偏向早期 CI2/3 习惯，大量魔法数字与硬编码降低了可维护性，且单方法职责过重（如 `get_bill_goods_info` 超 300 行）。
- **风险等级**：🔴 高
> 💡 **框架说明**：从目录结构（`system/`、`application/models/`）、`get_instance()` 及 `$this->load->model()` 等特征判断，该项目实际基于 **CodeIgniter 3** 架构。若 `phpci` 为内部定制分支，以下安全与性能规范依然通用。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_bill_goods_info` | **SQL 注入风险**：使用字符串拼接构造 WHERE 条件 `'_unique_key="' . $unique_key . '" AND ...'` 并直接传入查询。若 `$unique_key` 来源不可控，将导致注入。 | 严格使用 CI 查询构建器（Query Builder）的 `where()` 方法，或启用参数绑定。 | `$this->db->where('_unique_key', $unique_key)->where_in('_status', [1,4])->or_where(...);` |
| 🔴 严重 | `confirm_receipt`<br>`close_room_after` | **缺乏事务保护**：连续执行 `update` 与多次 `insert`，若中途失败会导致订单状态与流水记录不一致。 | 包裹在数据库事务中，失败时自动回滚。 | `$this->db->trans_start();`<br>`// 执行操作`<br>`if ($this->db->trans_status() === FALSE) $this->db->trans_rollback();`<br>`else $this->db->trans_commit();` |
| 🟠 警告 | `get_list`<br>`get_detail` | **N+1 查询与循环内加载模型**：在 `foreach` 中调用 `$this->load->model()` 并执行 `get_one()`，数据量大时会导致严重性能衰减。 | 1. 模型统一在 `__construct()` 中加载；<br>2. 使用 `JOIN` 或批量 `WHERE IN` 一次性获取关联数据。 | `$ids = array_column($order_info, 'package_id');`<br>`$packages = $this->ahead_room_package_model->get_where_in('_id', $ids);`<br>`// 内存中映射关联` |
| 🟠 警告 | `get_detail` | **逻辑死代码/变量未使用**：`$order_data['before_payment'] = ...` 赋值后，`$order_data` 变量从未被使用或返回，实际返回的是 `$order_info`。 | 修正变量名，确保数据正确返回至前端。 | `$order_info['before_payment'] = $before_order_info_data['_actual_pay'] ?? '';` |
| 🟠 警告 | `encode_group_buying_order` | **误用 MD5 作为“加解密”**：MD5 是单向哈希算法，不可逆且已存在碰撞漏洞。当前实际用于签名校验，但命名与实现易引发安全误解。 | 改用 `hash_hmac('sha256', ...)` 或 CI 的 `Encryption` 库进行对称加密/签名。 | `return hash_hmac('sha256', $order_id, $this->encrypt, true);` |
| 🟠 警告 | `binding_order_check` | **隐式依赖未定义属性**：直接使用 `$this->uid`，该属性未在 Model 中声明。若控制器未正确注入，将导致逻辑绕过或报错。 | 通过方法参数显式传入，或在 `__construct` 中从 Session 安全获取。 | `public function binding_order_check($order_id, $sign, $uid)` |
| 🟡 建议 | `get_bill_goods_info` | **方法职责过重 & 计算逻辑臃肿**：单方法超 300 行，混合了数据查询、金额聚合、商品合并、折扣计算。PHP 循环处理大量账单数据效率低下。 | 1. 拆分出独立的 `BillCalculator` 服务类；<br>2. 将 `SUM()`、`GROUP BY` 等聚合操作下沉至数据库层执行。 | `SELECT SUM(_amount) as price_total, SUM(_actual_pay) as actual_total ... GROUP BY _unique_key` |
| 🟡 建议 | 全局 | **命名规范与魔法数字混用**：方法名混用 `snake_case` 与 `camelCase`（如 `get_list` vs `bindingOrder`）；大量硬编码状态值（`1, 2, 10, 14`）未使用已定义的常量。 | 遵循 PSR-12 统一使用 `camelCase` 方法名；全面替换硬编码为 `self::ORDER_VIP_PAY_PLATFORM` 等常量。 | `if ($order['_pay_platform'] == self::ORDER_VIP_PAY_PLATFORM) { ... }` |
## 3. 总结与行动建议
### 🚨 优先修复（P0）
1. **修复 SQL 注入漏洞**：立即重构 `get_bill_goods_info` 中的条件拼接逻辑，全面切换至 CI Query Builder 或 PDO 预处理。
2. **引入数据库事务**：为 `confirm_receipt`、`close_room_after`、`bindingOrder` 等涉及多表写入的方法添加 `$this->db->trans_start()/trans_complete()` 机制，保障资金与订单状态一致性。
3. **修正逻辑缺陷**：修复 `get_detail` 中 `$order_data['before_payment']` 未生效的 Bug，避免前端展示异常。
### 🛠 性能与架构优化（P1）
1. **消除循环查库**：将 `get_list` 和 `get_detail` 中的关联查询改为 `JOIN` 或批量 `WHERE IN` 查询，将模型加载移至构造函数。
2. **账单计算下沉**：`get_bill_goods_info` 的聚合逻辑建议拆分为独立的 `OrderBillService`。优先使用 MySQL 的 `SUM()`、`CASE WHEN` 替代 PHP 数组遍历，可提升 50%~80% 的查询性能。
3. **安全签名升级**：废弃 `md5()` 签名方案，改用 `hash_hmac('sha256', $data, $key)` 或 CI3 内置的 `encryption` 库。
### 📐 规范与可维护性（P2）
1. **统一编码规范**：方法名统一为 `camelCase`，移除文件顶部的 `$CI = &get_instance();`（破坏模型封装性）。
2. **常量集中管理**：将支付平台、订单类型等映射数组迁移至 `application/config/constants.php` 或独立的 `OrderConfig` 类，避免 Model 文件膨胀。
3. **补充类型声明**：若 PHP 版本 ≥ 7.0，建议为方法参数与返回值添加类型提示（如 `public function get_list(array $where, int $page, int $pageSize): array`），提升 IDE 提示与静态检查能力。
> ⚠️ **局限性说明**：提供的代码在 `get_timing_order` 方法末尾被截断，未能完整审查该方法逻辑。若该方法涉及核心计费或状态更新，建议补充完整代码后二次审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780294836
|
1780294836
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
421
|
21
|
143
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `0bf1239e9 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `0bf1239e9035d033b17df3fcc23471b0ad332a59`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 14:19:34
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该 Model 承载了大量核心订单业务逻辑，功能覆盖较全。但存在典型的“上帝类”与“面条代码”特征：循环内频繁加载模型、缺乏数据库事务控制、SQL 拼接存在注入风险、大量硬编码魔术数字。整体可维护性、性能与安全性均有较大优化空间。
- **风险等级**：🔴 高
> ⚠️ **局限性说明**：提供的代码在 `get_timing_order()` 方法末尾被截断，无法对该方法完整性及后续逻辑进行评估。以下审查基于已提供部分。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_detail()` ~L138 | 未加载模型直接调用 `$this->ahead_yc_order_model->get_one()`，将触发 `Fatal Error`。且 `$order_data['before_payment']` 中 `$order_data` 变量未定义。 | 改为调用当前模型方法 `$this->get_one()`，或提前加载模型。修正变量名赋值。 | `$before_order_info_data = $this->get_one(['_id' => $order_info['before_order_id']]);`<br>`$order_info['before_payment'] = $before_order_info_data['_actual_pay'] ?? '';` |
| 🔴 严重 | `get_bill_goods_info()` ~L235 | 直接字符串拼接 SQL：`$sql = '_unique_key="' . $unique_key . '" ...'`。若 `$unique_key` 来源不可控，将导致严重 SQL 注入。 | 废弃字符串拼接，全面改用框架 Query Builder 或参数绑定。 | `$this->db->where('_unique_key', $unique_key)`<br>`->where_in('_status', [1, 4])`<br>`->or_where(['_pay_platform' => 10, '_status' => -1])`<br>`->get()->result_array();` |
| 🔴 严重 | `confirm_receipt()` ~L188 | 连续执行两次 `insert` 未包裹事务。若第二次插入失败，订单状态将停留在“已确认收货”而非“订单完成”，导致数据不一致。 | 使用数据库事务保证原子性。 | `$this->db->trans_start();`<br>`$this->ahead_yc_order_process_model->insert($data1);`<br>`$this->ahead_yc_order_process_model->insert($data2);`<br>`$this->db->trans_complete();`<br>`if ($this->db->trans_status() === FALSE) { $this->db->trans_rollback(); return ['code'=>false, 'msg'=>'操作失败']; }` |
| 🟠 警告 | `get_list()` ~L85 | 在 `foreach` 循环内调用 `$this->load->model()`。CI 框架虽会缓存已加载模型，但每次循环仍会触发文件包含与实例化检查，引发严重 N+1 查询与性能损耗。 | 将模型加载移至 `__construct()` 或方法顶部。复杂关联数据建议改用 `JOIN` 或批量查询。 | `public function __construct() { parent::__construct(); $this->load->model(['ahead_room_package_model', 'ahead_wares_package_model']); }` |
| 🟠 警告 | `close_room_after()` ~L215 | 循环内逐条执行 `update` 与 `insert`。当 `$order_data` 数据量较大时，极易触发数据库连接超时或锁表。 | 收集待更新/插入数据，使用 `update_batch()` 与 `insert_batch()` 批量处理。 | `$update_batch = []; $insert_batch = []; foreach($order_data as $v) { $update_batch[] = ['_id'=>$v['_id'], '_process'=>10]; $insert_batch[] = [...]; }`<br>`$this->db->update_batch($this->table_name, $update_batch, '_id');`<br>`$this->ahead_yc_order_process_model->insert_batch($insert_batch);` |
| 🟠 警告 | `encode_group_buying_order()` ~L435 | 使用 `md5()` 实现“加解密”。MD5 是单向哈希算法，不可逆，且已存在碰撞风险。方法命名与实际行为严重不符。 | 若为签名校验，改用 `hash_hmac('sha256', ...)`；若需可逆加解密，改用 `openssl_encrypt/decrypt`。 | `// 签名校验示例`<br>`return hash_equals(hash_hmac('sha256', $order_id, $this->encrypt), $sign);` |
| 🟠 警告 | `binding_order_check()` ~L465 | 使用未定义的属性 `$this->uid`。若父类或控制器未注入，将抛出 `Undefined property` 警告并导致逻辑中断。 | 通过方法参数显式传入 `$uid`，或在父类中明确定义并初始化。 | `public function binding_order_check($order_id, $sign, $uid)` |
| 🟡 建议 | 全局/类定义 | 类名 `Ahead_yc_order_model` 不符合 PSR-12 规范；顶部 `$CI = &get_instance();` 在 Model 中冗余；大量硬编码状态值（如 `1,2,3,17,18...`）散落各处。 | 类名改为 `AheadYcOrderModel`；移除顶部 `$CI`；将业务状态提取为 `const` 常量集中管理。 | `class AheadYcOrderModel extends Simple_model`<br>`const STATUS_PAID = 1; const STATUS_REFUNDING = 3;` |
| 🟡 建议 | `confirm_receipt()` ~L192 | `$aheaduname` 直接拼接至 `_process_msg` 入库。若前端未过滤，渲染时可能触发 XSS 攻击。 | 入库前进行安全过滤，或在视图层统一转义输出。 | `$data['_process_msg'] = htmlspecialchars($aheaduname, ENT_QUOTES, 'UTF-8') . ' - 已确认收货';` |
| 🟡 建议 | `get_bill_goods_info()` 整体 | 方法超过 300 行，混合了账单统计、商品合并、价格计算、退款处理等多重职责，违反单一职责原则 (SRP)。 | 拆分为独立方法：`calculateBillTotals()`, `mergeGoodsList()`, `formatBillItems()`。 | 建议按业务边界拆分，提升单元测试覆盖率与可读性。 |
## 3. 总结与行动建议
### 🔑 优先修复项（P0/P1）
1. **修复致命错误**：立即修正 `get_detail()` 中未加载模型直接调用及 `$order_data` 未定义的问题，避免线上 Fatal Error。
2. **消除 SQL 注入风险**：全面替换 `get_bill_goods_info()` 中的字符串拼接 SQL，改用框架提供的 Query Builder 或预处理语句。
3. **引入事务控制**：为 `confirm_receipt()`、`close_room_after()` 等涉及多表写入的操作添加 `$this->db->trans_start()/trans_complete()` 事务包裹，保障数据一致性。
### 🛠 后续重构与优化方向
1. **架构与性能优化**：
- 彻底移除循环内的 `$this->load->model()`，统一在构造函数或方法入口加载。
- 针对 `get_bill_goods_info()` 的 N+1 查询，建议将多次单表查询改写为 `JOIN` 或 `WHERE IN` 批量查询，减少数据库往返次数。
- 考虑将超长方法按职责拆分，或引入 `Service` 层处理复杂账单计算逻辑，保持 Model 仅负责数据持久化。
2. **安全与规范升级**：
- 废弃 `md5` 签名逻辑，迁移至 `hash_hmac` 或 JWT/非对称加密方案。
- 提取所有魔术数字至类常量（如 `PAY_PLATFORM_WECHAT = 1`），提升代码可读性与后期维护效率。
- 统一数组语法为短数组 `[]`，类名遵循 `PascalCase`，严格对齐 PSR-12。
3. **框架适配提示**：
- 基于目录结构推测本项目基于 **CodeIgniter 3.x** 架构。若 `phpci` 为内部定制框架，请确认其生命周期钩子、事务 API 及模型加载机制是否与 CI3 一致。若存在差异，请以官方文档为准调整 `$this->db->trans_*` 及 `$this->load->model()` 的调用方式。
- `throwError()` 非标准框架函数，建议替换为 `show_error()` 或抛出 `RuntimeException` 以便全局异常处理器捕获。
> 💡 **下一步建议**：在修复上述高危问题后，建议为核心方法（如 `get_bill_goods_info`、`confirm_receipt`）补充单元测试，并引入静态代码分析工具（如 PHPStan / Psalm）进行持续质量门禁管控。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780294774
|
1780294774
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
420
|
21
|
142
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `78d9e44f4 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `78d9e44f40e921f6156ec197bdcca9cf21cfe53a`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 14:18:07
---
## 1. 审查摘要
- **代码质量评分**：4.5 / 10 分
- **总体评价**：该 Model 承载了大量核心业务逻辑，但实现方式较为陈旧。存在明显的架构反模式（如文件顶层执行实例化）、性能瓶颈（循环内加载模型与 N+1 查询）、安全隐患（SQL 拼接、硬编码密钥）及职责过重（单方法超 300 行）。整体可维护性与扩展性较低，建议优先修复安全与事务问题，随后进行模块化重构。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_bill_goods_info` (~L230) | **SQL 注入风险**：直接使用字符串拼接构建查询条件 `_unique_key="' . $unique_key . '"`，若参数可控将导致注入。 | 严格使用框架查询构造器或参数绑定，禁止手动拼接 SQL 字符串。 | `$this->db->where('_unique_key', $unique_key);`<br>`$this->db->where_in('_status', [1, 4]);`<br>`$this->db->get($this->table_name)->result_array();` |
| 🔴 严重 | 文件顶部 (~L4-5) | **全局作用域执行**：`$CI = &get_instance();` 与 `$CI->load->model()` 在类外执行，文件被 `include` 时即触发，易引发致命错误或内存泄漏。 | 移除顶层代码，将依赖加载移至构造函数或按需加载。 | `public function __construct() { parent::__construct(); $this->load->model('Simple_model'); }` |
| 🟠 警告 | `get_list`, `get_detail` | **N+1 查询与循环内加载模型**：`foreach` 中频繁调用 `$this->load->model()` 并执行单条查询，数据量稍大即导致性能雪崩。 | 提前加载模型，收集关联 ID 后使用 `WHERE IN` 批量查询，再在内存中映射。 | `$ids = array_column($order_info, 'package_id');`<br>`$packages = $this->ahead_room_package_model->get_batch(['_id' => $ids]);`<br>`$map = array_column($packages, null, '_id');` |
| 🟠 警告 | `confirm_receipt`, `close_room_after` | **缺乏数据库事务**：连续执行 `update` 与多次 `insert`，若中途失败将导致订单状态与流水记录不一致。 | 使用框架事务机制包裹关键写操作，失败自动回滚。 | `$this->db->trans_start();`<br>`// 执行 insert/update`<br>`if ($this->db->trans_status() === FALSE) $this->db->trans_rollback();`<br>`else $this->db->trans_commit();` |
| 🟠 警告 | `encode_group_buying_order` | **密码学误用**：方法名含 `encode/decode`，但实际使用 `md5()`。MD5 为单向哈希，无法“解密”，且易受彩虹表攻击。 | 若用于签名校验，改名为 `verify_group_buying_sign` 并使用 `hash_hmac`；若需加解密，改用 `openssl_encrypt/decrypt`。 | `$sign = hash_hmac('sha256', $order_id, $this->encrypt);`<br>`return hash_equals($sign, $provided_sign);` |
| 🟡 建议 | `get_detail` (~L150) | **隐式依赖未定义属性**：`$this->uid` 在当前类中未声明，依赖父类或全局状态，降低方法可测试性。 | 将用户 ID 作为显式参数传入，或从 Session/Request 对象中安全获取。 | `public function binding_order_check($order_id, $sign, $uid = null)` |
| 🟡 建议 | 全局常量/属性 | **命名不规范与冗余**：`ORDRE_WARES_TPE` 拼写错误；`pay_platform_arr` 与 `ORDER_PAY_PLATFORM_ARR` 数据重复；属性全为 `public`。 | 遵循 PSR-12 使用 `const` 定义不可变配置，属性设为 `protected`，修正拼写错误。 | `protected const PAY_PLATFORM_MAP = [1 => '微信', ...];`<br>`protected const ORDER_WARES_TYPE = 2;` |
| 🟡 建议 | `get_bill_goods_info` | **违反单一职责原则 (SRP)**：单方法超 300 行，混合了数据查询、金额计算、商品合并、视图格式化等多重职责。 | 拆分为独立方法：`fetchBillOrders()`, `calculateBillTotals()`, `mergeGoodsDetails()`, `formatBillResponse()`。 | 提取私有方法，主方法仅负责流程编排与数据组装。 |
## 3. 总结与行动建议
### 🔑 优先修复项（P0/P1）
1. **修复 SQL 注入**：立即替换 `get_bill_goods_info` 中的字符串拼接查询，全面改用框架 Query Builder 或预处理语句。
2. **引入数据库事务**：为 `confirm_receipt` 和 `close_room_after` 添加事务包裹，确保订单状态与流水记录的原子性。
3. **消除循环内查询**：重构 `get_list` 与 `get_detail`，采用“收集 ID → 批量查询 → 内存映射”模式，预计可降低 70%+ 数据库交互耗时。
### 🛠 后续重构与优化方向
1. **架构解耦**：
- 将硬编码的加密串 `$encrypt`、支付平台映射数组等移至 `config/` 或 `.env` 文件中。
- 移除文件顶层的 `$CI = &get_instance();`，严格遵循框架生命周期。
2. **方法拆分与 DTO 化**：
- `get_bill_goods_info` 建议拆分为 3~4 个私有方法，并考虑引入 `OrderBillDTO` 对象承载计算结果，避免数组键名魔术字符串满天飞。
3. **规范与安全升级**：
- 统一类名与常量命名（如 `AheadYcOrderModel`、`PAY_PLATFORM_MAP`）。
- 将 `md5` 签名逻辑升级为 `hash_hmac('sha256', ...)`，提升防篡改能力。
- 为所有公开方法补充 PHPDoc 类型声明（如 `@param int $order_id`, `@return array`），便于 IDE 静态分析与后续迁移至 PHP 8+。
> ⚠️ **局限性说明**：您提供的代码在 `get_timing_order` 方法末尾被截断，未能完整审查该方法逻辑。若该方法包含关键业务分支或数据库操作，请补充完整代码以便进行二次评估。
> 📖 **框架适配提示**：基于目录结构（`system/`, `application/`）及 `$this->load->model()` 等语法，本审查默认代码基于 **CodeIgniter 3.x** 架构。若 `phpci` 为内部定制框架，请对照其官方文档调整 `trans_start()`、`where()` 等底层 API 的具体调用方式。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780294687
|
1780294687
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
419
|
21
|
141
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `aa91fcb84 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `aa91fcb8438c82a64a84133815c1a22bf980f07d`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-01 14:14:02
---
## 1. 审查摘要
- **代码质量评分**：4/10 分
- **总体评价**：该 Model 承载了订单列表、详情、账单统计、状态流转等核心业务逻辑，功能覆盖较全。但存在严重的 **N+1 查询性能瓶颈**、**SQL 注入隐患**、**事务缺失导致的数据不一致风险**，以及大量硬编码配置与职责过载问题。代码结构偏向“脚本化”，未充分发挥面向对象与框架查询构建器的优势。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_bill_goods_info` | **SQL 注入风险**：使用字符串拼接构造查询条件 `_unique_key="' . $unique_key . '"`，未使用参数绑定或查询构建器过滤，恶意输入可导致数据库越权查询。 | 严格使用框架提供的查询构建器或参数绑定方法，禁止直接拼接用户/业务输入到 SQL 字符串中。 | `$this->db->where('_unique_key', $unique_key)->where_in('_status', [1,4])->get($this->table_name)->result_array();` |
| 🔴 严重 | `get_detail` | **逻辑错误/未定义调用**：`$this->ahead_yc_order_model->get_one(...)` 当前类即为该模型，直接调用自身别名极易引发 `Fatal Error` 或无限递归。 | 替换为当前实例方法 `$this->get_one()`。若需跨模型调用，应显式 `$this->load->model()` 后使用新对象。 | `$before_order_info_data = $this->get_one(['_id' => $order_info['before_order_id']]);` |
| 🔴 严重 | `confirm_receipt` | **数据一致性风险**：连续执行两次 `insert` 更新订单流程状态，未包裹数据库事务。若第二次插入失败，订单将卡在“已确认收货”状态，无法自动完成。 | 使用框架事务机制包裹连续写入操作，失败时自动回滚。 | `见下方事务示例` |
| 🟠 警告 | `get_list`, `get_detail`, `get_bill_goods_info` | **N+1 查询与性能瓶颈**：在 `foreach` 循环内频繁 `$this->load->model()` 并执行单条查询。模型重复加载与逐条查询将导致数据库连接数飙升，响应时间呈指数级增长。 | 模型加载移至方法顶部或构造函数；关联数据改用 `JOIN` 或 `WHERE IN` 批量查询，在内存中映射。 | `$ids = array_column($order_info, 'package_id');<br>$this->load->model('ahead_room_package_model');<br>$packages = $this->ahead_room_package_model->get_by_ids($ids);` |
| 🟠 警告 | 类属性定义 | **敏感信息硬编码**：`public $encrypt = "Vs!Fs7VT";` 直接暴露在源码中，易通过版本控制泄露，且多环境部署时无法差异化配置。 | 移至配置文件（如 `config/config.php`）或 `.env`，通过 `$this->config->item()` 读取。 | `$this->encrypt_key = $this->config->item('order_sign_secret');` |
| 🟠 警告 | `encode_group_buying_order` | **密码学误用**：使用 `md5()` 实现“加密/解密”。MD5 是单向哈希算法，**无法解密**。当前逻辑实为签名校验，但命名与实现严重误导后续维护者。 | 若需加解密，改用 `openssl_encrypt/decrypt`；若仅为防篡改校验，建议重命名并使用 `hash_hmac` + `hash_equals`。 | `return hash_equals(hash_hmac('sha256', $order_id, $this->config->item('secret')), $sign);` |
| 🟡 建议 | 全局/类定义 | **违反 OOP 与 PSR-12**：文件顶部 `$CI = &get_instance();` 脱离类作用域；类名 `Ahead_yc_order_model` 使用下划线；大量业务字典数组定义为 `public` 属性。 | 移除全局 `$CI`；类名改为 `AheadYcOrderModel`；字典配置移至 `config/` 目录或定义为 `private const`。 | `class AheadYcOrderModel extends Simple_model { ... }` |
| 🟡 建议 | `binding_order_check` | **隐式依赖风险**：直接使用 `$this->uid` 但未在类中声明或初始化，强依赖父类或全局上下文，易触发 `Undefined property` 警告且不利于单元测试。 | 显式声明属性或在方法签名中传入 `$uid`，增加类型与空值校验。 | `public function binding_order_check($order_id, $sign, $uid = null) { $uid = $uid ?? $this->uid ?? 0; ... }` |
| 🟡 建议 | `get_bill_goods_info` | **方法职责过重**：该方法超 300 行，混合了数据查询、金额统计、商品合并、格式化展示、业务规则判断，严重违反单一职责原则（SRP）。 | 拆分为 `fetchBillOrders()`, `calculateBillMetrics()`, `mergeGoodsList()` 等独立方法，提升可测试性。 | 重构建议见第 3 部分 |
**🔴 严重问题代码示例（事务包裹）：**
```php
public function confirm_receipt($order_info, $aheaduid, $aheaduname, $star = 5)
{
// ... 前置校验逻辑保持不变 ...
$this->db->trans_start(); // 开启事务
$data = [
'_order_id' => $order_id,
'_process' => 7,
'_process_msg' => $aheaduname . ' - 已确认收货',
'_process_time' => time(),
'_ahead_user_id' => $aheaduid,
'_ahead_user_name' => $aheaduname,
'_star' => $star
];
$this->ahead_yc_order_process_model->insert($data);
$data['_process'] = 8;
$data['_process_msg'] = '订单完成';
$this->ahead_yc_order_process_model->insert($data);
$this->db->trans_complete(); // 提交事务
if ($this->db->trans_status() === FALSE) {
$this->db->trans_rollback();
return ['code' => false, 'msg' => '订单状态更新失败，已回滚'];
}
// ... 推送消息逻辑 ...
return ['code' => true, 'msg' => '确认收货成功'];
}
```
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复 SQL 注入**：立即替换 `get_bill_goods_info` 中的字符串拼接查询，全面启用查询构建器或参数绑定。
2. **补充数据库事务**：为 `confirm_receipt`、`bindingOrder` 等涉及多表/多行写入的方法添加 `$this->db->trans_start()/complete()` 机制，保障资金与订单状态强一致性。
3. **消除 N+1 查询**：将循环内的模型加载与单条查询重构为批量查询（`WHERE IN`）或 `LEFT JOIN`，预计可将列表/详情接口响应时间降低 60% 以上。
4. **修正模型自引用**：将 `get_detail` 中的 `$this->ahead_yc_order_model->get_one()` 改为 `$this->get_one()`，避免潜在运行时崩溃。
### 🛠 后续重构与优化方向
- **配置与常量分离**：将 `$pay_id_arr`、`$type_arr` 等业务字典迁移至 `config/order_config.php`，通过 `$this->config->item()` 读取，保持 Model 纯净。
- **方法拆分与单一职责**：`get_bill_goods_info` 建议拆分为三层：
- `Data Access Layer`：仅负责 `JOIN` 查询原始订单与商品数据。
- `Business Logic Layer`：负责金额计算、优惠券抵扣、积分规则处理。
- `Presentation Layer`：负责字段格式化、数组结构组装（可移至 Service 或 Helper）。
- **安全加固**：废弃 `md5` 签名逻辑，改用 `hash_hmac('sha256', $data, $key, true)`；敏感配置统一走环境变量或加密配置中心。
- **规范对齐**：遵循 PSR-12 重命名类与方法（`camelCase`），统一使用 `private/protected` 控制属性可见性，移除文件级 `$CI = &get_instance();`。
> ⚠️ **局限性说明**：提供的代码在 `get_timing_order` 方法末尾被截断（`return ['success' => false, 'msg' => '订单`），无法评估该方法的完整逻辑、异常处理及返回值结构。建议补充完整代码以便进行闭环审查。
>
> 📖 **框架适配注记**：当前代码结构、`$CI = &get_instance()`、`$this->load->model()` 及 `$this->db` 事务语法高度符合 **CodeIgniter 3** 规范。若 `phpci` 为内部定制框架，请核对上述事务与查询构建器方法名是否与官方文档一致，核心架构建议（事务、防注入、N+1优化）在绝大多数 PHP MVC 框架中通用。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780294443
|
1780294443
|
0
|
0
|
0
|
0
|
Edit
Delete
|