|
174
|
21
|
8
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `cdacd84f9 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `cdacd84f9016e1024221f4b7a4666b5c44d76979`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 11:30:11
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该 Model 承载了复杂的套餐查询、价格计算、社区模式过滤及多端展示逻辑，业务覆盖全面。但存在**严重的 SQL 注入风险**、**数组引用操作逻辑缺陷**、**多处重复代码**及**框架使用不规范**等问题。部分核心逻辑未做边界保护，且硬编码与魔法数字较多，可维护性与安全性亟待提升。
- **风险等级**：🔴 高（存在直接拼接 SQL 的注入漏洞、关键过滤逻辑失效风险）
> 📌 **框架说明**：代码特征（`get_instance()`、`$this->load->model()`、`$this->db->query()`）高度符合 **CodeIgniter 3** 规范。若 `phpci` 为贵司内部定制框架，请结合其官方文档对底层 DB/Model 行为进行适配验证。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_package_list()`<br>`get_hot_sale_top5()`<br>约 450~520 行 | **SQL 注入漏洞**：直接使用字符串拼接构造 SQL，未对 `$param['special_merchant_id']`、`$shop_name`、`$shop_id` 进行类型转换或转义。攻击者可构造恶意参数篡改查询逻辑或拖库。 | 1. 强制类型转换 `(int)`<br>2. 使用 CI3 Query Builder 或 `$this->db->escape()`<br>3. 避免手动拼接 `LIKE` 和 `IN` | ```php<br>// 错误<br>$sql .= " AND `shop`.`_name` like '%" . $shop_name . "%'";<br><br>// 正确<br>$shop_name = $this->db->escape_like_str($shop_name);<br>$sql .= " AND `shop`.`_name` LIKE '%{$shop_name}%'";<br>``` |
| 🔴 严重 | `get_package_price_list()`<br>`get_screen_list()`<br>约 110/280 行 | **`unset($row)` 逻辑失效**：在 `foreach ($list as &$row)` 中使用 `unset($row)` 仅销毁引用变量，**不会从原数组中移除元素**，导致无效数据仍被返回。 | 使用键值遍历并 `unset($list[$key])`，或改用 `array_filter()` | ```php<br>foreach ($list as $key => &$row) {<br> if ($book_arrival_time < $order_end_time) {<br> unset($list[$key]);<br> continue;<br> }<br>}<br>``` |
| 🟠 警告 | 全局顶部<br>`$CI = &get_instance();` | **全局实例化 CI 对象**：在类外部直接调用 `get_instance()` 会在文件被 `include` 时立即执行，若未处于 CI 生命周期内将导致 Fatal Error。且 Model 内部已可通过 `$this` 访问 Loader/DB。 | 删除顶部代码，在方法内部按需使用 `$this->load` 或 `$this->db`。若必须使用 CI 实例，应在方法内局部获取。 | ```php<br>// 删除顶部<br>$CI = &get_instance();<br>$CI->load->model('Simple_model');<br><br>// 类内直接使用<br>$this->load->model('Ahead_vip_model');<br>``` |
| 🟠 警告 | 多个方法内<br>`$this->load->model()` | **重复加载模型**：同一模型在多个方法甚至同一方法内被反复 `load`，增加 I/O 开销。CI3 的 `load->model()` 虽会缓存，但频繁调用仍影响可读性与性能。 | 将常用模型移至 `__construct()` 统一加载，或使用懒加载+静态缓存。 | ```php<br>public function __construct() {<br> parent::__construct();<br> $this->load->model(['Ahead_vip_model', 'Ahead_yc_merchant_model', 'ahead_room_package_model']);<br>}<br>``` |
| 🟠 警告 | `get_package_price_list()`<br>`get_screen_list()` | **DRY 原则违反**：社区模式时间过滤逻辑（`$book_arrival_time` 计算、包厢结束时间判断）在两个方法中完全重复。后续修改易遗漏。 | 抽取为私有方法 `private function _check_community_package_visibility($list, $params)` | 见下方重构建议 |
| 🟡 建议 | 全局多处 | **命名与规范不一致**：类名 `Ahead_room_package_infos_model` 为蛇形，方法名混用驼峰(`getPackageInfoByIds`)与蛇形；魔法数字(`4`, `2`, `100`, `86400`)散落；保留 `//edit by nan` 等提交注释。 | 遵循 PSR-12：类名 PascalCase，方法名 camelCase；提取常量；清理历史注释。 | ```php<br>const SCREEN_RENEW_TYPE = 4;<br>const SECONDS_PER_DAY = 86400;<br>const DISCOUNT_DIVISOR = 100; // 原 /10/10<br>``` |
| 🟡 建议 | `get_package_by_fields()`<br>`get_book_package_list()` | **状态污染风险**：`$this->set_table_name()` 与 `$this->set_select_db()` 修改了 Model 全局状态。若并发请求或后续链式调用未正确恢复，会导致数据错乱。 | 使用局部变量或 CI3 的 `clone` 机制；确保 `try-finally` 或显式恢复状态。 | ```php<br>$originalTable = $this->table_name;<br>$this->set_table_name($table_name . ' info');<br>// ... 查询逻辑 ...<br>$this->set_table_name($originalTable); // 必须恢复<br>``` |
---
## 3. 总结与行动建议
### 🔑 优先修复项（P0/P1）
1. **彻底修复 SQL 注入**：所有 `$this->db->query($sql)` 必须替换为 Query Builder (`$this->db->select()->from()->where()->get()`) 或严格使用 `$this->db->escape()`。禁止直接拼接用户输入。
2. **修正数组过滤逻辑**：全局搜索 `unset($row)` 在 `foreach` 引用中的用法，统一改为 `unset($array[$key])` 或使用 `array_filter()`，确保数据过滤生效。
3. **清理全局 `$CI` 实例**：移除文件顶部的 `get_instance()`，避免框架初始化异常。
### 🛠 后续重构与优化方向
1. **逻辑抽取与 DRY**：将 `get_package_price_list` 与 `get_screen_list` 中重复的“社区模式时间校验”、“套餐价格折扣计算”、“商品口味拼接”抽取为独立的 `private` 辅助方法，降低维护成本。
2. **折扣计算语义化**：当前 `$rate / 10 / 10` 逻辑隐晦，建议统一在配置层或常量中定义折扣乘数（如 `0.95`），并在计算时直接相乘，避免连续除法带来的浮点精度隐患。
3. **模型状态隔离**：若 `set_select_db()` 为自定义多库切换方法，建议封装为带回调的上下文管理器，确保执行完毕后自动切回默认库，防止请求间状态泄漏。
4. **规范与静态分析**：
- 启用 `PHP_CodeSniffer` (PSR-12) 与 `PHPStan` 进行自动化检查。
- 将魔法数字提取为类常量，提升可读性。
- 移除所有 `//edit by xxx` 注释，依赖 Git 历史追踪变更。
> 💡 **局限性说明**：提供的代码在 `get_book_package_list_group_by_shop()` 处被截断，未能审查完整逻辑。若该方法涉及分页、排序或复杂 JOIN，请补充完整代码以便进行针对性评估。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779161411
|
1779161411
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
176
|
21
|
9
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `aa880e506 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `aa880e50672277db9650328ede3b2b261906d202`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 13:20:10
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了较为复杂的门店业务逻辑，但存在多处严重的安全隐患（SQL注入）、状态管理缺陷（类属性污染）、MVC 职责越界以及性能瓶颈（N+1查询、PHP层距离计算）。部分代码未遵循 CI 框架生命周期规范，且命名与硬编码缺乏一致性。需进行系统性重构。
- **风险等级**：🔴 高
> 📌 **框架说明**：根据目录结构（`system/`, `application/`）及语法特征（`get_instance()`, `$this->load->model()`, `$this->db->`），判定该代码基于 **CodeIgniter 3.x** 架构。以下审查与建议均基于 CI3 最佳实践。若 `phpci` 为内部定制框架，请对照其官方文档调整组件调用方式。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_community_shop_list` 约第 280 行 | **变量名拼写错误**：使用未定义的 `$param['bookFrom']`，实际参数名为 `$params`。将导致 PHP Notice 且业务逻辑失效。 | 修正为 `$params['bookFrom']`，并增加类型校验。 | `if (!empty($params['bookFrom'])) { ... }` |
| 🔴 严重 | `get_date_shop_no_business_time` 约第 560 行 | **类属性状态污染**：使用 `$this->shop_no_business_time` 累加数据。同一请求多次调用该方法会导致数据无限叠加，引发内存泄漏与逻辑错乱。 | 改为局部变量，方法结束后自动销毁。 | `$shop_no_business_time = [];`<br>`// 后续逻辑中替换 $this->shop_no_business_time` |
| 🔴 严重 | 多处 (`get_community_shop_list`, `get_shop_list_order_by_distance` 等) | **SQL 注入漏洞**：`FIND_IN_SET({$operational_scene}, ...)` 与 `LIKE '%{$shop_name}%'` 直接拼接用户输入，未做转义或参数化。 | 使用 CI 查询构建器绑定参数，或严格过滤输入类型。 | `$this->db->where("FIND_IN_SET(?, shop._operational_scene)", (int)$operational_scene);`<br>`$shop_name = $this->db->escape_like_str($shop_name);` |
| 🟠 警告 | 文件顶部 第 8-9 行 | **违反框架生命周期**：在文件作用域直接调用 `get_instance()` 加载模型。CI 尚未完全初始化时会引发 Fatal Error。 | 移除文件顶部代码，统一在 `__construct()` 中加载依赖。 | `public function __construct() { parent::__construct(); $this->load->model('Simple_model'); }` |
| 🟠 警告 | `getAliAuthInfo` 约第 180 行 | **变量拼写错误**：`$this->db->select($filed)` 中 `$filed` 未定义，应为 `$fields`。 | 修正变量名，避免查询字段为空。 | `$this->db->select($fields)` |
| 🟠 警告 | `get_shop_list_order_by_distance` 约第 350 行 | **原始 SQL 拼接风险**：`_id in (...)` 与 `FIELD()` 循环拼接未校验数据类型，若传入非数字将破坏 SQL 语法或引发注入。 | 使用 `array_map('intval', $arr)` 过滤，并改用 CI Query Builder 或严格转义。 | `$safe_ids = implode(',', array_map('intval', $shop_id_arr_order_distance));`<br>`$sql .= " AND _id IN ({$safe_ids})";` |
| 🟠 警告 | 多个列表方法 (`get_info`, `get_community_shop_list` 等) | **N+1 查询性能瓶颈**：在 `foreach` 循环中逐条调用 `get_miniprogram_consumption_methods` 等模型方法，数据量大时数据库压力剧增。 | 提取 ID 列表批量查询，或引入 Redis/内存缓存。 | `$shop_ids = array_column($shop_data, 'shop_id');`<br>`$configs = $this->ahead_shop_config_second_model->get_batch_by_shop_ids($shop_ids);` |
| 🟡 建议 | 全局 | **MVC 职责越界**：Model 中直接调用 `throwError()` / `showErrorView()`。Model 应仅负责数据存取，视图与异常响应应由 Controller 处理。 | 改为抛出 `Exception` 或返回错误码，由 Controller 统一拦截处理。 | `if (empty($data)) { throw new \Exception('门店错误', 404); }` |
| 🟡 建议 | 全局 | **命名规范与魔法数字**：方法名混用驼峰(`getAliAuthInfo`)与下划线；大量使用 `86400`, `1`, `-1` 等硬编码。 | 统一使用下划线命名法（CI 规范）；定义类常量提升可读性。 | `const STATUS_ACTIVE = 1;`<br>`const TEST_SHOP_FLAG = -1;`<br>`public function get_ali_auth_info($condition)` |
| 🟡 建议 | `get_cache_shop_data` 约第 100 行 | **缓存序列化隐患**：`json_encode($shop_data)` 未处理失败情况，且 `$redis->close()` 可能破坏连接池复用。 | 增加 JSON 编码校验；使用 CI 内置 Cache 驱动管理连接。 | `if ($json === false) { log_message('error', 'Redis cache encode failed'); return $shop_data; }` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复 SQL 注入**：立即替换所有字符串拼接的 SQL 条件，改用 CI Query Builder 的 `where()`, `where_in()`, `like()` 或参数化绑定。特别是 `FIND_IN_SET` 和 `LIKE` 场景。
2. **消除状态污染**：将 `get_date_shop_no_business_time` 中的 `$this->shop_no_business_time` 改为局部变量，避免并发或多次调用时的数据交叉污染。
3. **修正致命拼写错误**：修复 `$param` vs `$params` 及 `$filed` vs `$fields`，防止运行时崩溃。
4. **规范框架初始化**：移除文件顶部的 `get_instance()` 调用，将依赖模型加载移至 `__construct()`。
### 🛠 后续重构与优化方向
- **架构分层**：严格遵循 MVC。Model 仅返回数据或抛出 `Exception`，将 `throwError`/`showErrorView` 移至 Controller 或全局异常处理器。
- **性能优化**：
- **批量查询**：将循环内的单条查询改为 `WHERE IN` 批量获取，或使用 Redis Hash 缓存门店配置。
- **距离计算下沉**：PHP 层循环计算经纬度距离（Haversine）消耗 CPU。建议在 MySQL 中使用空间函数或 `ST_Distance_Sphere`，或在查询时直接返回排序结果。
- **代码规范**：
- 统一方法命名为 `snake_case`。
- 将 `public` 属性改为 `protected`，避免外部随意篡改。
- 提取魔法数字为类常量（如 `const CACHE_TTL = 86400;`）。
- **缓存策略升级**：建议弃用自定义 `get_aliyun_redis_conn()`，改用 CI 官方 `Cache` 驱动（`$this->load->driver('cache', ['adapter' => 'redis'])`），以获得更好的连接池管理与序列化支持。
> 💡 **提示**：若需对 `get_shop_list_order_by_distance` 中的 `FIELD()` 排序进行深度优化，可考虑在数据库层面使用临时表或 `CASE WHEN` 语句，避免在 PHP 中动态拼接超长 SQL。如有特定业务约束无法修改，请确保所有传入参数经过 `intval()` 或白名单过滤。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779168010
|
1779168010
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
178
|
21
|
10
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `4de14a2cf ## 自动代码审查报告
**分支**: pay-260519
**提交**: `4de14a2cff5bc6855ae3992c46f2b1b3e911c7bc`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 13:21:45
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码整体实现了门店查询、缓存、距离排序及多端适配等核心业务，但存在明显的**安全漏洞**（SQL注入）、**线上阻断风险**（遗留调试代码）及**性能瓶颈**（N+1查询、PHP层全量排序）。代码结构高度耦合，重复逻辑较多，未充分利用框架的查询构造器与缓存机制，可维护性与扩展性有待提升。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_shop_list_order_by_distance` (~L560) | **SQL 注入漏洞**：`$shop_name` 未经过滤直接拼接到 SQL 字符串中，攻击者可构造恶意输入破坏查询或窃取数据。 | 使用框架查询构造器或参数绑定，禁止字符串拼接。 | `$this->db->like('_name', $shop_name, 'both');` |
| 🔴 严重 | `get_shop_list_order_by_distance` (~L585) | **线上阻断风险**：遗留 `echo $this->db->last_query(); exit;`，一旦部署将直接中断所有请求。 | 立即删除该行，调试信息应通过日志记录而非直接输出并终止。 | 删除 `echo...exit;` 代码块 |
| 🔴 严重 | 文件顶部 (~L4) | **全局状态污染**：在类外部执行 `$CI = &get_instance();` 并加载模型，违反框架生命周期，易导致依赖冲突或内存泄漏。 | 移除文件顶部代码，依赖加载统一移至 `__construct()` 中。 | 删除顶部 `$CI = &get_instance();` 相关代码 |
| 🟠 警告 | `get_community_shop_list` 等多处 | **N+1 查询性能瓶颈**：在 `foreach` 循环中逐行调用 `get_miniprogram_consumption_methods()`，门店数量多时将产生海量数据库请求。 | 收集所有 `shop_id` 后使用 `where_in` 批量查询，或在主 SQL 中 `JOIN` 关联配置表一次性获取。 | `$ids = array_column($shop_data, 'shop_id'); $configs = $this->config_model->get_batch($ids);` |
| 🟠 警告 | `get_id_by_distance` (~L230) | **内存与计算瓶颈**：全量拉取门店数据后在 PHP 中循环计算距离并排序，数据量稍大即触发 OOM 或超时。 | 将距离计算下推至数据库层（MySQL 空间函数或 `ORDER BY` 近似公式），或使用 Redis GEO。 | `ORDER BY (latitude - ?)^2 + (longitude - ?)^2 ASC` |
| 🟠 警告 | `get_community_shop_list` (~L430) | **迭代安全隐患**：在 `foreach` 中直接使用 `unset($shop_data[$k])` 过滤数据，可能导致数组键断裂或后续逻辑索引错乱。 | 使用 `array_filter` 进行安全过滤，或先收集需剔除的 ID 再统一处理。 | `$shop_data = array_values(array_filter($shop_data, fn($v) => !empty($v['book_operational_scene'])));` |
| 🟡 建议 | 全文多处 | **违反 DRY 原则**：坐标转换、地址拼接、运营场景解析、营业时间格式化等逻辑在 5+ 个方法中重复编写。 | 抽取为私有辅助方法（如 `private function formatShopDisplayData(array $shop, string $from)`）。 | 统一封装处理逻辑，主方法仅负责查询与调用格式化。 |
| 🟡 建议 | 全文多处 | **硬编码魔法值**：`$special_city_id = [2, 3, 4, 5, 34, 35]` 在多处重复出现，后期维护极易遗漏。 | 提取为类常量或独立配置文件。 | `const SPECIAL_CITY_IDS = [2, 3, 4, 5, 34, 35];` |
| 🟡 建议 | `get_cache_shop_data` (~L60) | **缓存序列化风险**：`json_encode($shop_data)` 未处理非 UTF-8 字符或资源类型，且 `set` + `expireAt` 为两次网络请求。 | 使用 `JSON_UNESCAPED_UNICODE`，或改用框架缓存驱动/Redis `SETEX` 原子操作。 | `$redis->setex($redis_key, 86400, json_encode($shop_data, JSON_UNESCAPED_UNICODE));` |
| 🟡 建议 | `get_shop_list_order_by_distance` (~L555) | **类型安全缺失**：`$satisfy_shop_ids` 直接 `implode` 拼接，若包含非数字字符串将导致 SQL 语法错误。 | 强制类型转换或过滤，确保仅传入合法 ID。 | `$safe_ids = array_map('intval', array_filter($satisfy_shop_ids, 'is_numeric'));` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题（P0/P1）
1. **立即移除调试代码**：删除 `get_shop_list_order_by_distance` 中的 `echo ... exit;`，避免线上服务雪崩。
2. **修复 SQL 注入**：将 `get_shop_list_order_by_distance` 中的原生 SQL 拼接全面替换为 CI 查询构造器（Query Builder）或预处理语句，特别是 `LIKE` 和 `IN` 条件。
3. **解决 N+1 查询**：对 `get_community_shop_list`、`get_shop_list_order_by_distance` 等列表接口，将循环内的单条查询改为批量查询（`where_in`）或 SQL `JOIN`，预计可降低 70%+ 数据库负载。
### 🛠 后续重构与优化方向
1. **逻辑下沉与 DRY 重构**：
- 创建 `private function processShopForDisplay(array $shopData, string $source = 'web')`，统一处理：坐标转换、距离计算、地址拼接、运营场景映射、营业时间格式化。
- 将重复的 `$this->load->model()` 移至类顶部或构造函数，避免运行时重复加载。
2. **距离排序架构升级**：
- 若门店数据量 > 1000，强烈建议废弃 PHP 层 `get_distance()` 循环。改用 MySQL `ST_Distance_Sphere` 或 Redis `GEODIST` 实现数据库/缓存层排序，性能可提升 10 倍以上。
3. **框架规范适配**：
- 注：当前代码结构高度符合 **CodeIgniter 3** 规范。若 `phpci` 为内部定制框架，请确认其是否兼容 CI3 的 `DB_driver` 与 `load` 机制。建议统一使用框架提供的缓存组件（如 `$this->cache->redis->get()`）替代原生 `get_aliyun_redis_conn()`，以便统一连接池管理与异常捕获。
- 为所有公开方法添加 PHPDoc `@return` 类型声明，并逐步引入 PHP 7.4+ 类型提示（如 `public function get_info(array $param): array`）。
4. **安全与健壮性加固**：
- 对 `$param` 输入增加统一过滤层（如 `filter_var` 或框架验证器），避免依赖零散的 `intval()`/`trim()`。
- 敏感操作（如 `add_shop_after`）建议加入数据库事务包裹，确保多表插入的原子性。
> 💡 **局限性说明**：由于未提供 `Simple_model` 基类、全局辅助函数（`locationTurnTxMap`, `get_distance`, `throwError` 等）及数据库表结构，部分业务逻辑的边界条件验证依赖于假设。建议在完整上下文中补充单元测试覆盖核心查询与缓存逻辑。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779168105
|
1779168105
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
179
|
21
|
11
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `e0309e97c ## 自动代码审查报告
**分支**: pay-260519
**提交**: `e0309e97c19e9542fbbf526e45cc4d0aff8b24e8`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 13:22:54
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该 Model 承载了大量门店业务逻辑，功能覆盖较全，但存在明显的架构与编码规范问题。核心隐患集中在 **SQL 注入风险、N+1 查询性能瓶颈、框架生命周期误用** 以及 **变量拼写错误**。代码整体偏向“脚本式”堆砌，缺乏面向对象设计原则（如单一职责、依赖注入）的约束，后期维护与扩展成本较高。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 全局/第3-4行 | 文件顶部直接调用 `get_instance()` 并加载 `Simple_model`。此代码在文件被 `include/require` 时即执行，而非实例化时，严重违反 CI/PHPCI 框架生命周期，易导致类未定义或单例污染。 | 移除全局调用。模型依赖应通过 CI 自动加载配置或移至 `__construct()` 中。 | `// 删除顶部这两行<br>$CI = &get_instance();<br>$CI->load->model('Simple_model');` |
| 🔴 严重 | `get_shop_list_order_by_distance` (~L750) | 原始 SQL 拼接未对 `$shop_name`、`$satisfy_shop_ids`、`$city_id` 进行转义或参数绑定，存在高危 **SQL 注入** 漏洞。 | 使用 CI 查询构建器（Query Builder）或 `$this->db->escape()` / `escape_like_str()` 进行安全过滤。 | `$safe_name = $this->db->escape_like_str($shop_name);<br>$sql .= " AND _name LIKE '%{$safe_name}%'";` |
| 🔴 严重 | `get_community_shop_list` (~L630) | 变量名拼写错误：`if (!empty($param['bookFrom']))`，实际入参为 `$params`。将导致 `Undefined variable` 警告，且后续 JOIN 逻辑永远不执行。 | 修正为 `$params['bookFrom']`，并建议开启 `error_reporting(E_ALL)` 在开发环境拦截此类错误。 | `if (!empty($params['bookFrom'])) { ... }` |
| 🟠 警告 | `get_community_shop_list` & `get_shop_list_order_by_distance` | **N+1 查询性能瓶颈**：在 `foreach` 循环中逐条调用 `$this->ahead_shop_config_second_model->get_miniprogram_consumption_methods()`。若返回 100 家门店，将产生 100+ 次额外 DB 请求。 | 提取所有 `shop_id` 数组，编写批量查询方法 `get_batch_methods($merchant_id, $shop_ids)`，在循环外一次性获取，再在内存中映射。 | `$ids = array_column($shop_data, 'shop_id');<br>$batch_data = $this->ahead_shop_config_second_model->get_batch_methods($merchant_id, $ids);<br>foreach ($shop_data as &$v) { $config = $batch_data[$v['shop_id']] ?? []; ... }` |
| 🟠 警告 | `get_date_shop_no_business_time` (~L840) | 循环步长依赖外部模型属性 `$this->ahead_shop_book_time_info_model->min_minute_unit_time`。若该值为 `0` 或未初始化，将导致 **死循环** 耗尽 CPU/内存。 | 增加步长安全校验，或提取为类常量。 | `$step = max(1, $this->ahead_shop_book_time_info_model->min_minute_unit_time);<br>for ($i = 0; $i < $business_from; $i += $step) { ... }` |
| 🟠 警告 | 全局属性 `$shop_no_business_time` | 使用 `public $shop_no_business_time = [];` 累积状态。在并发请求或多次调用时会产生 **数据污染**，且破坏方法纯函数特性。 | 改为方法局部变量返回，或封装为独立 DTO/Value Object。 | `// 移除 public 属性<br>public function get_date_shop_no_business_time(...) {<br> $no_business_times = []; // 局部变量<br> // ... 逻辑<br> return ['result' => $result, 'no_business_times' => $no_business_times];<br>}` |
| 🟡 建议 | 全文 | 方法命名风格不统一（如 `getAliAuthInfo` 驼峰 vs `get_list_for_search` 下划线），不符合 PSR-12 规范。 | 统一使用 `camelCase` 命名方法，属性使用 `snake_case`。 | `public function getAliAuthInfo()` → `public function getAliAuthInfo()` (保持) 或 `get_ali_auth_info()` (统一) |
| 🟡 建议 | `get_cache_shop_data` | Redis 过期时间使用 `expireAt` 配合 `time()+86400` 非原子操作。若 `set` 成功但 `expireAt` 失败，将产生永久缓存。 | 使用原子命令 `setex` 或 `set($key, $val, ['ex' => 86400])`。 | `$redis->setex($redis_key, 86400, json_encode($shop_data));` |
| 🟡 建议 | `get_list_by_id` | `explode(",", $shop_id)` 在传入空字符串时会返回 `['']`，导致后续 `WHERE IN ('')` 语法错误或全表扫描。 | 增加空值过滤与类型转换。 | `$shop_id = array_filter(array_map('intval', explode(',', $shop_id)));<br>if (empty($shop_id)) return [];` |
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **立即修复 SQL 注入**：`get_shop_list_order_by_distance` 中的原始 SQL 拼接必须替换为 CI Query Builder 或严格转义。这是最高优先级的安全红线。
2. **修正致命拼写错误**：`get_community_shop_list` 中的 `$param` 必须改为 `$params`，否则业务逻辑将静默失效。
3. **清理全局实例化代码**：删除文件顶部的 `$CI = &get_instance();`，将其移至 `__construct()` 或依赖 CI 的 `autoload.php` 配置。
### 🛠 后续重构与优化方向
1. **性能架构升级**：
- **批量查询替代循环查询**：针对 `get_community_shop_list` 等列表接口，将配置、评论、距离计算等依赖改为 `IN` 批量查询或 Redis Pipeline 获取。
- **距离计算下沉**：PHP 循环计算 `get_distance()` 在数据量大时极慢。建议改用 MySQL 空间函数（如 `ST_Distance_Sphere`）或 Redis `GEO` 模块在数据库/缓存层完成排序。
2. **代码规范与可维护性**：
- **统一命名与类型声明**：全面采用 PSR-12 规范，为所有方法添加 PHP 7.4+ 类型提示（如 `public function get_info(array $param): array`），提升 IDE 提示与静态分析能力。
- **消除魔法数字**：将 `86400`、`1`、`-1`、`5` 等硬编码提取为类常量（如 `const CACHE_TTL = 86400; const STATUS_ACTIVE = 1;`）。
- **异常处理标准化**：当前混用 `throwError()` 和 `showErrorView()`。建议统一使用 PHP 原生 `throw new \RuntimeException()` 或框架标准异常，便于全局异常拦截与日志记录。
3. **框架适配建议**：
- 基于代码结构，该项目高度类似 **CodeIgniter 3**。若确为 `phpci` 定制框架，请确认其是否支持 CI4 的依赖注入容器。若支持，建议逐步将 `$this->load->model()` 替换为构造函数注入，以提升单元测试覆盖率。
- `Simple_model` 作为基类，建议封装统一的 `batchSelect()`、`cache()` 方法，避免各子类重复实现缓存与批量逻辑。
> 💡 **注**：由于未提供 `Simple_model` 基类及全局辅助函数（如 `locationTurnTxMap`, `get_distance`）的实现，部分性能与逻辑评估基于常规实践推断。建议在修复上述高危问题后，结合 Xdebug 或 Blackfire 进行实际压测，验证 N+1 与距离计算优化效果。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779168174
|
1779168174
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
180
|
21
|
12
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `6a5abf32f ## 自动代码审查报告
**分支**: pay-260519
**提交**: `6a5abf32f15e89bfd3709efd2e39ebefdfb97ebf`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 13:33:35
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了支付流水记录的核心业务逻辑，功能结构完整。但存在**高危 SQL 注入漏洞**、**N+1 查询性能瓶颈**、**严重违反 DRY 原则**以及**框架生命周期误用**等问题。代码中大量使用魔法数字、松散比较和冗余的模型加载，可维护性与安全性亟待提升。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_vip_pay_log` (~380行)<br>`get_vip_pay_log_min` (~490行) | **SQL 注入漏洞**：直接使用字符串拼接构造 `WHERE` 条件（如 `'_merchant_id=' . $merchant_id`），未进行任何转义或参数绑定，恶意输入可导致数据泄露或篡改。 | 废弃字符串拼接，全面改用框架查询构造器（Query Builder）或参数化查询。 | `$this->db->where('_merchant_id', $merchant_id)->where('_vip_card', $vip_card)->get(...)` |
| 🔴 严重 | 文件顶部 (1-4行) | **框架生命周期误用**：在类外部执行 `$CI = &get_instance();` 并加载模型。该代码会在文件被 `include/require` 时立即执行，此时框架可能尚未完成初始化，易引发致命错误或内存泄漏。 | 移除顶部全局代码，直接继承父类。模型加载应移至构造函数或按需调用。 | `class Ahead_pay_log_model extends Simple_model { public function __construct() { parent::__construct(); } }` |
| 🔴 严重 | `add_by_footbath_order` (~345行) | **逻辑错误/数据不一致**：`ManageMap` 数据准备中误将 `$order['_registration_fee']` 赋值给 `actual_pay`，应为 `$order['_actual_pay']`。且核心调用已被注释，保留冗余代码易引发后续维护混淆。 | 修正字段名；若业务明确暂不启用，请直接删除整段数据准备代码。 | `'actual_pay' => $order['_actual_pay'],` |
| 🟠 警告 | `get_bill_pay_log`<br>`get_order_pay_log`<br>`get_vip_pay_log_min` | **N+1 查询性能瓶颈**：在 `foreach` 循环中频繁调用 `get_one()` 或 `get_custom_pay_platform()`。当返回 100 条记录时，将触发 100+ 次独立数据库查询，严重拖慢响应速度。 | 收集所有关联 ID，使用 `WHERE IN` 批量查询，或在内存中构建映射数组（Map）进行关联。 | `$ids = array_column($log_data, 'admin_id'); $users = $this->model->get_by_ids($ids); $map = array_column($users, '_name', '_id');` |
| 🟠 警告 | 多个 `add_by_*` 方法 | **违反 DRY 原则**：`ManageMap->add_income` 与 `ahead_songs_sales_pay_log_model->add_data` 的调用逻辑在 6 个方法中高度重复，且参数组装方式不一致。 | 抽取为私有统一处理方法 `_sync_related_logs($data, $map_type, $sales_type)`，集中管理第三方/关联表同步逻辑。 | `private function _sync_related_logs($data, $map_type, $sales_type) { if($data['_actual_pay']>0) { ... } $this->load->model('...'); ... }` |
| 🟡 建议 | 全文多处 | **魔法数字泛滥**：支付平台 ID (`1,2,3,11,14,16...`)、状态值硬编码散落各处，与 `PAY_LOG_TYPE_MAP` 未形成联动，业务变更时代价极高。 | 定义支付平台常量类（如 `PayPlatform`），或在配置文件中集中管理，代码中统一引用常量。 | `if ($platform === PayPlatform::WECHAT) { ... }` |
| 🟡 建议 | `get_bill_pay_log` (~108行) | **三元运算符滥用**：`$pay_platform == 11 ? ($v['actual_pay'] = $v['present_amount']) : '';` 利用三元运算符执行赋值操作，违反 PSR-12 规范且降低可读性。 | 改用标准 `if` 条件语句。 | `if ($pay_platform == 11) { $v['actual_pay'] = $v['present_amount']; }` |
| 🟡 建议 | 全文多处 | **松散比较 (`==`) 与类型不一致**：如 `$order['_pay_platform'] == 14` 与 `== '14'` 混用，PHP 隐式类型转换可能在边界条件下引发逻辑误判。 | 统一使用严格比较 `===`，并在方法入口对关键参数进行类型校验或强制转换。 | `if ((int)$order['_pay_platform'] === 14) { ... }` |
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **立即修复 SQL 注入**：`get_vip_pay_log` 与 `get_vip_pay_log_min` 中的字符串拼接 `WHERE` 条件必须替换为查询构造器或参数绑定。这是当前最高危的安全漏洞。
2. **清理顶部全局代码**：删除文件开头的 `$CI = &get_instance();` 及模型加载逻辑，确保模型生命周期符合 MVC 框架规范。
3. **修正 `add_by_footbath_order` 数据错误**：核对 `actual_pay` 字段赋值来源，并清理已注释的无效代码块。
### 🛠 后续重构与优化方向
1. **消除 N+1 查询**：对涉及循环内查库的方法进行批量查询重构。可引入 `array_column` + `WHERE IN` 模式，将数据库交互次数从 `O(N)` 降至 `O(1)`。
2. **抽象重复同步逻辑**：将 `ManageMap` 营收同步与 `ahead_songs_sales_pay_log_model` 销售日志同步封装为私有方法。建议采用**策略模式**或**观察者模式**解耦支付流水与下游业务系统的依赖。
3. **建立常量/枚举体系**：将散落的支付平台 ID、订单类型、状态码提取为独立的常量类或配置文件。结合 `PAY_LOG_TYPE_MAP` 实现前后端/数据库的统一映射。
4. **框架适配说明**：当前代码结构高度契合 **CodeIgniter 3** 规范。若 `phpci` 为内部定制框架，请重点确认：
- `Simple_model::select()` 是否自动处理 SQL 转义？
- `$this->load->model()` 是否支持自动缓存？（CI3 默认支持，但显式重复加载仍影响可读性）
- 建议查阅 `phpci` 官方文档中关于 `Query Builder` 与 `Model 基类` 的最佳实践，确保底层驱动与当前写法兼容。
> 💡 **提示**：若需对 `Simple_model` 的底层实现或 `ManageMap` 同步逻辑进行更精准的架构级审查，请提供相关基类代码。当前审查基于标准 MVC/CI 范式给出。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779168815
|
1779168815
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
197
|
21
|
18
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `54d804a6e ## 自动代码审查报告
**分支**: pay-260519
**提交**: `54d804a6e3d4c35b65e0b7c085adce8143732218`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 14:28:19
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：业务逻辑覆盖较全面，实现了多平台团购券验券、兑换、核销及复杂的时间/包厢匹配逻辑。但存在**严重的代码重复**、**模型未加载即调用**、**事务回滚机制混用**等隐患。部分时间计算与数组生成逻辑存在性能瓶颈，且错误处理依赖全局函数，不符合现代 PHP 规范。
- **风险等级**：🔴 高（存在运行时 Fatal Error 风险、事务状态不一致风险及高维护成本）
> 📌 **框架说明**：代码中大量使用 `&get_instance()`、`$CI->load->model()`、`$this->db->trans_start()` 等语法，架构特征高度契合 **CodeIgniter 3** 或其衍生框架（如 `phpci`）。以下审查建议基于 CI/phpci 通用最佳实践，若框架有特定封装差异，请以官方文档为准。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Juhai.php` ~158 | 在 `prepare_by_voucher_data` 中，未加载 `ahead_shop_book_time_info_model` 模型就直接调用 `$CI->ahead_shop_book_time_info_model->min_minute_unit_time`，将触发 `Undefined property` 或 `Fatal Error`。 | 将模型加载移至方法顶部或属性首次使用前，确保依赖已注入。 | `$CI->load->model('ahead_shop_book_time_info_model');`<br>`$unit = $CI->ahead_shop_book_time_info_model->min_minute_unit_time;` |
| 🔴 严重 | `Juhai.php` 全文 | `prepare_by_voucher_data` 与 `room_package_prepare` 方法逻辑重合度超 80%，违反 DRY 原则。后续维护极易出现逻辑分歧或漏改。 | 提取公共校验与数据加载方法 `validate_and_load_package_info()`，通过参数区分入口（券码/套餐ID）。 | 见下方重构示例 |
| 🟠 警告 | `Juhai.php` ~130, ~138 | `explode(',', $reward_data['disabled_day'])` 未判空。若字段为空字符串，`explode` 返回 `['']`，`strtotime('')` 返回 `false`，导致日期计算异常。 | 增加 `!empty()` 前置校验，或使用 `array_filter` 过滤空值。 | `if (!empty($reward_data['disabled_day'])) { $days = array_filter(explode(',', $reward_data['disabled_day'])); ... }` |
| 🟠 警告 | `Juhai.php` ~188 | `for` 循环按分钟步长生成 `$this->use_time_info`。若步长为 1 分钟，将生成 1440 个元素的数组，内存占用高且前端通常只需时间段范围。 | 改为存储起止时间戳/范围，由前端或独立工具函数按需展开；或限制最大生成数量。 | `$this->use_time_info['now_date'][] = ['start' => $start_hour_time, 'end' => $end_hour_time];` |
| 🟠 警告 | `Ahead_tuangou_exchange_log_model.php` ~240 | 手动调用 `$this->db->trans_rollback()` 与 CI 自动事务机制混用。若 `trans_complete()` 被后续代码隐式调用，可能导致事务状态混乱。 | 移除手动 `trans_rollback()`，统一依赖 `$this->db->trans_complete()` 配合 `$this->db->trans_status()` 判断。 | `if (!$this->db->trans_status()) { return ['status'=>false, 'msg'=>'事务失败']; }` |
| 🟠 警告 | `Ahead_tuangou_exchange_log_model.php` ~310 | 通过 `$this->ahead_user_reward_model->insert_flag = false;` 绕过数据库插入生成模拟数据。在并发请求下极易引发状态污染或竞态条件。 | 在 Model 中提供独立的 `build_mock_reward_data()` 方法，避免修改全局/实例状态标志位。 | `public function build_mock_data($params) { return $this->format_reward($params); }` |
| 🟡 建议 | 全局 | 大量使用魔法数字/字符串（如 `24`, `23`, `17`, `86400`, `256`），可读性差且易出错。 | 提取为类常量或配置文件常量，如 `const PLATFORM_DOUYIN = 24; const SECONDS_PER_DAY = 86400;` | `const PLATFORM_DOUYIN = 24;`<br>`if ($from_palce == self::PLATFORM_DOUYIN) { ... }` |
| 🟡 建议 | 全局 | 依赖全局函数 `throwError()` 中断流程，不符合 PSR 异常处理规范，且不利于上层统一捕获与日志记录。 | 替换为抛出标准异常类（如 `throw new \InvalidArgumentException()` 或框架自定义 `BusinessException`）。 | `throw new BusinessException('开房套餐券码错误', 400);` |
| 🟡 建议 | 全局 | PHPDoc 注释中 `@return true` 语法错误，应为 `@return bool`。类名/方法名未遵循 PSR-12 驼峰规范。 | 修正注释类型声明，方法名改为 `camelCase`，类名保持 `PascalCase`。 | `@return bool`<br>`public function tuangouExchangeCheck(...)` |
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **修复未加载模型即调用的致命错误**：立即在 `Juhai.php` 顶部补充 `$CI->load->model('ahead_shop_book_time_info_model');`，否则线上验券流程将直接崩溃。
2. **消除核心逻辑重复**：`prepare_by_voucher_data` 与 `room_package_prepare` 必须合并重构。建议将“套餐校验、时间交集计算、不可用日期/星期处理、Redis 缓存”抽离为独立私有方法，通过策略模式或参数路由复用。
3. **规范事务处理**：统一使用 `$this->db->trans_start(); ... $this->db->trans_complete(); if (!$this->db->trans_status()) { ... }` 模式，移除所有手动 `trans_rollback()`，避免事务嵌套或状态残留。
### 🛠 后续重构与优化方向
1. **架构与规范升级**：
- 逐步废弃全局 `throwError()`，引入 `try-catch` 与全局异常处理器（Exception Handler），实现错误码统一、日志自动记录与安全脱敏。
- 严格遵循 PSR-12 命名规范，将 `tuangou_exchange_check` 等改为 `tuangouExchangeCheck`，提升 IDE 提示与静态分析兼容性。
2. **性能与内存优化**：
- **时间段计算**：将分钟级循环展开改为区间存储（如 `[['start'=>'09:00', 'end'=>'18:00']]`），大幅降低内存峰值。
- **Redis 连接管理**：频繁调用 `get_aliyun_redis_conn()` 并手动 `close()` 会增加 TCP 握手开销。建议改用连接池或单例模式复用连接，或使用框架内置的 Redis 驱动。
- **数据库查询**：`prepare_by_voucher_data` 中连续 4 次 `get_one` 查询可考虑使用 `JOIN` 或批量 `WHERE IN` 优化，减少网络往返延迟。
3. **安全加固**：
- Redis 中存储的 `$redis_data` 包含用户 ID、支付金额、平台信息等敏感数据。建议对序列化后的字符串进行加密（如 `openssl_encrypt`）或启用 Redis ACL 权限隔离，防止缓存穿透/泄露。
- `set_table_name($table . ' info')` 会修改 Model 实例的全局表名状态，若后续有其他查询复用该 Model 实例可能导致 SQL 错乱。建议改用 `$this->db->from($table . ' info')` 或克隆 Model 实例。
> 💡 **重构代码示例（逻辑抽离参考）**：
> ```php
> // Juhai.php 重构示意
> private function validate_and_load_package($merchant_id, $shop_id, $check_package_infos, $check_package) {
> // 提取原 prepare_by_voucher_data 中 ~60% 的公共校验与计算逻辑
> // 返回标准化后的 $package_data 数组
> // ...
> return $package_data;
> }
>
> public function prepare_by_voucher_data($merchant_id, $shop_id, $reward_data) {
> // 前置券校验...
> $package_data = $this->validate_and_load_package($merchant_id, $shop_id, $check_package_infos, $check_package);
> $this->assign_voucher_properties($reward_data, $package_data);
> return true;
> }
> ```
请优先处理 🔴 严重项，并在下一迭代中推进 🟠 警告项的规范化改造。如需针对特定模块（如时间交集算法或事务封装）提供完整重构代码，可随时提供详细上下文。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779172099
|
1779172099
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
208
|
21
|
21
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `3ac445346 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `3ac445346e2558d854d462bc96b5d97b9d9ad574`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 16:25:42
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：代码实现了复杂的团购券验券、核销、时间窗计算及跨平台路由逻辑，业务覆盖较全。但存在**核心逻辑严重重复、潜在SQL注入、循环边界未校验、异常静默吞没**等问题。整体架构偏向过程式，未充分利用面向对象设计原则，可维护性与安全性有待提升。
- **风险等级**：🟠 中（存在安全漏洞隐患与性能/稳定性风险，需优先修复）
> 📌 **框架说明**：代码中大量使用 `&get_instance()`、`$CI->load->model()`、`$this->db->trans_start()` 等语法，属于典型的 **CodeIgniter 3** 架构。`phpci` 实为 PHP 持续集成服务器（CI/CD工具），并非 PHP 框架。本次审查将基于 CI3 规范与 PHP 现代最佳实践进行。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_room_package_infos_model.php`<br>~L380, L430 | **SQL 注入风险**：`$shop_name` 直接拼接至原生 SQL 语句中，未做转义或参数化绑定。攻击者可构造恶意输入破坏查询或拖库。 | 使用 CI3 查询构造器替代原生 SQL，或至少使用 `$this->db->escape()` 进行转义。 | `$this->db->like('shop._name', $shop_name, 'both');`<br>`$query = $this->db->get();` |
| 🔴 严重 | `Juhai.php`<br>`prepare_by_voucher_data()` vs `room_package_prepare()` | **核心逻辑严重重复**：两个方法中关于套餐校验、时间交集计算、跨天处理、Redis 缓存的代码重复率超 80%。后续维护极易出现逻辑不同步。 | 提取公共方法 `calculate_package_availability($package_info, $room_package, $shop_data)`，子类仅处理差异参数。遵循 DRY 原则。 | `protected function process_package_time_logic($info, $pkg, $shop) { /* 提取公共逻辑 */ }`<br>`public function prepare_by_voucher_data(...) { $this->process_package_time_logic(...); }` |
| 🟠 警告 | `Tuangou.php`<br>`build_use_time_info()` | **潜在死循环/性能瓶颈**：`for ($i = $start; $i <= $end; $i += $min_minute_unit_time)` 未校验步长。若 `min_minute_unit_time <= 0` 将导致死循环或内存溢出。 | 增加步长合法性校验，并限制最大循环次数。建议将时间片生成逻辑移至缓存或惰性计算。 | `if ($step <= 0) throw new \InvalidArgumentException('步长必须大于0');`<br>`$max_iter = 300; while($i <= $end && $max_iter-- > 0) { ... }` |
| 🟠 警告 | `Tuangou.php`<br>`get_duration_in_hours()` | **正则与转换逻辑矛盾**：`preg_match('/(\d+)(?=小时)/u')` 仅匹配阿拉伯数字，后续判断汉字数字的代码永远无法执行。无法正确解析“两小时”等中文表述。 | 统一正则表达式，或改用更健壮的解析逻辑。 | `preg_match('/(\d+|[一二两三四五六七八九十]+)(?=小时)/u', $goods_title, $matches);`<br>`$duration_str = $matches[1] ?? '';` |
| 🟠 警告 | `Tuangou.php`<br>`save_voucher_info_to_redis()` 等 | **异常静默吞没**：`catch (RedisException $e) {}` 空捕获导致 Redis 写入失败时业务无感知，可能引发验券状态不一致。 | 记录错误日志，或根据业务需求抛出异常/返回明确状态码。 | `catch (RedisException $e) { log_message('error', 'Redis写入失败: '.$e->getMessage()); return false; }` |
| 🟡 建议 | `Juhai.php` L28 | **拼写错误**：`$CI->ahead_user_reward_model->fileds` 应为 `fields`。可能导致模型属性访问失败或返回空数组。 | 修正拼写，并建议开启 IDE 静态检查或 PHPStan。 | `$CI->ahead_user_reward_model->fields` |
| 🟡 建议 | 全局多处 | **魔法数字硬编码**：如 `4`, `24`, `23`, `17`, `86400`, `7200` 散落在代码中，缺乏语义且难以维护。 | 在类顶部定义常量或提取至配置文件。 | `const PLATFORM_JUHAI = '-1';`<br>`const SECONDS_PER_DAY = 86400;`<br>`const REDIS_TTL = 7200;` |
| 🟡 建议 | `Tuangou.php`<br>`_common_processing()` | **违反单一职责原则 (SRP)**：该方法超 300 行，混合了平台路由、模型加载、参数组装与业务分发，可读性差且难以单元测试。 | 采用**策略模式**或**工厂模式**，将各平台逻辑拆分为独立类（如 `DouyinStrategy`, `MeituanStrategy`）。 | `interface PlatformStrategy { public function prepare(...); }`<br>`$strategy = PlatformFactory::create($platform);` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复 SQL 注入漏洞**：立即替换 `Ahead_room_package_infos_model.php` 中的原生 SQL 拼接，改用 CI3 Query Builder 或预处理语句。
2. **消除重复代码**：将 `Juhai.php` 中 `prepare_by_voucher_data` 与 `room_package_prepare` 的公共逻辑抽离为受保护方法，降低维护成本与逻辑分歧风险。
3. **加固循环与异常处理**：为所有基于 `min_minute_unit_time` 的循环添加步长校验；移除空的 `catch` 块，确保 Redis 或 DB 异常可被监控与追踪。
### 🛠 后续重构与优化方向
1. **架构升级（策略模式）**：当前 `_common_processing` 充当了“上帝类”角色。建议引入策略模式，将抖音、美团、巨嗨等平台逻辑解耦。这不仅符合开闭原则（OCP），也能大幅提升单元测试覆盖率。
2. **时间计算逻辑优化**：跨天、交集、时间片生成的算法较为脆弱。建议封装独立的 `TimeRangeCalculator` 工具类，使用 `DateTime` / `DateInterval` 替代原始秒数运算，避免时区与跨日边界错误。
3. **模型加载优化**：CI3 中频繁在方法内调用 `$CI->load->model()` 虽不会报错，但会增加 I/O 开销。建议在类的 `__construct()` 中统一加载，或使用 CI3 的自动加载配置。
4. **类型声明与规范**：逐步引入 PHP 7.4+ 类型声明（如 `public function prepare(int $merchant_id, int $shop_id, string $voucher_code): bool`），配合 PSR-12 规范，可大幅减少运行时类型错误。
> 💡 **局限性说明**：本次审查基于提供的代码片段。部分依赖（如 `Simple_model`、`throwError`、`timeToHour`、`intersectTimeRanges` 等全局函数/基类）未提供完整实现，部分逻辑假设基于 CI3 标准行为。建议在完整上下文中进行集成测试验证。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779179142
|
1779179142
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
210
|
21
|
22
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `368ebd744 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `368ebd744ea5c1997898e97957ec175a8c32f852`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 16:27:38
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：业务逻辑链路完整，能实现团购券与门店卡券的绑定校验及列表获取。但存在明显的 **SQL 注入风险**、**循环内重复加载模型与查询（N+1问题）**，且类命名、实例调用方式不符合现代 PHP 与主流框架规范。需优先修复安全与性能瓶颈，再进行代码规范化重构。
- **风险等级**：🔴 高（存在未转义的 SQL 拼接与循环查询性能隐患）
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_gift_data` ~L38 | **SQL 注入风险**：直接使用字符串拼接构造 `WHERE` 条件，`$shop_id` 未经过任何转义或参数化处理。若传入恶意字符可破坏 SQL 结构。 | 使用框架查询构造器或手动转义。若 `Simple_model` 不支持参数绑定，必须使用 `$this->db->escape()`。 | `$shop_id_esc = $this->db->escape($shop_id);`<br>`$where_str[] = "(_shop_id={$shop_id_esc} OR FIND_IN_SET({$shop_id_esc}, _satisfy_shop_ids))";` |
| 🔴 严重 | `get_user_tuangou_coupon_info` ~L108 | **循环内加载模型与查询**：在 `foreach` 内部调用 `$this->load->model()` 和 `get_gift_info()`，导致严重的重复加载开销与 N+1 查询问题，数据量大时极易拖垮数据库。 | 将模型加载移至循环外；收集所有 `$gift_id` 后使用 `where_in` 批量查询，再在内存中通过数组映射匹配。 | 见下方 `3. 总结与行动建议` 中的重构示例 |
| 🟠 警告 | 文件顶部 L1-L2 | **不当的全局实例调用**：在类定义外部使用 `$CI = &get_instance();` 加载模型。模型本身已继承 CI 核心类，顶层代码会在 `include` 时立即执行，破坏 OOP 封装且可能引发重复加载。 | 删除顶部两行代码。在类内部直接使用 `$this->load->model()` 或依赖框架自动加载机制。 | `// 删除以下两行`<br>`$CI = &get_instance();`<br>`$CI->load->model('Simple_model');` |
| 🟠 警告 | 全局多处 | **硬编码魔法值**：大量使用 `'4'`, `'1'`, `'2'`, `'3'` 等字面量表示业务状态，降低可读性且后续维护易出错。 | 在类顶部定义语义化常量，统一替换硬编码。 | `const GIFT_TYPE_ROOM_PACKAGE = '4';`<br>`const STATUS_ENABLED = 1;`<br>`const PLATFORM_MEITUAN = '2';` |
| 🟠 警告 | `get_gift_data` ~L68 | **变量作用域隐患**：`$coupon_room_type_package` 仅在 `if` 分支中赋值，虽使用 `?? []` 兜底，但不符合显式初始化规范，静态分析工具会报错。 | 在方法开头显式初始化 `$coupon_room_type_package = [];`。 | `$coupon_room_type_package = [];`<br>`// ... 后续逻辑` |
| 🟡 建议 | 类定义 L7 | **类名不符合 PSR-12**：使用蛇形命名 `Ahead_shop_group_buying_coupon_model`。 | 改为大驼峰命名 `AheadShopGroupBuyingCouponModel`，并同步修改文件名。 | `class AheadShopGroupBuyingCouponModel extends Simple_model` |
| 🟡 建议 | 多处方法内 | **频繁调用 `load->model()`**：每个方法内重复加载相同模型，增加 I/O 开销。 | 建议在 `__construct()` 中统一加载，或配置框架自动加载。 | `public function __construct() {`<br>` parent::__construct();`<br>` $this->load->model(['ahead_merchant_gift_model', 'ahead_room_package_infos_model', 'ahead_room_package_model', 'ahead_shop_config_second_model']);`<br>`}` |
| 🟡 建议 | `get_gift_data` ~L38 | **`FIND_IN_SET` 性能隐患**：该函数无法利用 B-Tree 索引，数据量增长后将导致全表扫描。 | 建议将 `_satisfy_shop_ids` 拆分为独立关联表（如 `gift_shop_relation`），使用 `JOIN` 查询。 | 架构优化建议，非紧急代码修改 |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复 SQL 注入**：立即对 `get_gift_data` 中的 `$shop_id` 进行转义处理。若 `phpci` 框架支持参数化查询（如 `?` 占位符或命名参数），请优先替换字符串拼接。
2. **消除循环内查询**：`get_user_tuangou_coupon_info` 中的 N+1 查询是性能瓶颈核心。需改为批量查询。
3. **清理顶层冗余代码**：删除文件头部的 `$CI = &get_instance();`，避免框架生命周期异常。
### 🛠 后续重构与优化方向
#### 1. 循环查询优化示例（`get_user_tuangou_coupon_info`）
```php
// 1. 收集所有需要查询的 gift_id
$gift_ids = array_unique(array_column($coupon_data, '_gift_id'));
if (empty($gift_ids)) return [];
// 2. 批量查询（假设 Simple_model 支持 where_in）
$this->load->model('ahead_merchant_gift_model');
$all_gifts = $this->ahead_merchant_gift_model->get_list(['where_in' => ['_id', $gift_ids]]);
$gift_map = array_column($all_gifts, null, '_id'); // 以 _id 为键建立映射
// 3. 内存中匹配，避免循环查库
foreach ($deal_group_info as $deal_group_id => $code_arr) {
$gift_id = $coupon_data[$deal_group_id]['_gift_id'] ?? null;
if (!$gift_id || !isset($gift_map[$gift_id])) continue;
$gift_info = $gift_map[$gift_id];
// ... 后续业务逻辑
}
```
#### 2. 框架适配与规范说明
- **框架假设**：当前代码结构高度契合 **CodeIgniter 3** 规范。若 `phpci` 为内部定制框架，请确认 `Simple_model` 的 `where` 数组解析规则是否原生支持参数绑定。若不支持，建议封装统一的 `safe_where()` 方法。
- **常量管理**：建议将 `'4'`, `'1'`, `'2'` 等状态值抽离至独立的 `config/constants.php` 或类常量中，便于全局维护。
- **异常处理**：`throwError()` 若为全局函数，建议统一替换为 `throw new \Exception()` 或框架内置的异常类，以便上层控制器统一捕获并返回标准 JSON 格式。
> 💡 **提示**：本次审查基于提供的代码片段。若 `Simple_model` 或 `phpci` 框架有特殊的查询构造器语法或自动加载机制，请以官方文档为准。建议在修复上述高危问题后，补充单元测试覆盖边界条件（如空数组、非法类型、数据库断连等）。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779179258
|
1779179258
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
211
|
21
|
23
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `49416cb8b ## 自动代码审查报告
**分支**: pay-260519
**提交**: `49416cb8b6925c63be7877293b14e6790a9c8bd4`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 16:36:45
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：代码完整实现了团购券的验券、兑换、核销及 Redis 缓存流转逻辑，业务流程闭环清晰。但存在事务控制不严谨、并发场景下的状态污染风险、大量魔法数字硬编码、模型职责过重等问题。整体可维护性与健壮性有待提升。
- **风险等级**：🟠 中（主要风险集中在事务回滚逻辑、并发竞态条件及外部 API 串行调用导致的性能瓶颈）
> 💡 **框架说明**：代码特征（`$CI = &get_instance()`、`$this->load->model()`、`$this->db->trans_start()`）高度符合 **CodeIgniter 3** 规范。若 `phpci` 为基于 CI 的定制框架，以下建议完全适用；若为独立框架，请根据实际生命周期调整组件加载方式。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 文件顶部 / 多处方法 | `$CI = &get_instance();` 在类外部声明，且在方法内多次重复获取。在 CI 架构中，模型内部应直接使用 `$this` 访问已加载组件。全局获取易导致上下文污染、内存泄漏及测试困难。 | 移除文件顶部的 `$CI` 赋值。模型内直接使用 `$this->load`、`$this->db`。若需访问控制器属性，应通过方法参数传递或依赖注入。 | `// 删除顶部 $CI = &get_instance();`<br>`// 方法内直接使用 $this->load->model(...)` |
| 🔴 严重 | `_tuangou_exchange` | 事务回滚逻辑不严谨。手动调用 `$this->db->trans_rollback()` 后直接 `return`，但未统一处理 `$this->db->trans_complete()` 的调用时机，在 CI 严格模式下可能引发事务状态异常或隐式二次回滚。 | 使用 `try...catch` 包裹核心逻辑，或依赖 CI 的 `trans_strict` 自动回滚机制。确保 `trans_complete()` 仅在未手动回滚时执行。 | ```php<br>$this->db->trans_start();<br>try {<br> // 业务逻辑<br> if (!$success) {<br> $this->db->trans_rollback();<br> return ['status'=>false, 'msg'=>'...'];<br> }<br> $this->db->trans_complete();<br>} catch (\Exception $e) {<br> $this->db->trans_rollback();<br> throw $e;<br>}<br>``` |
| 🟠 警告 | `get_reward_info_from_redis` | 直接修改共享模型属性 `$this->ahead_user_reward_model->insert_flag = false;`。在高并发请求下会引发**竞态条件**，导致其他请求的插入行为被意外跳过。 | 避免修改全局/共享模型状态。应将标志位作为参数传入，或重构 `register_present_gift` 方法支持局部控制。 | `// 修改方法签名支持参数控制`<br>`$reward_id = $this->ahead_user_reward_model->register_present_gift(..., $skip_db_insert = false);` |
| 🟠 警告 | `tuangou_exchange_check` | `in_array($platform, $platform_arr)` 使用松散比较。若 `$platform` 为字符串而 `$platform_arr` 为整型，PHP 类型转换可能导致误判。 | 启用严格比较，并确保数据类型一致。 | `if (!in_array((int)$platform, $platform_arr, true)) { ... }` |
| 🟠 警告 | 多处方法 | 魔法数字/字符串硬编码（如 `'1'`, `'2'`, `11`, `256`, `3600`）。降低可读性，且业务规则变更时需全局搜索替换。 | 提取为类常量或配置文件。例如核销模式、平台标识、Redis 过期时间等。 | `const VERIFY_MODE_INSTANT = '1';`<br>`const REDIS_EXPIRE_SEC = 3600;`<br>`const PLATFORM_DOUYIN = 1;` |
| 🟠 警告 | `tuangou_exchange` | `json_encode($redis_data, 256)` 使用魔法数字。PHP 7.3+ 推荐结合 `JSON_THROW_ON_ERROR` 处理编码异常，避免静默失败。 | 使用语义化常量，并增加异常捕获。 | `json_encode($redis_data, JSON_UNESCAPED_UNICODE \| JSON_THROW_ON_ERROR)` |
| 🟡 建议 | 多处方法 | 错误处理机制不统一。部分使用 `throwError()` 抛出全局异常，部分返回 `['status' => false]`。模型层抛出异常会破坏调用链预期。 | 统一模型层返回结构化数组或抛出自定义业务异常（如 `BusinessException`），由控制器层统一捕获并格式化响应。 | `// 统一返回格式`<br>`return ['status' => false, 'msg' => '券码验证失败'];` |
| 🟡 建议 | 多处方法 | 频繁在方法内部调用 `$this->load->model()`。虽然 CI 会缓存实例，但分散声明影响可读性与单元测试。 | 将高频依赖模型移至构造函数 `__construct()` 中初始化，或配置 `autoload.php`。 | `public function __construct() { parent::__construct(); $this->load->model('ahead_shop_group_buying_coupon_model'); }` |
| 🟡 建议 | `get_reward_info_from_redis` | `$reward_info ?? []` 在 PHP 8+ 中若变量未初始化会触发 `Warning`。 | 提前初始化变量 `$reward_info = [];`。 | `$reward_info = [];`<br>`// ... 业务逻辑 ...`<br>`return $reward_info;` |
| 🟡 建议 | 类定义 | 类名 `Ahead_tuangou_exchange_log_model` 使用下划线命名，不符合 PSR-12 规范。 | 若项目强制遵循 CI3 规范可保留，但建议逐步迁移至 `AheadTuangouExchangeLogModel`。 | `class AheadTuangouExchangeLogModel extends Simple_model` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **事务安全加固**：立即重构 `_tuangou_exchange` 中的事务控制逻辑，采用 `try...catch` + `trans_complete()` 标准模式，防止并发或异常场景下的数据不一致。
2. **消除并发竞态条件**：移除对 `$this->ahead_user_reward_model->insert_flag` 的全局状态修改，改为参数传递或方法级隔离。
3. **清理全局 `$CI` 引用**：删除文件顶部的 `&get_instance()`，严格遵循 CI 模型规范使用 `$this` 上下文。
### 🛠 后续重构与优化方向
1. **架构分层（SRP 原则）**：当前 Model 承担了 `验券校验`、`Redis 缓存管理`、`DB 事务`、`第三方 API 调用`、`卡券发放` 等多重职责。建议抽离为 **Service 层**（如 `TuangouExchangeService`），Model 仅负责数据持久化，提升可测试性与可维护性。
2. **性能优化**：
- `tuangou_exchange_check` 中的 `foreach` 串行请求第三方平台验券接口是主要性能瓶颈。建议评估是否可改用 `curl_multi` 并发请求，或引入本地缓存/异步队列降级处理。
- Redis 操作可封装为独立 Helper，避免重复的 `get/set/expire/close` 样板代码。
3. **安全与规范**：
- 所有外部输入（`$qr_code`, `$voucher_code`, `$params`）在进入业务逻辑前应进行基础过滤与类型强转。
- 统一错误码与消息字典，避免硬编码中文提示，便于后续多语言或前端对接。
- 若 `phpci` 框架支持，建议启用 `CI_ENVIRONMENT` 环境变量区分开发/生产配置，敏感信息（如 Redis 连接参数）走配置中心。
> 📌 **局限性说明**：本次审查仅基于提供的单个 Model 文件。实际风险可能受关联的 `Tuangou` 库、`Simple_model` 基类实现、数据库驱动配置及全局 Helper（如 `throwError`、`get_aliyun_redis_conn`）影响。建议结合完整调用链进行集成测试与压测验证。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779179805
|
1779179805
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
212
|
21
|
24
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `2a980b367 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `2a980b3670633e5727929484e767c544065612c4`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 16:38:25
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该 Model 承载了复杂的套餐查询、多端价格计算、会员折扣与社区模式适配逻辑，业务覆盖较全。但代码存在**高危 SQL 注入隐患**、**经典的 `unset` 引用失效 Bug**、**循环内性能损耗**及**不符合现代 PHP 规范的写法**。整体处于“功能可跑但架构脆弱”状态，需优先处理安全与核心逻辑缺陷，并进行职责拆分。
- **风险等级**：🔴 高
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_package_list` / `get_hot_sale_top5` 等多处 | **SQL 注入漏洞**：`$shop_name` 等参数未经转义直接拼接入 `LIKE` 语句。虽 `$city_id` 做了 `intval()`，但原始 SQL 拼接模式极易被绕过或引发语法错误。 | 全面替换为框架查询构造器（Query Builder）或使用 `$this->db->escape()`。禁止手动拼接 `WHERE` 条件。 | `$this->db->where('shop._city_id', $city_id)->like('shop._name', $shop_name)->get()->result_array();` |
| 🔴 严重 | `get_package_price_list` (~L148)<br>`get_screen_list` (~L288) | **`unset($row)` 逻辑失效**：在 `foreach ($list as &$row)` 中执行 `unset($row)` 仅销毁局部引用，**不会**从原数组中移除元素，导致无效套餐仍被返回。 | 改用键值遍历 `foreach ($list as $key => $row)` 并 `unset($list[$key])`，或使用 `array_filter`。 | `foreach ($list as $key => $row) { if ($book_arrival_time < $order_end_time) { unset($list[$key]); } }` |
| 🟠 警告 | 文件顶部 (~L5) | **全局 `$CI` 实例化时机错误**：`$CI = &get_instance();` 在文件被 `include` 时立即执行，此时框架可能未完全初始化，且破坏面向对象封装原则。 | 删除顶部代码。在方法内部统一使用 `$this->load->model()` / `$this->config->load()`。CI 框架会自动处理依赖注入。 | 移除 `$CI = &get_instance();` 及 `$CI->load->...`，全部替换为 `$this->load->...` |
| 🟠 警告 | `get_package_price_list` / `get_screen_list` | **循环内 `array_unshift` 性能瓶颈**：在 `foreach` 中频繁调用 `array_unshift`，时间复杂度退化为 O(n²)，数据量超 100 时极易导致 CPU 飙升或超时。 | 将推荐项与非推荐项分别收集到临时数组，循环结束后使用 `array_merge` 合并。 | `$rec[] = $row; $norm[] = $row; ... $result['drink'] = array_merge($rec, $norm);` |
| 🟠 警告 | `get_book_package_list` (~L415) | **静态变量伪缓存**：`static $_shop_id_arr` 仅在单次 PHP-FPM 请求生命周期有效，无法跨请求共享，且无 TTL 控制，实际未起到缓存作用。 | 使用框架缓存组件（Redis/Memcached）替代静态变量，设置合理过期时间。 | `$key = "shop_dist_{$city_id}_{$lat}_{$lon}"; $ids = $this->cache->get($key) ?: $this->ahead_shop_model->get_id_by_distance(...); $this->cache->save($key, $ids, 300);` |
| 🟡 建议 | 全局 | **魔法数字泛滥**：大量硬编码 `4`, `2`, `100`, `86400`, `-1` 等，降低可读性与后期维护效率。 | 提取为类常量或配置文件。已定义的 `const SCREEN_RENEW_TYPE = 4;` 需全局替换使用。 | `const PACKAGE_TYPE_GROUP = 4; const SECONDS_PER_DAY = 86400; const DISCOUNT_STATUS_ON = 1;` |
| 🟡 建议 | 全局 | **命名规范不一致**：类名使用下划线 `Ahead_room_package_infos_model`，方法名混用驼峰与下划线，不符合 PSR-12 规范。 | 类名改为 `AheadRoomPackageInfosModel`，方法名统一为 `camelCase`。若受历史包袱限制，至少保持项目内一致。 | `class AheadRoomPackageInfosModel extends Simple_model` |
| 🟡 建议 | `get_package_price_list` 等多处 | **重复加载模型**：同一方法内多次调用 `$this->load->model()`，虽 CI 会做单例拦截，但增加无谓开销且代码冗余。 | 将高频依赖模型移至 `__construct()` 或方法顶部统一加载。 | `public function __construct() { parent::__construct(); $this->load->model(['Ahead_vip_model', 'Ahead_vip_level_model', ...]); }` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即修复 SQL 注入**：将 `get_book_package_list`、`get_hot_sale_top5` 及后续截断方法中的原生 SQL 全部迁移至 CI 查询构造器或预处理语句。
2. **修正 `unset` 逻辑漏洞**：全局搜索 `foreach ($arr as &$v) { unset($v); }` 模式，替换为键值遍历或 `array_filter`，否则将导致脏数据透传至前端。
3. **移除顶部 `$CI` 实例化**：避免框架初始化阶段的竞态条件与内存泄漏风险。
### 🛠 后续重构与优化方向
1. **方法职责拆分**：`get_package_price_list` 单方法超过 150 行，混合了“条件构建、VIP计算、社区模式校验、数据格式化、分类排序”等多个职责。建议拆分为：
- `buildPackageQueryConditions()`
- `calculateVipPrice()`
- `filterCommunityAvailablePackages()`
- `formatPackageList()`
2. **引入 DTO/VO 模式**：当前直接返回裸数组，字段名混杂（如 `_id`、`id`、`package_id`）。建议定义 `PackageDTO` 类统一数据结构，提升类型安全与 IDE 提示体验。
3. **缓存策略升级**：套餐列表查询属于高频读操作。建议对 `get_package_price_list` 结果引入 Redis 缓存，以 `merchant_id_shop_id_room_type` 为 Key，设置 1~5 分钟 TTL，并在后台修改套餐时主动清除缓存。
4. **框架适配说明**：代码结构高度符合 **CodeIgniter 3.x** 规范。若 `phpci` 为内部定制框架，请确认 `$this->db`、`$this->load`、`$this->cache` 的底层实现是否与 CI3 一致。若存在差异，需针对性调整查询构造器与缓存调用方式。
> ⚠️ **局限性说明**：文件末尾 `get_book_package_list_group_by_shop` 方法在 `$special_city_id = [2, 3, 4, 5, 34,` 处被截断，无法审查其完整逻辑与潜在风险。请补充完整代码以便进行二次深度审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779179905
|
1779179905
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
214
|
21
|
25
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `04ced4a89 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `04ced4a89a4379956b4bbf57616c3d36432a852f`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 16:53:26
---
## 1. 审查摘要
- **代码质量评分**：5/10
- **总体评价**：代码承载了复杂的团购核销与时间计算业务，但架构设计偏向过程式，存在大量硬编码、全局状态依赖与超长方法。核心逻辑违反单一职责与开闭原则，缓存与异常处理存在静默失败风险，整体可维护性与扩展性较低。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Tuangou.php` `_common_processing` | 巨型 `switch` 路由违反开闭原则；返回类型不一致（有时返回数组/对象，有时返回 `''`），调用方易发生类型错误。 | 采用**策略模式**拆分各平台逻辑，统一返回结构（如 `['status' => bool, 'data' => mixed, 'msg' => string]`），并严格声明返回类型。 | `public function prepare(...): array { return $this->platformStrategy->prepare(...); }` |
| 🔴 严重 | `Tuangou.php` `save_voucher_info_to_redis` / `del_redis_voucher_info` | 捕获 `RedisException` 后空处理，导致缓存读写失败被静默吞掉，可能引发验券状态不一致或脏数据。 | 记录错误日志并向上抛出或返回明确失败标识，禁止空 `catch`。 | `catch (\RedisException $e) { log_message('error', 'Redis操作失败: ' . $e->getMessage()); throw $e; }` |
| 🔴 严重 | `Ahead_shop_book_time_info_model.php` 构造函数 & `self::$xxx` | 构造函数直接加载库并读取 Redis 产生强副作用；大量 `self::$static` 缓存变量在 PHP-FPM/长连接环境下会跨请求残留，导致脏数据或内存泄漏。 | 移除构造函数副作用，改为按需加载；静态缓存替换为请求级缓存（如框架 Cache 组件）或注入式单例。 | `// 移除构造函数中的 $this->load->library('Tuangou'); 改为在业务方法中显式调用或依赖注入` |
| 🟠 警告 | `Tuangou.php` `get_duration_in_hours` | 正则 `/(\d+)(?=小时)/u` 无法匹配中文数字（如“两小时”）；`$duration` 未初始化直接返回可能触发 Notice；汉字转阿拉伯逻辑无法处理“二十”、“一百”等复合词。 | 使用完整映射表或引入成熟库（如 `symfony/polyfill-intl-icu`），或改用更健壮的正则+替换逻辑。 | `preg_match('/(\d+|[一二三四五六七八九十两]+)小时/u', $title, $m); return $m ? $this->parseChineseNumber($m[1]) : 0;` |
| 🟠 警告 | `Tuangou.php` `get_tuangou_platform_list` | `foreach` 循环内调用 `get_tuangou_platform_shop_id`，每次触发一次 DB 查询，存在严重的 **N+1 查询** 性能瓶颈。 | 改为批量查询（`WHERE platform IN (...)`）或一次性获取所有平台配置后在内存中过滤。 | `$ids = $this->shop_model->get_platform_ids_batch($merchant_id, $shop_id, array_keys($this->platform_arr));` |
| 🟠 警告 | `Tuangou.php` & `Ahead_shop_book_time_info_model.php` | 重度依赖全局变量（`$CI->uid`, `$CI->operational_scene` 等）与全局函数（`throwError`, `timeToHour` 等），破坏封装性，难以进行单元测试。 | 将上下文参数显式传入方法，或使用框架的 Request/Config 对象替代全局 `$CI`；将工具函数封装为独立 Service 类。 | `public function build_use_time_info(string $now_date, int $minUnit): array { ... }` |
| 🟡 建议 | 全局 | 方法命名混用下划线与驼峰（如 `_common_processing`、`get_tuangou_platform_list`），且缺乏 PHP 7+ 类型声明。 | 统一遵循 PSR-12 驼峰命名法；文件顶部添加 `declare(strict_types=1);`，为所有参数与返回值补充类型提示。 | `public function getDurationInHours(string $goodsTitle): int { ... }` |
| 🟡 建议 | `Tuangou.php` 属性定义 | 数十个 `public` 属性直接暴露状态，多次调用易产生状态污染（如 `verify_result` 残留影响下次验券）。 | 改为 `private` 属性，通过 Getter/Setter 或 DTO 对象管理状态；每次验券前强制调用 `init()` 重置。 | `private array $verifyResult = []; public function getVerifyResult(): array { return $this->verifyResult; }` |
| 🟡 建议 | 框架适配 | 代码呈现典型的 CodeIgniter 3 风格（`$CI = &get_instance()`、`$CI->load->library()`）。若项目确为 `phpci`，请确认该框架是否兼容此写法。 | 若 `phpci` 支持依赖注入，建议优先使用 DI 容器替代全局实例获取，提升代码可测试性。 | `// 建议查阅 phpci 官方文档确认是否支持 Service Container 或自动装配` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **消除 Redis 静默失败**：所有 `catch (RedisException $e) {}` 必须补充日志记录或异常抛出，避免缓存层故障导致业务逻辑“假成功”。
2. **解决 N+1 查询**：重构 `get_tuangou_platform_list`，将循环内的单条查询合并为 `IN` 批量查询，降低数据库压力。
3. **修复时长解析缺陷**：重写 `get_duration_in_hours`，确保能正确解析阿拉伯数字与常见中文数字，并处理未匹配时的默认值逻辑。
4. **清理静态缓存污染**：移除 `Ahead_shop_book_time_info_model` 中的 `self::$xxx` 静态缓存，改用框架提供的请求级缓存或实例属性，防止 PHP-FPM Worker 复用导致的数据串扰。
### 🛠 后续重构与优化方向
- **架构解耦（策略模式）**：将 `_common_processing` 中的平台路由逻辑抽离为独立的 `DouyinStrategy`、`MeituanStrategy`、`JuhaiStrategy` 等类，实现 `PlatformStrategyInterface`。主类仅负责上下文传递与策略调度，彻底消除巨型 `switch`。
- **状态封装与 DTO 化**：将 `Tuangou` 类中用于传递验券数据的公开属性收敛为 `VoucherContext` 值对象。每次验券流程开始时实例化新对象，避免多请求/多调用间的状态泄漏。
- **时间计算服务化**：`build_use_time_info` 与 `get_book_day_time_info` 逻辑过于臃肿。建议将时间交集计算、跨天处理、营业时段过滤等逻辑抽取至独立的 `BookingTimeCalculator` 服务类，主模型仅负责数据组装与持久化。
- **全面类型安全**：在文件头部启用 `declare(strict_types=1);`，为所有方法签名补充 `int`, `string`, `array`, `bool` 等类型声明。配合 PHPStan 或 Psalm 进行静态分析，提前拦截隐式类型转换风险。
- **框架规范对齐**：若 `phpci` 为定制框架，请严格对照其官方文档调整 `$CI` 实例获取方式、模型加载机制及生命周期钩子。建议逐步向依赖注入（DI）与面向接口编程迁移，提升代码的可测试性与长期可维护性。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779180806
|
1779180806
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
215
|
21
|
26
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `04479f82b ## 自动代码审查报告
**分支**: pay-260519
**提交**: `04479f82b380ba9e9ac36688cd4ce28e6d05aad0`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 16:57:08
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该类实现了多平台团购券的核销、缓存、时间计算与路由分发等核心业务，功能覆盖面广。但存在典型的“上帝类”问题：方法过长、状态变量滥用、异常静默吞没、时间计算逻辑复杂且易出错。部分基础逻辑（如中文数字解析）存在明显缺陷，且代码末尾未闭合，整体可维护性与健壮性有待大幅提升。
- **风险等级**：🔴 高（异常处理缺失与时间计算边界问题可能导致线上核销失败、状态不一致或资损）
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_redis()` / `save_voucher_info_to_redis()` / `get_voucher_info_from_redis()` | **异常静默吞没**：所有 `catch (RedisException $e) {}` 均为空，Redis 故障时程序静默失败，可能导致券状态丢失、重复核销或缓存不一致。 | 必须记录错误日志并返回明确失败状态，或向上抛出异常交由业务层统一处理。 | `catch (RedisException $e) { log_message('error', 'Redis操作失败: ' . $e->getMessage()); return false; }` |
| 🔴 严重 | `get_duration_in_hours()` | **中文数字解析逻辑错误**：当前实现将汉字逐字映射后拼接（如“十二”→`"102"`），无法处理复合数字（二十三、一百等），且未处理“半小时”、“1.5小时”等常见场景。 | 建议直接要求前端/上游传递阿拉伯数字时长；若必须解析，应使用成熟的中文数字转换库或重写正则匹配逻辑。 | `// 简化方案：仅支持阿拉伯数字<br>preg_match('/(\d+(?:\.\d+)?)\s*小时/u', $goods_title, $m);<br>return isset($m[1]) ? (float)$m[1] : 1;` |
| 🔴 严重 | 类属性声明 vs `init_voucher_info()` | **属性类型不一致**：`public $room_package_type = [];` 声明为数组，但在 `init_voucher_info()` 中被赋值为 `0` (int)，后续若按数组操作将引发 `TypeError`。 | 统一类型声明与初始化值，或明确该字段为 `int` 类型。 | `public $room_package_type = 0;` |
| 🔴 严重 | 文件末尾 | **代码截断未闭合**：文件在 `if (empty($data)) {` 处突然结束，存在致命语法错误风险，且无法评估后续业务逻辑。 | 请补充完整代码。审查基于当前片段，后续逻辑可能存在未暴露的隐患。 | *(需补充完整代码后重新审查)* |
| 🟠 警告 | `_common_processing()` | **Switch 分支未使用常量**：大量使用 `case '-1':`、`case '1':` 等硬编码字符串，未复用顶部定义的 `self::JUHAISHOP` 等常量，易引发拼写错误且不利于维护。 | 全面替换为类常量，提升可读性与重构安全性。 | `case self::JUHAISHOP:`<br>`case self::DOUYINTUANGOU:` |
| 🟠 警告 | `_common_processing()` / 多处 | **频繁重复加载组件**：每次调用都执行 `$CI->load->library()` 和 `$CI->load->model()`。虽 CI 框架有缓存机制，但高频调用仍增加开销，且不符合依赖注入最佳实践。 | 在构造函数中统一加载，或使用懒加载模式。若框架支持，建议通过 DI 容器注入。 | `public function __construct() { $this->CI =& get_instance(); $this->CI->load->model('ahead_shop_model'); }` |
| 🟠 警告 | `build_use_time_info()` / `get_user_time_info()` | **时间计算逻辑复杂且性能差**：方法超 150 行，嵌套深，且在循环中频繁调用 `strtotime()` 和 `date()`，高并发下 CPU 消耗大。直接修改 `$this->use_hour_time_info_check` 状态易引发副作用。 | 抽离为独立的 `TimeCalculator` 服务；预计算时间戳；避免在循环中调用日期函数；使用纯函数替代状态修改。 | `// 循环外预计算基准时间戳<br>$base_ts = strtotime($now_date);<br>for ($i = $start; $i <= $end; $i += $step) { $ts = $base_ts + $i; ... }` |
| 🟠 警告 | `get_voucher_info_from_redis()` | **JSON 解析无容错**：`json_decode($data, true)` 未校验返回值，若缓存数据损坏将返回 `null`，后续数组访问将触发 `Warning` 或逻辑异常。 | 增加 `json_last_error()` 校验或使用 `JSON_THROW_ON_ERROR`。 | `$data = json_decode($data, true, 512, JSON_THROW_ON_ERROR);` |
| 🟡 建议 | 全局方法 | **强依赖全局函数**：大量使用 `throwError()`、`timeToHour()`、`mergeTimeRanges()` 等未声明的全局函数，不利于单元测试、静态分析及框架迁移。 | 封装为类方法或注入 Helper 服务；添加 `function_exists()` 检查；逐步迁移至命名空间。 | `if (!function_exists('throwError')) { throw new \RuntimeException('Global function missing'); }` |
| 🟡 建议 | 类属性与参数 | **缺失现代 PHP 类型声明**：未使用 PHP 7+ 的标量类型声明与返回类型声明，降低代码自文档化能力与静态分析准确性。 | 为所有公开方法添加参数类型与返回类型提示。 | `public function get_tuangou_platform_shop_id(int $merchant_id, int $shop_id, string $platform): string` |
| 🟡 建议 | `@var` 注释 | **类型注释不准确**：如 `@var numeric` 实际存储为 `string`，`@var array` 实际可能为 `int`。误导 IDE 提示与开发者。 | 修正 PHPDoc 类型标注，与实际数据类型保持一致。 | `/** @var string */ public $use_start_time = '';` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **补全代码并修复语法截断**：当前文件末尾未闭合，需立即确认完整逻辑，否则无法部署。
2. **消除空 Catch 块**：所有 Redis 操作必须记录日志并返回明确状态，禁止静默失败。建议统一封装 `RedisHelper` 处理连接与异常。
3. **修复中文数字解析缺陷**：`get_duration_in_hours` 当前逻辑在业务中极易返回错误时长，建议改为强制要求上游传入阿拉伯数字，或引入标准转换库。
4. **统一类型与常量使用**：修正 `room_package_type` 类型不一致问题；将 `_common_processing` 中的硬编码字符串全部替换为顶部定义的类常量。
### 🛠 后续重构与优化方向
1. **拆分“上帝类”，遵循单一职责原则 (SRP)**：
- `TuangouRouter`：负责平台路由与组件分发（替代 `_common_processing`）。
- `VoucherCacheManager`：独立处理 Redis 读写、序列化与异常。
- `TimeRangeCalculator`：抽离 `build_use_time_info` 与 `get_user_time_info` 的复杂时间计算逻辑，改为无状态纯函数。
2. **引入依赖注入与懒加载**：避免在业务方法中频繁调用 `$CI->load->`。可在构造函数中初始化常用 Model/Library，或使用框架的 DI 容器。
3. **性能优化**：
- 避免在循环中调用 `strtotime()`/`date()`，改为基于基准时间戳的数学运算。
- Redis 连接应复用（单例/连接池），而非每次 `get_redis()` 新建。
4. **框架适配说明**：
> 注：当前代码结构高度符合 **CodeIgniter 3** 规范（使用 `&get_instance()` 与 `$CI->load->`）。若 `phpci` 为定制或新版框架，请确认其组件加载机制、生命周期钩子及错误处理策略是否一致。建议查阅 `phpci` 官方文档，确认是否支持 PHP 8+ 特性、PSR-4 自动加载及现代 DI 模式，以便进行平滑升级。
如需对补全后的代码或拆分后的架构进行二次审查，请提供完整片段。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779181029
|
1779181029
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
216
|
21
|
27
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `98ea3d3ec ## 自动代码审查报告
**分支**: pay-260519
**提交**: `98ea3d3ec60057a38e72234acf2db36caceb97db`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 16:59:51
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该类实现了多平台团购券的路由分发、状态缓存与时间规则计算，具备完整的业务骨架。但存在严重的架构设计缺陷：大量使用公共属性暴露状态、巨型 `switch` 分支耦合各平台逻辑、时间计算复杂且缺乏边界保护、异常被静默吞没。代码未遵循现代 PHP 规范，可维护性与可测试性较差。
- **风险等级**：🔴 高（存在静默失败、潜在死循环、状态污染及业务规则硬编码风险）
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_duration_in_hours` 方法 | **正则逻辑矛盾**：`preg_match('/(\d+)(?=小时)/u')` 仅匹配阿拉伯数字，后续判断 `preg_match('/[\x{4e00}-\x{9fff}]+/u', $duration_str)` 永远为 `false`，导致中文数字时长（如“两小时”）解析失败并返回 `0`。 | 修正正则或改用成熟的中文数字转换逻辑。若业务允许，建议前端直接传递标准时长字段，避免后端解析文案。 | `// 方案1：统一使用阿拉伯数字正则<br>preg_match('/(\d+|两|二|三|四|五|六|七|八|九|十)(?=小时)/u', $goods_title, $matches);` |
| 🔴 严重 | `del_redis_voucher_info` / `save_voucher_info_to_redis` / `get_voucher_info_from_redis` | **异常静默吞没**：`catch (RedisException $e) {}` 捕获后未记录日志也未抛出，Redis 宕机或网络抖动时业务继续执行，导致验券状态不一致或资金/券资损。 | 记录错误日志，并向上抛出业务异常或返回明确错误码，禁止空 `catch`。 | `catch (RedisException $e) {<br> log_message('error', 'Redis操作失败: ' . $e->getMessage());<br> throw new RuntimeException('缓存服务异常，请稍后重试');<br>}` |
| 🟠 警告 | `build_use_time_info` 方法 | **潜在死循环风险**：`for` 循环步长依赖 `$CI->ahead_shop_book_time_info_model->min_minute_unit_time`。若该值为 `0` 或负数，将导致无限循环与内存溢出。 | 增加步长合法性校验，确保 `> 0`；同时限制最大循环次数或使用 `while` 配合安全计数器。 | `$step = $CI->ahead_shop_book_time_info_model->min_minute_unit_time;<br>if ($step <= 0) throw new InvalidArgumentException('时间步长必须大于0');` |
| 🟠 警告 | `_common_processing` 方法 | **硬编码与类型不一致**：`switch` 分支使用字符串字面量而非类常量；方法返回类型混杂（数组、字符串、空值），调用方难以安全解构。 | 统一使用 `self::CONSTANT`；明确方法签名与返回类型，使用类型声明约束。 | `case self::DOUYINTUANGOU: // 替代 case '1':<br>...<br>return $result ?? []; // 统一返回数组` |
| 🟠 警告 | 全局多处 | **频繁获取全局实例与动态加载**：几乎每个方法都调用 `$CI = &get_instance();` 并动态 `load->library/model`。虽 CI3 会缓存，但增加耦合度且阻碍单元测试。 | 在 `__construct()` 中初始化 `$CI` 并预加载核心依赖；或采用依赖注入（DI）容器管理。 | `private $CI;<br>public function __construct() {<br> $this->CI =& get_instance();<br> $this->CI->load->model('ahead_shop_model');<br>}` |
| 🟡 建议 | 全局属性定义 | **破坏封装性**：所有业务状态属性均为 `public`，外部可随意篡改，极易引发状态污染与难以追踪的 BUG。 | 改为 `private`/`protected`，提供 `getter/setter` 或使用 DTO 对象集中管理状态。 | `private string $platform = '';<br>public function setPlatform(string $platform): self { $this->platform = $platform; return $this; }` |
| 🟡 建议 | `init_voucher_info` 方法 | **手动重置易遗漏**：硬编码重置数十个属性，新增字段极易遗漏，违反开闭原则。 | 使用数组/对象存储状态，提供统一 `reset()` 方法；或实例化新对象替代状态重置。 | `private array $voucherState = [];<br>public function resetState(): void { $this->voucherState = []; }` |
| 🟡 建议 | `get_user_time_info` 方法 | **业务规则硬编码**：使用大量 `strpos` 硬解析商品名称提取可用星期/时段，运营文案微调（如“周末可用”改为“周末通用”）将直接导致逻辑崩溃。 | 将规则抽离至配置表或 JSON 策略文件，与核心代码解耦。 | `// 建议改为：从数据库读取规则映射表<br>$rules = $this->config->get('tuangou_time_rules');<br>$matchedRule = $this->matchRule($goods_title, $rules);` |
| 🟡 建议 | 全局代码风格 | **未遵循 PSR-12 规范**：方法名使用下划线（如 `_common_processing`）、无类型声明、注释格式不统一。 | 全面升级至 PHP 7.4+/8.x 语法，添加严格类型声明，方法名改为 `camelCase`。 | `public function commonProcessing(int $merchantId, int $shopId, string $platform, string $type, array $params = []): array` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复 Redis 异常静默处理**：券资系统对缓存强依赖，必须确保异常可观测、可降级，避免“假成功”导致资损。
2. **修正 `get_duration_in_hours` 正则逻辑**：当前实现无法正确解析中文数字，需立即调整或改为强类型传参。
3. **防御 `build_use_time_info` 死循环**：增加步长校验与安全退出机制，防止生产环境 OOM。
### 🛠 后续重构与优化方向
1. **引入策略模式（Strategy Pattern）**：当前 `_common_processing` 承载了所有平台的路由逻辑，违反单一职责原则。建议为抖音、美团、巨嗨分别创建 `DouyinStrategy`、`MeituanStrategy` 等类，实现统一接口 `PlatformInterface`。`Tuangou` 类仅负责上下文组装与策略分发。
2. **状态对象化（DTO）**：将 40+ 个公共属性收敛为 `VoucherContext` 或 `VoucherInfo` 数据对象。通过构造函数注入或方法参数传递，彻底消除类级状态污染，提升并发安全性。
3. **规则引擎解耦**：将“商品名解析可用时间/星期”的脆弱逻辑迁移至后台配置中心或数据库规则表，使用正则配置或结构化数据匹配，降低代码变更频率。
4. **全面类型安全升级**：启用 `declare(strict_types=1);`，为所有方法添加参数与返回值类型声明，配合 PHPStan/Psalm 进行静态分析，提前拦截类型错误。
> ⚠️ **局限性说明**：您提供的代码在 `check_goods` 方法末尾（`if (empty($data)) {`）处截断，无法评估该方法的完整逻辑、异常处理及后续业务流程。建议补充完整代码以便进行更精准的边界条件与事务一致性审查。
>
> 📖 **框架适配备注**：代码呈现典型的 CodeIgniter 3 架构特征（`get_instance()`、`$this->load->`）。若 `phpci` 为基于 CI3 的定制框架，上述建议完全适用；若为独立框架，请将 `$CI->load->` 替换为对应框架的依赖注入或服务容器调用方式。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779181191
|
1779181191
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
217
|
21
|
28
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `e8251a226 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `e8251a2266f827bc49723a378a3b4b21e1c8a779`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 17:02:26
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：代码实现了多平台团购券的核心业务逻辑（验券、核销、时间计算、Redis缓存等），整体功能完整。但存在明显的逻辑死代码、N+1 查询性能瓶颈、硬编码与封装性不足等问题。时间计算模块复杂度高且依赖逐分钟循环，可维护性与扩展性有待提升。
- **风险等级**：🟠 中（存在性能隐患与逻辑缺陷，需优先修复）
> 📌 **框架说明**：根据目录结构（`system/`、`get_instance()`、`$CI->load->library()` 等）判断，本项目基于 **CodeIgniter 3.x** 架构。若 `phpci` 为贵司内部定制框架，请结合其特定生命周期与组件规范微调建议。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_duration_in_hours` 方法 | 正则 `/(\d+)(?=小时)/u` 仅匹配阿拉伯数字，导致后续“汉字数字转阿拉伯数字”分支永远无法执行，属于逻辑死代码。若商品名含“两小时”将返回 `0`。 | 修改正则同时兼容阿拉伯数字与中文数字，或拆分匹配逻辑。 | `preg_match('/(\d+|[一二三四五六七八九十两]+)(?=小时)/u', $goods_title, $matches);` |
| 🔴 严重 | `get_tuangou_platform_list` 方法 | 循环内调用 `get_tuangou_platform_shop_id`，每次触发独立 DB 查询。平台越多，N+1 查询越严重，高并发下易拖垮数据库。 | 改为批量查询或一次性读取缓存。利用 CI 的 `where_in` 或 Redis 批量获取。 | 见下方优化建议 |
| 🟠 警告 | 类属性定义区 | 所有业务状态属性均声明为 `public`，破坏面向对象封装原则，外部可随意篡改导致验券状态不一致。 | 改为 `protected` 或 `private`，对外暴露必要的 `get/set` 方法。 | `protected $platform = '';`<br>`public function setPlatform(string $p): void { $this->platform = $p; }` |
| 🟠 警告 | `_common_processing` 方法 | `switch` 分支中大量使用硬编码字符串 `'-1'`, `'1'`, `'2'` 等，未复用顶部定义的类常量，增加维护成本与出错概率。 | 统一替换为 `self::JUHAISHOP`, `self::DOUYINTUANGOU` 等常量。 | `case self::JUHAISHOP:`<br>`case self::DOUYINTUANGOU:` |
| 🟠 警告 | `build_use_time_info` 方法 | 使用 `for` 循环按 `min_minute_unit_time` 粒度逐分钟生成时间区间。当跨度大或跨天时，循环次数呈指数增长，消耗 CPU 与内存。 | 采用区间数学计算或时间戳范围映射替代逐分钟迭代。可考虑将可用时间存为 `[start, end]` 区间数组。 | 建议重构为区间合并算法，避免 `for ($i = $start; $i <= $end; $i += $unit)` |
| 🟡 建议 | 全局 DocBlock | 多处 `@return true` 不符合 PHPDoc 规范；`throwError` 为全局函数，未使用标准异常机制，不利于统一错误处理与测试。 | 修正为 `@return bool`；逐步迁移至 `throw new \RuntimeException()` 或 CI 的 `show_error()`。 | `@return bool`<br>`throw new \InvalidArgumentException('参数错误');` |
| 🟡 建议 | `_common_processing` 方法 | 分支内频繁调用 `$CI->load->library()` 与 `$CI->load->model()`。CI3 虽会检查重复加载，但仍增加框架解析开销。 | 在类构造函数或首次调用时统一加载，或配置 `config/autoload.php`。 | `public function __construct() { $this->CI->load->model('ahead_shop_model'); }` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复正则逻辑死代码**：立即修正 `get_duration_in_hours` 中的正则表达式，确保中文数字时长能被正确解析，避免业务侧核销失败。
2. **消除 N+1 查询**：重构 `get_tuangou_platform_list`，将循环内的单条查询改为批量查询。示例：
```php
// 优化前：循环查库
// 优化后：一次性查询所有平台店铺ID
$platforms = array_keys($this->platform_arr);
$shop_ids = $this->CI->db->select('_id, _douyin_shop_id, _open_shop_uuid')
->where('_merchant_id', $merchant_id)
->where('_id', $shop_id)
->get('your_platform_table')
->row_array();
// 根据返回数组映射各平台ID，避免循环查库
```
3. **统一平台标识常量**：将 `_common_processing` 中的硬编码字符串全部替换为类常量，提升可读性与重构安全性。
### 🛠 后续重构与优化方向
- **引入策略模式 (Strategy Pattern)**：当前 `_common_processing` 承担过多平台路由职责，违反单一职责原则。建议为每个平台（抖音、美团、巨嗨）创建独立的策略类，实现统一的 `VoucherInterface`，通过工厂类动态实例化。可大幅降低 `switch-case` 的圈复杂度。
- **时间计算逻辑降维**：`build_use_time_info` 的分钟级循环在业务扩展后极易成为性能瓶颈。建议将可用时间抽象为“时间区间数组”，利用区间交集/差集算法（如 `array_reduce` 或专用时间库）进行计算，避免逐分钟遍历。
- **规范异常与错误处理**：逐步废弃全局 `throwError`，改用 PHP 原生异常或 CI3 的 `show_error()`。配合全局异常处理器（`set_exception_handler`）实现日志记录与统一响应格式，便于排查线上问题。
- **封装与类型约束**：为类属性添加 `protected` 修饰符，并在 PHP 7.4+ 环境下使用类型声明（如 `public string $platform = '';`），提升静态分析工具（如 PHPStan）的覆盖率。
> ⚠️ **局限性说明**：您提供的代码在 `check_goods` 方法处被截断，未能完整审查该方法的后续逻辑（如套餐查询、状态校验等）。建议补充完整代码以便进行全链路安全与逻辑验证。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779181346
|
1779181346
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
218
|
21
|
29
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `450649498 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `450649498fb2421e75bd21abcf3c576a3bd8481b`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 17:08:50
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：该类实现了多平台团购券的路由分发、Redis 状态缓存、可用时间计算及平台授权校验等核心业务。整体功能完整，但存在严重的架构耦合（巨型 Switch）、硬编码泛滥、时间计算逻辑脆弱、异常静默吞没及潜在的性能瓶颈。部分核心方法（如汉字时长解析、跨天时间构建）缺乏边界保护，易引发线上故障。
- **风险等级**：🔴 高
> 📌 **框架说明**：代码结构（`get_instance()`、`$CI->load->library/model`、`system/` 目录）高度符合 **CodeIgniter 3** 规范。若 `phpci` 为内部定制框架，请确认其生命周期与 CI3 是否一致。以下建议基于 CI3/通用 PHP 最佳实践给出。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `_common_processing` | `switch` 分支中大量 `case`（如 `prepare`、`cancel_verify`）未对 `$result` 赋值，导致方法默认返回空字符串 `''`。调用方依赖 `?: []` 兜底，掩盖了真实执行状态，易引发后续逻辑误判。 | 统一返回值契约：无返回值的方法显式返回 `true`，有返回值的赋值给 `$result`。建议后续采用**策略模式**替代巨型 Switch。 | `case 'prepare': ... $result = true; break;`<br>`return $result ?? true;` |
| 🔴 严重 | `get_duration_in_hours` | 汉字数字转换逻辑存在致命缺陷：仅做字符拼接映射（如“一百”→`"10"`，“十二”→`"12"` 碰巧正确但“二十一”→`"21"` 逻辑脆弱），且正则 `/(\d+)(?=小时)/u` 无法匹配“2.5小时”、“半小时”等常见业务场景。 | 废弃手动循环映射，改用成熟的正则提取+标准化解析，或引入 `symfony/string` 等组件。 | 见下方优化代码 |
| 🟠 警告 | `get_tuangou_platform_list` | 循环内调用 `get_tuangou_platform_shop_id()`，每次均触发 `_common_processing` 并重复加载 Model/Library，存在明显的 **N+1 查询/加载隐患**。 | 提前批量获取门店授权配置，或在循环外统一加载依赖，避免重复 I/O。 | 优化循环逻辑，先 `array_keys` 批量查库，再过滤。 |
| 🟠 警告 | Redis 操作方法 | `try { ... } catch (RedisException $e) {}` 静默吞没异常，且每次调用 `get_aliyun_redis_conn()` 后手动 `$redis->close()`，破坏连接池复用，增加 TCP 握手开销。 | 移除空 `catch`，记录日志；使用单例或框架 Cache Driver 管理连接，移除手动 `close()`。 | `$this->redis = get_aliyun_redis_conn();`<br>`// 移除 close()，交由连接池管理` |
| 🟠 警告 | `build_use_time_info` | 时间计算逻辑极度复杂，混用全局函数（`timeToHour`、`mergeTimeRanges`）、硬编码 `86400` 及字符串拼接。跨天/跨周边界处理脆弱，难以单元测试。 | 引入 `DateTime`/`DateInterval` 或 `nesbot/carbon`，将时间计算抽离为独立的 `TimeCalculator` 服务类。 | 建议重构为独立 Service，使用 `Carbon::parse()` 链式操作。 |
| 🟡 建议 | 全局常量使用 | `switch` 中直接使用字符串 `'-1'`、`'1'` 等，未使用已定义的类常量，降低可读性且易拼写错误。 | 全面替换为 `self::JUHAISHOP`、`self::DOUYINTUANGOU` 等常量。 | `case self::JUHAISHOP:` |
| 🟡 建议 | 异常处理机制 | 使用全局函数 `throwError()` 抛出错误，不符合现代 PHP 异常处理规范，不利于上层统一捕获、日志记录与 API 标准化响应。 | 替换为标准 `throw new \InvalidArgumentException('...')` 或框架内置异常类。 | `throw new \RuntimeException('该门店未绑定平台店铺');` |
| 🟡 建议 | 属性可见性 | 大量业务状态属性（如 `$platform`、`$verify_token`、`$prepare_result`）声明为 `public`，外部可随意修改，破坏类内部状态一致性。 | 改为 `protected` 或 `private`，通过 `getVoucherInfo()` / `setPlatform()` 等方法暴露必要接口。 | `protected $platform = '';` |
### 🔧 核心问题修复示例
**1. 修复 `get_duration_in_hours` 解析逻辑**
```php
public function get_duration_in_hours(string $goods_title): float
{
if (!$this->check_goods_title) {
return 1.0;
}
// 匹配数字（支持整数/小数）+ 小时/钟
if (preg_match('/(\d+(?:\.\d+)?)\s*(?:小时|钟)/u', $goods_title, $matches)) {
return (float) $matches[1];
}
// 匹配“半”小时
if (preg_match('/半\s*(?:小时|钟)/u', $goods_title)) {
return 0.5;
}
return 0.0;
}
```
**2. 优化 Redis 连接与异常处理**
```php
private function getRedis(): \Redis
{
static $redis = null;
if ($redis === null) {
$redis = get_aliyun_redis_conn('', 34);
}
return $redis;
}
public function save_voucher_info_to_redis(array $voucher_info = []): bool
{
$CI = &get_instance();
if (empty($CI->uid)) {
return false;
}
$data = $voucher_info ?: $this->getVoucherDataArray(); // 抽离数据组装逻辑
$data['operational_scene'] = $CI->operational_scene ?? '1';
$key = $this->voucher_redis_key . $CI->uid;
try {
$redis = $this->getRedis();
$redis->set($key, json_encode($data, JSON_THROW_ON_ERROR));
$redis->expire($key, 7200);
} catch (\RedisException $e) {
log_message('error', 'Redis save voucher failed: ' . $e->getMessage());
return false;
}
return true;
}
```
## 3. 总结与行动建议
### 🚨 优先修复项（P0）
1. **统一 `_common_processing` 返回值契约**：明确区分“执行动作”与“获取数据”的分支，避免返回空字符串导致调用方误判。
2. **修复时长解析漏洞**：替换脆弱的汉字映射逻辑，支持小数、半字等真实业务输入，防止套餐时长计算错误引发资损。
3. **移除空 `catch` 与手动 `close()`**：Redis 异常必须记录日志，连接交由底层池化管理，避免连接泄漏或性能抖动。
### 🛠 后续重构方向
1. **架构解耦（策略模式）**：将抖音、美团、巨嗨等平台逻辑抽离为独立的 `PlatformStrategy` 类，通过工厂类实例化。消除 `Tuangou` 类中 300+ 行的巨型 `switch`，符合开闭原则。
2. **时间计算服务化**：`build_use_time_info` 与 `get_user_time_info` 耦合度过高。建议引入 `Carbon` 或 `DatePeriod`，将“营业时间交集”、“跨天偏移”、“不可用星期过滤”拆分为独立方法，并补充单元测试。
3. **标准化异常与响应**：全局替换 `throwError()` 为 `throw new \Exception()` 或框架标准异常。配合全局异常处理器，统一返回 JSON 错误码，提升 API 健壮性。
4. **属性封装**：将 `public` 状态属性改为 `protected`，提供只读访问器。防止外部代码意外覆盖 `$verify_token` 或 `$prepare_result` 导致验券状态错乱。
> ⚠️ **局限性说明**：提供的代码在 `check_goods` 方法处截断，无法完整评估该方法的业务闭环与数据库交互安全性。若需全面审查，请补充完整代码片段。建议结合 `phpci` 官方文档确认其自定义 Helper（如 `throwError`、`timeToHour`）的底层实现，以确保框架级兼容性。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779181731
|
1779181731
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
219
|
21
|
30
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `7f29769a1 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `7f29769a1813c2629cafaeb7dbf67e2c7129a3b5`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 17:12:49
---
## 1. 审查摘要
- **代码质量评分**：4 / 10 分
- **总体评价**：该模型承载了门店账户余额、扣款、日志记录及第三方接口上报等核心财务逻辑，但存在严重的 SQL 注入隐患、数据库事务缺失、未定义变量及死代码等致命缺陷。代码风格偏向老旧的 CodeIgniter 3 架构，缺乏现代 PHP 的类型约束、常量管理与金融级代码应有的严谨性。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `modify_shop_account` / `modify_shop_all_account` / `rentDeal` 等多处 | **SQL 注入风险**：使用字符串拼接构造 `UPDATE` 语句（如 `'_operate_balance=_operate_balance+' . $amount`）。若 `$amount` 来源不可控或包含特殊字符，将直接导致 SQL 注入或语法错误。 | 使用框架查询构建器或参数绑定。财务扣款建议在 PHP 层计算后传入，或使用 `set()` 方法并强制类型转换。 | `$this->db->set('_operate_balance', '_operate_balance + ' . (float)$amount, FALSE);`<br>`$this->db->where('_id', $id);`<br>`$this->db->update($this->table_name);` |
| 🔴 严重 | `update_shop_account_by_sms` / `consume_deduction_account` | **财务数据不一致（缺少事务）**：先扣减余额，再插入日志。若日志插入失败或中途抛出异常，余额已扣减但无流水记录，导致账目不平。 | 包裹在数据库事务中，失败时自动回滚。 | `$this->db->trans_begin();`<br>`// 扣款 & 插日志逻辑`<br>`if ($this->db->trans_status() === FALSE) { $this->db->trans_rollback(); return false; }`<br>`$this->db->trans_commit();` |
| 🔴 严重 | `_check_consume_deduction_balance` | **未定义变量错误**：方法开头直接使用 `if (empty($shopInfo))`，但 `$shopInfo` 并未作为参数传入或提前定义，将触发 `Undefined variable` 警告并导致逻辑跳过。 | 修正变量作用域，先查询再判断。 | `$shopInfo = $this->get_one($shopWhere, '_operate_balance,_id');`<br>`if (empty($shopInfo['_operate_balance']) || ...)` |
| 🔴 严重 | `sent_cavca_open_room_order` | **死代码**：方法体第一行直接 `return true;`，导致后续所有业务逻辑（加载模型、计算价格、请求接口）永远不会执行。 | 删除首行 `return true;` 或确认是否为调试遗留代码。若需保留，应通过配置开关控制。 | `// 删除或注释掉首行的 return true;` |
| 🟠 警告 | `rentDeal` | **重复扣款风险**：防重逻辑 `$che = $this->...->get_one($where); if (!empty($che)) { // return true; }` 被注释。若同一订单多次触发，将导致余额被重复扣除。 | 恢复防重判断，或依赖数据库唯一索引约束。 | `if (!empty($che)) { return true; } // 恢复防重` |
| 🟠 警告 | `check_shop_balance` / `check_shop_defaulting` | **魔法数字与硬编码**：大量使用 `9.98`、`0.01`、`'32329'`、`1/2/3/5` 等硬编码值。业务规则变更时需全局搜索替换，极易遗漏。 | 提取为类常量或配置文件。状态值建议定义枚举或常量映射。 | `const DEFAULT_BALANCE_THRESHOLD = 9.98;`<br>`const MERCHANT_ID_EXCLUDED = '32329';` |
| 🟠 警告 | 文件顶部 & 各方法内 | **框架反模式**：`$CI = &get_instance();` 放在类外部会在每次文件被 `include` 时执行，浪费资源且不符合 CI 规范。频繁在方法内 `$this->load->model()` 影响性能。 | 移除顶部 `$CI` 赋值。模型依赖建议在构造函数中统一加载，或使用自动加载配置。 | `public function __construct() { parent::__construct(); $this->load->model('...'); }` |
| 🟡 建议 | 全局 | **命名规范与类型声明**：方法名混用驼峰与下划线（如 `rentCheck` vs `check_shop_balance`）。缺乏 PHP 7+ 类型声明与返回值类型提示，降低可读性与 IDE 支持。 | 统一遵循 PSR-12 命名规范，添加类型声明。 | `public function checkShopBalance(int $merchantId, int $shopId): array` |
| 🟡 建议 | `rentDeal` / `check_shop_defaulting` | **低效时间计算**：`strtotime(date("Ymd"))` 会触发两次函数调用与字符串转换。 | 使用更高效的当日零点计算方式。 | `$start_time = strtotime('today');` 或 `time() - (time() % 86400);` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复 SQL 注入与财务事务**：所有涉及余额增减的 `UPDATE` 操作必须替换为查询构建器或参数化查询，并强制包裹在 `$this->db->trans_begin()` 事务块中。这是保障资金安全的第一道防线。
2. **清除致命逻辑错误**：立即修复 `_check_consume_deduction_balance` 的未定义变量问题，移除 `sent_cavca_open_room_order` 的无效 `return true;`，恢复 `rentDeal` 的防重逻辑。
3. **消除硬编码与魔法值**：将 `0.08`、`9.98`、`0.01`、商户白名单等提取至配置文件或类常量，便于后期运营策略调整。
### 🛠 后续重构与优化方向
- **架构规范化**：当前代码呈现典型的 CodeIgniter 3 特征。若 `phpci` 为内部定制框架，请确认其是否支持依赖注入（DI）与服务容器。建议逐步将模型依赖从 `load->model()` 迁移至构造函数注入，提升可测试性。
- **财务逻辑抽象**：建议将“扣款-记录日志-更新报表”封装为独立的 `AccountService` 或 `TransactionManager`，避免在 Model 层堆积过多业务逻辑，符合单一职责原则（SRP）。
- **增加单元测试**：针对余额扣减、边界条件（如余额为 0、负数、并发扣款）编写 PHPUnit 测试用例，使用 Mock 对象隔离数据库与外部 API，确保核心财务逻辑的稳定性。
- **日志与监控**：外部 API 调用（如音集协接口）目前仅做 `doLog`，建议增加重试机制、超时控制及失败告警，避免第三方服务抖动导致主流程阻塞。
> 💡 **框架说明**：代码结构高度契合 CodeIgniter 3 规范。若 `phpci` 确为独立框架，请核对 `$this->load->model()`、`$this->db->trans_*()` 等 API 是否与官方文档一致。如有差异，请以框架官方生命周期与组件调用方式为准进行适配。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779181969
|
1779181969
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
221
|
21
|
31
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `28bc9b025 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `28bc9b025cfcbeb407a7868ea68305e8259983ed`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 17:28:32
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10
- **总体评价**：代码完整覆盖了预订下单、支付回调、自动退款、消息推送等核心业务链路，逻辑闭环较为清晰。但存在**高危 SQL 注入隐患**、**事务状态机使用不规范**、**N+1 查询性能瓶颈**以及**方法职责过重**等问题。整体可维护性与安全性亟待提升。
- **风险等级**：🔴 高（涉及资金流转与支付回调，安全与事务一致性缺陷可能导致资损或数据不一致）
> 📌 **框架说明**：代码结构高度符合 `CodeIgniter 3.x` 规范（如 `$this->load->model()`、`$this->db->trans_start()`、`get_instance()`）。若 `phpci` 为贵司内部定制框架，请对照其官方文档确认加载器与事务管理器的差异。
---
## 2. 问题详情
| 严重程度 | 文件/位置 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 第10行 (类外部) | `$CI = &get_instance();` 放置在类定义外部。PHP 在 `include/require` 该文件时会立即执行，极易引发 `Fatal Error` 或破坏框架生命周期。 | **移除此全局调用**。CI 模型内部已继承 `$this->load`、`$this->config` 等组件，无需额外获取实例。若方法内确需使用，请在方法内部按需调用。 | `// 删除文件顶部的 $CI = &get_instance(); 与 $CI->load->model(...);` |
| 🔴 严重 | `refund_by_notify` 约第280行 | 字符串拼接构造 SQL 条件：`$log_where = '_relation_id="' . $order_data['_id'] . '" and ...'`。未做参数转义，若 `_id` 来源不可控，将导致 **SQL 注入**。 | 使用框架查询构造器或安全转义函数。避免手动拼接 SQL 字符串。 | `$this->db->where('_relation_id', $order_data['_id'])<br> ->where('_status', 1)<br> ->where_in('_type', [5, 13]);` |
| 🔴 严重 | `check_notify` 事务处理 | 混用 `$this->db->trans_start()`、手动 `trans_rollback()` 与 `trans_complete()`。CI 的 `trans_complete()` 会依据内部状态自动提交/回滚，手动回滚会导致事务状态机混乱，可能引发“假提交”或重复回滚警告。 | 统一事务管理模式。推荐显式使用 `trans_begin()` + `trans_commit()`/`trans_rollback()`，或完全依赖 `trans_start()`/`trans_complete()` 并移除手动回滚。 | 见下方重构示例 |
| 🟠 警告 | `get_list` 循环内 | **N+1 查询性能瓶颈**：在 `foreach` 中循环调用 `$this->ahead_merchant_model->get_one()`。订单量达百级时，数据库连接数与查询耗时将呈线性增长。 | 提取所有 `merchant_id`，使用 `WHERE IN` 批量查询，在内存中构建映射表后赋值。 | 见下方重构示例 |
| 🟠 警告 | 全文多处 | **魔法数字泛滥**：状态码 `-1,1,2,3,4,5`、支付平台 `1,3,14`、短信模板 `56,58` 等硬编码散落各处，业务规则变更时需全局搜索替换，极易遗漏。 | 在类顶部定义 `const` 常量或集中至配置数组，提升可读性与可维护性。 | `const STATUS_PENDING = -1; const STATUS_PAID = 1; const PAY_WX = 1;` |
| 🟠 警告 | `check_notify`, `refund_by_notify` | **方法过长/违反单一职责**：单个方法超 200 行，混合了订单校验、库存扣减、支付退款、流水记录、微信/短信推送等逻辑。难以测试与复用。 | 按职责拆分。将消息推送抽离至 `NotificationService`，退款逻辑抽离至 `RefundProcessor`，主方法仅负责流程编排。 | 建议采用策略模式或服务类封装 |
| 🟡 建议 | 全文 | 数组语法混用 `array()` 与 `[]`；日志函数名 `doLog` 与 `do_log` 不一致；未使用 PHP 7+ 类型声明。不符合 PSR-12 规范。 | 统一使用短数组语法 `[]`；统一日志函数命名；为方法参数与返回值添加类型提示。 | `public function check_notify(string $order_id, string $transaction_id = ""): array` |
| 🟡 建议 | `send_success_msg` | 同步调用微信模板消息与第三方短信 API。支付回调接口通常有超时限制（如 3-5 秒），同步阻塞易导致回调超时重试，引发重复处理。 | 引入消息队列（Redis/RabbitMQ）或使用 CI 的 `ignore_user_abort()` + 异步任务脚本处理非核心通知。 | 建议将推送逻辑改为异步队列消费 |
---
## 3. 总结与行动建议
### 🚨 优先修复项（P0）
1. **修复 SQL 注入漏洞**：立即替换 `refund_by_notify` 中的字符串拼接查询，改用查询构造器或 `$this->db->escape()`。
2. **规范事务管理**：统一使用 `trans_begin()` / `trans_commit()` / `trans_rollback()` 显式控制，或在 `try...catch` 中仅保留 `trans_complete()`，移除中间的手动 `trans_rollback()` 调用。
3. **移除类外部 `$CI` 实例化**：避免文件加载期执行框架方法，防止不可预知的致命错误。
### 🛠 重构与优化方向（P1）
1. **解决 N+1 查询**：将 `get_list` 中的循环查询改为批量 `WHERE IN` 查询，预计可提升列表接口 50%~80% 的响应速度。
2. **消除魔法数字**：建立 `OrderStatus`、`PayPlatform`、`SmsTemplate` 等常量类或配置文件，后续业务迭代将更安全。
3. **方法职责拆分**：
- `check_notify` 拆分为：`validateOrder()` → `checkInventory()` → `processPayment()` → `notifyUser()`
- `refund_by_notify` 拆分为：`calculateRefundAmount()` → `executeGatewayRefund()` → `rollbackInventory()` → `updateOrderStatus()`
4. **异步化非核心链路**：微信模板消息、短信发送、流水日志写入等建议改为异步任务，保障支付回调接口的低延迟与高可用。
### 📝 后续规范建议
- 启用静态代码分析工具（如 `PHP_CodeSniffer` + `PSR-12` 规则集、`PHPStan`）纳入 CI/CD 流水线，拦截语法与类型问题。
- 为资金流转核心方法补充单元测试（PHPUnit），重点覆盖：事务回滚场景、并发库存扣减、退款金额计算边界。
- 若 `phpci` 为定制框架，请确认其事务管理器是否兼容 CI3 的 `trans_status()` 机制，必要时查阅官方文档调整事务写法。
> ⚠️ **局限性说明**：提供的代码片段在末尾处截断（`$remark .= '；套餐不可跨时段使用';`），未能完整审查 `create_community_shop_book_order` 的后续逻辑。建议补充完整文件以便进行全量评估。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779182912
|
1779182912
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
222
|
21
|
32
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `2c6af8c19 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `2c6af8c190553919e523b9424e729bed1fd986f7`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 17:40:23
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：代码实现了复杂的包厢预订时段计算逻辑，涵盖了营业时间、团购券规则、跨天逻辑、清扫时间及多房间状态等场景。但存在**严重的静态缓存串扰**与**实例状态污染**问题，核心方法过长且职责混杂，大量使用魔法值与全局辅助函数，可维护性与性能存在较大隐患。代码末尾被截断，部分逻辑未能完整评估。
- **风险等级**：🔴 高（存在数据串扰与状态累加缺陷，可能直接导致线上预订错乱）
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_days_info()` 开头 | **静态缓存未区分参数导致数据串扰**：`self::$book_days_info` 作为静态属性缓存结果，但方法签名包含 `$merchant_id`, `$shop_id`, `$check_date`, `$add_day`。首次调用后，后续不同门店/日期的请求将直接返回错误缓存。 | 移除静态缓存，或改用带唯一键的缓存机制（如 Redis/CI Cache），键名需包含所有入参。若仅限单次请求内复用，应使用实例属性而非静态属性。 | ```php\n// 错误做法\nif (!empty(self::$book_days_info)) { return self::$book_days_info; }\n\n// 建议做法（请求级缓存）\n$cache_key = md5(implode('_', func_get_args()));\nif (isset($this->cache['book_days'][$cache_key])) {\n return $this->cache['book_days'][$cache_key];\n}\n// ... 计算逻辑 ...\n$this->cache['book_days'][$cache_key] = $result;\nreturn $result;\n``` |
| 🔴 严重 | `get_book_days_info()` 内部 | **实例属性被永久修改**：`if ($add_day) { $this->book_days += 1; }` 会直接修改实例属性。若该方法在同一次请求中被调用多次，天数会持续累加，导致后续逻辑计算错误。 | 使用局部变量进行计算，绝不修改实例配置属性。 | ```php\n$days_to_check = $this->book_days;\nif ($add_day) {\n $days_to_check += 1;\n}\nfor ($i = 0; $i < $days_to_check; $i++) { ... }\n``` |
| 🟠 警告 | `get_book_day_time_info()` 全文 | **方法过长且违反单一职责原则**：该方法超过 300 行，混合了数据查询、时间区间计算、团购券校验、状态标记、数组过滤等逻辑，极难测试与维护。 | 拆分为独立方法：`getShopBusinessHours()`, `calculateUnbookableSlots()`, `applyVoucherRules()`, `filterAvailableSlots()`。主方法仅负责流程编排。 | 见下方重构建议 |
| 🟠 警告 | `get_book_day_time_info()` 约第 180 行 | **多房间交集逻辑存疑**：`$un_book_time = array_intersect(...array_values($all_room_book_time));` 使用展开运算符求交集，意为“所有房间同时被占用的时间”。若业务为“智能推荐任一可用包厢”，此处应求**并集**或采用其他推荐算法。且空数组展开会触发 `ArgumentCountError`。 | 明确业务意图。若为求并集，改用 `array_merge` + `array_unique`。增加空值保护。 | ```php\nif (count($room_type_room_ids) > 1) {\n // 安全求并集示例\n $un_book_time = array_unique(array_merge(...array_values($all_room_book_time)));\n} else {\n $un_book_time = $all_room_book_time[$this->book_room_id] ?? [];\n}\n``` |
| 🟠 警告 | 全局多处 | **频繁调用 `&get_instance()` 与重复加载模型**：在多个方法中重复调用 `$CI = &get_instance();` 及 `$this->load->model()`，增加开销且破坏框架生命周期规范。 | 在 `__construct()` 中统一初始化 CI 实例与依赖模型，或使用 CI 的自动加载机制。 | ```php\npublic function __construct()\n{\n parent::__construct();\n $this->ci = &get_instance();\n $this->load->model([\n 'ahead_shop_config_second_model',\n 'ahead_family_servers_model',\n 'ahead_room_discontinue_rule_model'\n ]);\n // 其他初始化...\n}\n``` |
| 🟡 建议 | 全局属性定义 | **大量使用 `public` 属性暴露内部状态**：如 `$book_time_limit`, `$now_room_book_time` 等均为 `public`，易被外部意外覆盖，破坏封装性。 | 改为 `protected` 或 `private`，通过 Getter/Setter 访问。复杂数据结构建议使用 DTO 或 Value Object 封装。 | ```php\nprotected $book_time_limit = 3600;\npublic function getBookTimeLimit(): int { return $this->book_time_limit; }\n``` |
| 🟡 建议 | 全局多处 | **魔法数字/字符串硬编码**：大量使用 `'1'`, `'2'`, `'3'`, `86400`, `3600`, `'merchantApp'` 等字面量，降低可读性且易引发拼写错误（如 `opreational_scene`）。 | 提取为类常量，统一拼写。 | ```php\nclass Ahead_shop_book_time_info_model extends Simple_model\n{\n const SCENE_KTV = '1';\n const SCENE_BILLIARDS = '2';\n const SCENE_CARD = '3';\n const SECONDS_PER_DAY = 86400;\n const REQUEST_SOURCE_MERCHANT_APP = 'merchantApp';\n // ...\n}\n``` |
| 🟡 建议 | `get_book_day_time_info()` 约第 220 行 | **遍历中修改数组**：`foreach ($time_info as $k => &$v) { ... unset($time_info[$k]); }` 在遍历时直接 `unset` 当前数组元素，在 PHP 中虽可行但易引发指针错乱或不可预期行为。 | 收集需移除的键，遍历结束后统一删除；或改用 `array_filter`。 | ```php\n$keys_to_remove = [];\nforeach ($time_info as $k => $v) {\n if ($date == $today && $v['time'] <= $now_hour_time) {\n $keys_to_remove[] = $k;\n }\n}\nforeach ($keys_to_remove as $k) {\n unset($time_info[$k]);\n}\n``` |
> ⚠️ **局限性说明**：您提供的代码在 `$next_first_hour_range = reset($next_` 处被截断，导致 `_get_un_book_time` 方法后半段及后续逻辑无法审查。若截断部分包含核心时间推算或数据库写入逻辑，请补充完整代码以便进行二次深度审查。
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即修复静态缓存串扰**：`self::$book_days_info` 必须改为带参数维度的缓存或移除，否则多租户/多门店环境下将产生严重的数据错乱。
2. **消除实例状态污染**：禁止在业务方法中修改 `$this->book_days` 等配置属性，全部改用局部变量计算。
3. **修复多房间数组交集隐患**：确认 `array_intersect(...)` 是否符合“智能推荐”业务预期，并增加空数组保护防止 `ArgumentCountError`。
### 🛠 后续重构与优化方向
1. **方法拆分与职责分离**：将 `get_book_day_time_info` 拆分为 4~5 个私有方法，分别负责：
- 获取基础配置与营业时间
- 计算不可预订时间段（含跨天、清扫、锁定）
- 应用团购券/套餐规则过滤
- 生成最终可用时段列表
2. **引入时间处理组件**：当前大量依赖字符串拼接（`YmdHi`）与 `strtotime`，极易受时区/DST影响。建议引入 `Carbon` 或 `DateTimeImmutable` 进行标准化时间运算，提升精度与可读性。
3. **框架规范对齐**：
- 代码呈现典型的 CodeIgniter 3 风格。若 `phpci` 为 CI 的定制分支或现代重构版，请确认 `$this->load->model()` 与 `&get_instance()` 的官方推荐用法。建议查阅 `phpci` 官方文档中关于 **依赖注入(DI)** 与 **服务容器** 的章节，逐步替换全局实例获取方式。
- 输入参数 `$params` 建议接入框架的验证器（如 CI 的 `Form_validation` 或自定义 DTO 验证），避免直接信任外部传入数组。
4. **性能优化**：
- `ahead_shop_config_second_model->get_shop_setting` 被多次调用，建议改为批量获取或引入请求级缓存。
- 时间区间合并/交集计算可考虑使用位图或区间树算法替代多次 `array_intersect`/`array_merge`，降低 O(N²) 复杂度。
如需对截断部分进行补充审查，或需要针对某个子逻辑（如团购券跨天计算）提供完整重构示例，请随时提供完整代码。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779183623
|
1779183623
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
223
|
21
|
33
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `04183d9fa ## 自动代码审查报告
**分支**: pay-260519
**提交**: `04183d9fab6f49da6fdac02ba5d9dceaf2516c31`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 17:47:50
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：业务逻辑覆盖全面，能够处理跨天、套餐、清扫时间、最低时长等复杂预订场景。但核心方法 `get_book_day_time_info` 严重超长（超 300 行），职责混杂，过度依赖全局函数与硬编码，静态缓存缺乏生命周期管理，存在较高的维护成本与边界逻辑隐患。
- **风险等级**：🟠 中（逻辑复杂易引发边界 Bug，静态状态可能污染，PHP 8+ 兼容性存在隐患）
> 📌 **框架说明**：代码结构、`$CI = &get_instance()`、`$this->load->model()` 及 `system/` 目录特征明确指向 **CodeIgniter 3** 框架。若 `phpci` 为贵司内部定制版，请对照其官方文档微调底层组件调用方式。以下审查基于 CI3 最佳实践与通用 PHP 规范。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_day_time_info` ~L215 | `array_intersect(...array_values($all_room_book_time))` 在 PHP 8+ 中，若数组元素少于 2 个，展开运算符 `...` 会抛出 `Fatal error` 或 `Warning`，导致请求中断。 | 增加元素数量判断，或改用循环/`array_reduce` 安全求交集。 | `if (count($all_room_book_time) > 1) { $un_book_time = array_intersect(...array_values($all_room_book_time)); } else { $un_book_time = reset($all_room_book_time) ?: []; }` |
| 🔴 严重 | 全局静态属性 | `public static $book_days_info = [];` 等静态缓存未提供重置机制。在 CLI 环境、长连接或单元测试中极易引发**状态污染**与脏数据返回。 | 改用 CI3 内置缓存 `$this->cache->save()`，或提供 `clearStaticCache()` 方法。避免在 Model 中滥用静态属性。 | `public static function clearCache(): void { self::$book_days_info = []; self::$shop_data = []; }` |
| 🟠 警告 | `get_book_day_time_info` (全方法) | 方法体超 300 行，混合了数据拉取、时间计算、规则校验、状态赋值，严重违反**单一职责原则(SRP)**，极难编写单元测试与后期维护。 | 拆分为独立私有方法或提取为 `TimeSlotCalculator` 服务类：`fetchRoomBookings()`, `applyPackageConstraints()`, `filterByBusinessHours()`。 | 见下方重构建议 |
| 🟠 警告 | 多处 | 大量使用魔法值（如 `'1'`, `'-1'`, `86400`, `3600`）和硬编码字符串，可读性差且修改易遗漏。 | 定义类常量或独立枚举类，集中管理状态与时间单位。 | `const STATUS_AVAILABLE = '1'; const STATUS_UNAVAILABLE = '-1'; const SECONDS_PER_DAY = 86400;` |
| 🟠 警告 | 构造函数 & 多处 | 频繁调用 `$CI = &get_instance();`。CI3 中可直接通过 `$this->load` 访问，重复获取增加开销且不符合规范。 | 在构造函数中统一赋值 `$this->ci =& get_instance();`，后续直接使用 `$this->ci`。 | `public function __construct() { parent::__construct(); $this->ci =& get_instance(); }` |
| 🟠 警告 | 依赖全局函数 | 强依赖 `throwError`, `mergeTimeRanges`, `shiftTimeRange`, `minutesToUnits` 等全局辅助函数。破坏 OOP 封装，且未验证是否已加载。 | 将时间计算逻辑封装至 `TimeRangeService` 类，通过 `$this->load->library()` 调用，便于 Mock 测试。 | `$this->load->library('TimeRangeService'); $this->time_service->merge($ranges);` |
| 🟡 建议 | 输入参数处理 | `$params['date']`, `$params['merchant_id']` 等直接读取，未做类型校验或过滤。存在越权或类型错误风险。 | 使用 CI3 的 `$this->input->post()` 或 `Form_validation` 进行前置校验，确保数据类型安全。 | `$date = $this->input->post('date', TRUE); if (!preg_match('/^\d{8}$/', $date)) { throwError('日期格式错误'); }` |
| 🟡 建议 | 输出安全 | `$v['unavailable_reason']` 等字段若直接输出至前端，未做 XSS 过滤。 | 在视图层使用 `html_escape()`，或在赋值时进行净化。 | `$v['unavailable_reason'] = html_escape($reason);` |
| 🟡 建议 | 代码截断 | 文件末尾 `$next_first_hour_range = reset($next_` 未完整，无法评估次日时间计算的边界处理。 | 请补充完整代码，以便审查跨天逻辑与数组越界防护。 | 无 |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复 PHP 8+ 兼容性崩溃**：立即处理 `array_intersect(...array_values())` 的空数组展开问题，避免线上致命错误。
2. **清理静态缓存生命周期**：为所有 `public static $xxx` 属性提供 `reset()` 方法，或在请求钩子（如 `post_controller_constructor`）中自动清理，防止多租户/多请求数据串扰。
3. **拆分超长方法**：将 `get_book_day_time_info` 按业务阶段拆分为 `loadDependencies()` → `calculateBaseSlots()` → `applyRules()` → `formatOutput()`，单方法控制在 50 行以内。
### 🛠 后续重构与优化方向
| 优化维度 | 具体方案 |
| :--- | :--- |
| **架构设计** | 引入 **策略模式 (Strategy Pattern)** 处理不同场景（KTV/台球/棋牌/套餐/团购）。将 `book_room_operational_scene` 映射到对应的 `BookingRuleStrategy` 实现类，消除大量 `if/elseif` 分支。 |
| **时间计算** | 将 `mergeTimeRanges`, `shiftTimeRange` 等逻辑抽离为独立的 `TimeRangeCalculator` 值对象/服务类，使用 `DateTimeImmutable` 替代原始时间戳运算，彻底解决跨天/夏令时边界问题。 |
| **性能优化** | 1. 使用 `array_column` + `array_flip` 替代循环 `in_array` 判断。<br>2. 数据库查询结果 `json_decode` 前增加 `json_last_error()` 校验，防止脏数据导致解析失败。<br>3. 考虑将高频查询的门店配置与包厢状态接入 Redis 缓存，降低 DB 压力。 |
| **规范与安全** | 1. 全面启用 PHP 7.4+ 类型声明（`declare(strict_types=1);`、参数类型、返回类型）。<br>2. 输入参数统一走 `Form_validation` 或 DTO 对象校验。<br>3. 遵循 PSR-12，移除冗余注释，使用 PHPDoc 规范方法签名。 |
> 💡 **局限性说明**：由于提交的代码在 `$next_first_hour_range = reset($next_` 处截断，次日时间计算、跨天交集合并及最终返回逻辑未能完整审查。建议补充完整文件后，重点复核 `prev_date`/`next_date` 边界时间戳的加减逻辑是否出现 `00:00` 与 `23:59` 的 Off-by-one 误差。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779184070
|
1779184070
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
224
|
21
|
34
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `0c5f1d82c ## 自动代码审查报告
**分支**: pay-260519
**提交**: `0c5f1d82c3722d79e1bad88ef27af6bc9e0faae5`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 17:51:01
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该模型承载了极其复杂的预订时间计算逻辑，业务覆盖全面，但存在严重的架构设计缺陷。模型过度承担业务计算职责，静态缓存设计在 Web 服务环境下易引发数据串扰，且核心方法冗长、性能开销大。代码未遵循 PSR-12 规范，依赖大量未声明的全局函数，可维护性与可测试性较低。
- **风险等级**：🔴 高
> 📌 **框架说明**：代码结构、`$CI = &get_instance()` 调用方式及目录规范高度符合 **CodeIgniter 3** 框架特征。若 `phpci` 为内部定制版或别名，请确认其生命周期与 CI3 一致。以下审查基于 CI3 最佳实践及现代 PHP 规范。
> ⚠️ **局限性说明**：提供的代码在 `_get_un_book_time` 方法末尾被截断（`$next_first_hour_range = reset($next_`），无法完整评估跨天时间计算逻辑。以下审查基于已提供片段。
---
## 2. 问题详情
| 严重程度 | 文件/位置 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 全局静态属性<br>`self::$book_days_info`<br>`self::$shop_data` 等 | 静态属性在 PHP-FPM/持久化进程环境下会跨请求保留。若未显式清理，极易导致不同用户、门店或请求间的数据串扰与缓存污染。 | 改为实例属性 `$this->cache_data`，或使用 CI 内置 Cache 驱动（如 Redis/Memcached）。若仅用于单次请求内复用，应在方法入口或 `__destruct` 中重置。 | ```php<br>// 推荐：使用实例属性或 CI Cache<br>private $request_cache = [];<br><br>public function get_shop_data($id) {<br> if (isset($this->request_cache[$id])) return $this->request_cache[$id];<br> $data = $this->db->get_where(...)->row_array();<br> return $this->request_cache[$id] = $data;<br>}<br>``` |
| 🔴 严重 | `get_book_day_time_info()`<br>(约 300+ 行) | 严重违反单一职责原则 (SRP)。该方法混合了：参数校验、DB 查询、时间区间计算、团购券规则匹配、UI 状态标记 (`status`, `notice_type`)。导致难以单元测试、调试困难且极易引入回归 Bug。 | 将核心计算逻辑抽离至独立的服务类（如 `BookingTimeCalculator` 或 `TimeSlotService`）。模型仅保留数据存取（CRUD）与基础配置加载。 | ```php<br>// 架构重构示例<br>class BookingService {<br> public function getAvailableSlots($params) {<br> $config = $this->configLoader->load($params);<br> $bookings = $this->bookingRepo->getByDate($params['date']);<br> return $this->timeCalculator->calculate($config, $bookings);<br> }<br>}<br>``` |
| 🟠 警告 | 多处方法内部<br>`$CI = &get_instance();` | 频繁调用 `get_instance()` 增加函数调用开销，且不符合 CI 框架推荐用法。CI 模型本身已继承自 `CI_Model`，可直接使用 `$this->load` 或 `$this->db`。 | 在 `__construct` 中统一获取一次并赋值给 `$this->CI`，后续直接使用。或直接使用 CI 内置方法。 | ```php<br>class Ahead_shop_book_time_info_model extends CI_Model {<br> protected $CI;<br> public function __construct() {<br> parent::__construct();<br> $this->CI =& get_instance();<br> $this->CI->load->model('Simple_model');<br> }<br>}<br>``` |
| 🟠 警告 | `get_book_day_time_info()`<br>循环与数组操作 | 循环内高频调用 `strtotime()`, `date()`, `array_intersect()`, `array_merge()`, `sort()`。时间复杂度呈 O(n²) 甚至更高，在并发高或时间段密集时易造成 CPU 飙升。 | 1. 预计算时间戳，避免在循环内重复转换。<br>2. 使用区间树或位图优化时间交集判断。<br>3. 减少不必要的 `array_unique` 和 `sort`。 | ```php<br>// 优化前<br>$start = strtotime($date . ' ' . $time);<br><br>// 优化后：预计算基准时间戳<br>$base_ts = strtotime($date);<br>$start = $base_ts + $time_offset;<br>// 使用专用时间区间处理库或自定义高效交集算法替代 array_intersect<br>``` |
| 🟠 警告 | 全局函数依赖<br>`throwError`, `timeToHour`, `mergeTimeRanges` 等 | 依赖未声明的全局辅助函数，缺乏类型约束与自动加载保障。在严格模式或不同部署环境下易触发 `Call to undefined function` 致命错误。 | 将全局函数封装为静态工具类（如 `TimeHelper::merge()`），或使用 CI Helper 机制加载。添加 `function_exists()` 防御性检查。 | ```php<br>if (!function_exists('throwError')) {<br> function throwError($msg) { throw new \Exception($msg); }<br>}<br>// 或改用工具类<br>TimeHelper::throwError('请选择预订日期');<br>``` |
| 🟡 建议 | 全文件 | 未遵循 PSR-12 规范。魔法数字/字符串泛滥（如 `'1'`, `'-1'`, `86400`），属性命名不一致（部分驼峰、部分下划线），注释与代码耦合度高。 | 1. 提取状态常量类 `BookingStatus::AVAILABLE = '1'`。<br>2. 统一使用驼峰命名。<br>3. 添加 PHP 7.4+ 类型声明（属性类型、返回值类型）。 | ```php<br>class BookingConstants {<br> public const STATUS_AVAILABLE = '1';<br> public const STATUS_UNAVAILABLE = '-1';<br> public const SECONDS_PER_DAY = 86400;<br>}<br>``` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **消除静态缓存污染风险**：立即将 `self::$book_days_info`、`self::$shop_data` 等静态属性改为实例属性或接入 CI Cache 驱动。这是当前最高优先级的安全隐患，直接关联线上数据准确性。
2. **拆分巨型方法**：`get_book_day_time_info` 必须重构。建议按职责拆分为：
- `fetchBookingData()`：数据查询层
- `calculateTimeSlots()`：核心时间计算层
- `applyVoucherRules()`：团购券规则过滤层
- `formatOutput()`：视图状态标记层
3. **统一 CI 实例调用**：移除方法内部的 `$CI = &get_instance();`，统一在构造函数中初始化，降低运行时开销。
### 🛠 后续重构与优化方向
- **引入服务层架构**：将业务规则（如最低预订时长、清扫时间、跨天逻辑、团购券限制）从 Model 剥离至 `Service/Domain` 层。Model 仅作为数据映射对象（Data Mapper）。
- **时间计算引擎优化**：当前时间区间合并、交集判断逻辑脆弱且低效。建议引入成熟的时间区间处理库（如 `nesbot/carbon` 配合区间扩展，或自研基于时间戳的区间合并算法），避免字符串与时间函数混用。
- **输入校验与安全加固**：`$params` 直接参与业务逻辑，缺乏类型与范围校验。建议在入口处使用 CI `form_validation` 或自定义 DTO 进行强类型校验，防止非法日期、越权 `merchant_id` 传入。
- **单元测试覆盖**：重构后为核心计算逻辑编写 PHPUnit 测试用例，重点覆盖：跨天营业、团购券时长不足、最低开房时长限制、并发预订冲突等边界场景。
> 💡 **提示**：由于代码在 `_get_un_book_time` 处截断，跨天后一天的不可用时间计算逻辑未能完整审查。建议在补全代码后，重点检查 `$next_un_book_time` 的边界条件处理（如 `23:55` 特殊判断、时间戳溢出风险）。如需对完整文件进行二次审查，请提供后续代码片段。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779184261
|
1779184261
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
225
|
21
|
35
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `e27faf6c5 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `e27faf6c59c786fd0d6b4123593926e0cbeb73b4`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 19:27:38
---
## 1. 审查摘要
- **代码质量评分**：6.0 / 10 分
- **总体评价**：代码实现了自助台球/包厢业务的核心链路（状态判断、计费、支付路由、消息推送），业务逻辑覆盖较全。但存在严重的架构反模式（滥用 `$CI` 全局实例导致状态污染）、大量魔法值、SQL 拼接隐患以及不符合现代 PHP 规范的问题。代码末尾存在截断，部分自定义函数未提供源码，影响完整评估。
- **风险等级**：🔴 高（主要因全局状态污染、潜在 SQL 注入风险及高耦合架构导致）
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `check_room` / `get_room_package_list` 等多处 | **全局实例状态污染**：在 Model 中直接修改 `$CI->merchant_id`、`$CI->open_room_ignore_time_info`、`$CI->is_scan_open_room` 等属性。在并发请求、CLI 任务或同一请求多次调用时，会导致严重的数据串扰与逻辑错乱。 | 彻底移除对 `$CI` 属性的直接赋值。改为通过方法参数传递、返回值返回，或封装独立的 `RequestContext` / `DTO` 对象管理请求级状态。 | `// ❌ 错误：$CI->shop_id = $this->room_data['_shop_id'];`<br>`// ✅ 正确：将 shop_id 作为参数传入后续方法，或封装为配置数组返回。` |
| 🔴 严重 | `get_room_page_info` 约第 145-150 行 | **SQL 条件直接拼接**：`$where_str[] = 'FIND_IN_SET(' . $week . ', _week_cycle)';` 等使用字符串拼接构造 SQL。虽当前变量源自 `date()`，但违反安全编码规范，易被后续维护者误用导致注入，且不利于查询计划缓存。 | 使用框架查询构造器（Query Builder）或参数绑定（Prepared Statements）。 | `$this->db->where("FIND_IN_SET(?, _week_cycle)", $week);`<br>`$this->db->where("(_start_time <= ? AND _end_time >= ?)", [$hour_time, $hour_time]);` |
| 🟠 警告 | 全局多处 | **魔法值泛滥**：大量硬编码 `'1'`, `'2'`, `'-1'`, `'2333'` 表示业务状态、场景或错误码。可读性差，后期维护极易引发逻辑分支错误。 | 定义常量类或 PHP 8.1+ `Enum` 统一管理。例如 `class OperationalScene { const KTV = '1'; const BILLIARDS = '2'; ... }` | `if ($this->room_data['operational_scene'] === OperationalScene::TAVERN) { ... }` |
| 🟠 警告 | `check_room` 方法 | **实例属性缓存隐患**：`public $room_data = [];` 在方法内缓存数据。若 Model 实例被复用（如循环处理不同桌台或队列任务），将返回陈旧数据。 | 移除 `public` 可见性，改为私有属性，并在每次调用前重置，或改为纯方法局部变量。 | `private $currentRoomData = null;`<br>`// 方法入口: $this->currentRoomData = null;` |
| 🟠 警告 | `get_actual_pay` / `buy_room_package` 等 | **异常处理不规范**：使用全局函数 `throwError()` 而非 PHP 原生 `Exception`。不利于全局异常捕获、统一日志记录、API 标准化响应及事务回滚。 | 替换为 `throw new \InvalidArgumentException($msg, $code);` 或框架标准异常类，在 Controller 层统一 `try-catch` 并格式化输出。 | `throw new \RuntimeException('该包厢已关房，无法续费', 2333);` |
| 🟡 建议 | 全局 | **未遵循 PSR-12 规范**：缺少参数/返回值类型声明，未开启严格模式，方法可见性不一致，PHPDoc 注释不完整。 | 补充 `declare(strict_types=1);`，添加类型提示，统一命名与注释规范。 | `public function check_room_status(int $uid, int $merchant_id, array $params): array` |
| 🟡 建议 | `get_room_package_list` | **方法过长且职责混杂**：单方法超 150 行，混合了时间计算、套餐过滤、数组重组、配置读取等多重逻辑，违反单一职责原则（SRP）。 | 拆分为独立私有方法：`calculateAvailableTimeRange()`, `filterPackagesByConstraints()`, `buildHourOptions()` 等。 | *(重构建议见第 3 节)* |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **解除 `$CI` 全局状态依赖**：这是当前架构的最大隐患。建议将 `check_room` 返回一个包含 `room_data`、`shop_id`、`merchant_id` 的数组或 DTO，后续方法通过参数接收，彻底切断 Model 与全局实例的隐式耦合。
2. **统一异常与错误处理**：将 `throwError()` 替换为标准 `Exception`，并在入口层（Controller/Router）配置全局异常处理器，确保错误码、堆栈信息不直接暴露给前端，同时支持事务自动回滚。
3. **消除 SQL 拼接隐患**：全面审查 `where` 条件构造逻辑，强制使用参数绑定或框架提供的 `where()` 链式调用，杜绝字符串拼接。
### 🛠 后续重构与优化方向
- **引入常量/枚举管理**：创建 `config/constants.php` 或独立的 `Enums/` 目录，集中管理 `RoomStatus`、`OperationalScene`、`PayPlatform`、`RedirectPage` 等业务标识，替换所有魔法值。
- **拆分臃肿方法**：`get_room_package_list` 和 `get_pay_page_info` 建议按“数据获取 -> 规则计算 -> 视图组装”三层拆分。例如将时间窗口计算、套餐过滤逻辑抽离至独立的 `RoomPackageCalculator` 服务类。
- **性能优化**：
- `FIND_IN_SET` 在数据量大时会导致全表扫描。建议将 `_week_cycle` 改为 `TINYINT` 位运算字段，或使用关联表/JSON 字段配合索引优化。
- 提取 `time()`、`date()` 调用为方法首行的局部变量（如 `$now = time();`），避免重复系统调用。
- **框架适配说明**：当前代码结构高度类似 **CodeIgniter 3**。若 `phpci` 为基于 CI 的定制框架，建议遵循其官方文档中关于 `Model` 生命周期与 `$CI` 实例使用的规范。若为自研框架，强烈建议引入依赖注入（DI）容器替代 `get_instance()`，以提升可测试性与架构清晰度。
> ⚠️ **局限性说明**：提供的代码在 `get_valid_room_package_coupon` 方法末尾截断，无法审查该方法的完整逻辑与返回值。此外，`throwError`、`send_mini_content`、`hourToTime` 等全局辅助函数未提供源码，本次审查基于其常规行为假设。建议补充完整代码以便进行更精准的边界条件与异常流分析。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779190058
|
1779190058
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
226
|
21
|
36
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `a6f2f474b ## 自动代码审查报告
**分支**: pay-260519
**提交**: `a6f2f474b2308faa019937df9c9b916fb7e0e20e`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 19:42:44
---
## 1. 审查摘要
- **代码质量评分**：5.0 / 10 分
- **总体评价**：业务逻辑覆盖较为完整，能够支撑自助台球/包厢的开台、续费、支付及优惠券核销等核心流程。但代码存在**严重的安全隐患（SQL注入）**、**架构反模式（全局CI实例污染）**、**大量魔法数字**以及**文件末尾代码截断**等问题。整体可读性与可维护性较低，不符合现代 PHP 工程规范。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_user_reward_model.php` / `get_my_reward_list()` 约第 250 行 | **SQL 注入风险**：使用 `REGEXP` 直接拼接 `$shopIds` 变量。即使数据源自数据库，未转义直接拼入 SQL 仍可能被恶意构造绕过或引发语法错误。 | 使用框架查询构建器（Query Builder）或严格转义，推荐改用 `FIND_IN_SET` 或 `IN` 语法。 | `$this->db->where("FIND_IN_SET('{$this->db->escape_str($shop_id)}', reward._satisfy_shop_ids)");` |
| 🔴 严重 | `Ahead_billiards_model.php` / 文件顶部 & `check_room()` | **全局 CI 实例污染与并发风险**：在类外部执行 `$CI = &get_instance();` 违反框架加载规范；在方法内直接修改 `$CI->merchant_id` 等属性，在多请求并发下会导致数据串扰。 | 移除文件顶部的 `get_instance()`；使用类属性或上下文对象传递状态，避免修改全局 `$CI`。 | `// 类内部使用<br>private $context = [];<br>$this->context['merchant_id'] = $merchant_id;` |
| 🔴 严重 | `Ahead_user_reward_model.php` / 文件末尾 | **代码截断/语法错误**：`get_valid_coupon()` 方法末尾 `continue` 缺少分号，且缺失闭合大括号 `}`，直接导致 PHP 解析失败（Fatal Error）。 | 补全缺失的语法符号，并检查版本控制提交是否遗漏代码。 | `continue;<br>}<br>}<br>return [...];` |
| 🟠 警告 | `Ahead_billiards_model.php` / `get_room_page_info()` 约第 230 行 | **原始 SQL 拼接**：`FIND_IN_SET` 中直接拼接 `$this->room_data['_id']`，未使用框架转义机制，存在潜在注入风险。 | 使用 CI 的 `$this->db->escape()` 或查询构建器。 | `$this->db->where("FIND_IN_SET(" . $this->db->escape($this->room_data['_id']) . ", _room_ids)");` |
| 🟠 警告 | `Ahead_billiards_model.php` / `buy_room_package()` | **未初始化变量直接返回**：`$chinaums_url`、`$jsApiParameters` 在特定分支未赋值，若逻辑未命中则返回 `undefined` 或触发 Notice。 | 在方法开头统一初始化变量，或使用空合并运算符 `??`。 | `$chinaums_url = ''; $jsApiParameters = [];`<br>`$return_data['chinaums_url'] = $chinaums_url;` |
| 🟠 警告 | 两文件多处 | **魔法数字/字符串泛滥**：大量使用 `'1'`, `'2'`, `2333`, `'ktv'` 等硬编码，业务语义不清晰，后期维护成本极高。 | 提取为类常量或独立配置数组，增强可读性与可维护性。 | `const SCENE_KTV = '1'; const SCENE_BILLIARDS = '2'; const ERR_ROOM_NOT_FOUND = 2333;` |
| 🟠 警告 | `Ahead_billiards_model.php` / `check_room_status()` | **逻辑分支过深且含注释废弃代码**：`switch` 嵌套 `if/else` 超过 4 层，且保留大段注释掉的旧逻辑，极易引发状态遗漏。 | 使用策略模式或提取独立私有方法（如 `handleConsumingRoom()`, `handleBookedRoom()`），清理废弃代码。 | `private function handleConsumingStatus(array $room, int $uid): array { ... }` |
| 🟡 建议 | 两文件多处 | **重复加载模型**：同一方法内多次调用 `$this->load->model()`，增加框架 I/O 开销。 | 在 `__construct()` 中统一加载，或依赖 CI 的自动加载配置。 | `public function __construct() { parent::__construct(); $this->load->model('ahead_yc_shop_model'); }` |
| 🟡 建议 | 两文件多处 | **频繁调用 `time()`**：同一请求周期内多次调用 `time()`，可能导致跨秒边界时时间不一致。 | 在类初始化时缓存当前时间戳。 | `protected $now; public function __construct() { $this->now = time(); }` |
| 🟡 建议 | 两文件多处 | **缺乏类型声明与 PSR-12 规范**：方法无参数类型/返回类型提示，变量命名风格不统一（`$params`/`$param`/`$vip_param`）。 | 遵循 PHP 7.4+ 类型声明规范，统一命名风格，使用 IDE 自动格式化。 | `public function check_room(int $merchant_id, array $params): bool` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复语法阻断**：立即补全 `Ahead_user_reward_model.php` 末尾的 `continue;` 及闭合括号，否则代码无法运行。
2. **消除 SQL 注入隐患**：全面替换 `REGEXP` 和 `FIND_IN_SET` 中的字符串直接拼接，统一改用框架查询构建器或 `$this->db->escape()`。
3. **隔离全局状态**：移除文件顶部的 `$CI = &get_instance();`，禁止在 Model 中直接修改 `$CI->xxx` 属性。建议通过方法参数传递上下文，或使用独立的 `Context` 对象。
4. **清理废弃逻辑**：删除 `check_room_status()` 中注释掉的旧版台球逻辑，避免后续开发者误判或引入分支冲突。
### 🛠 后续重构与优化方向
1. **架构分层**：当前 Model 承担了过多业务逻辑（状态判断、价格计算、支付路由、微信消息推送）。建议引入 **Service 层**，将 `check_room_status`、`get_actual_pay` 等复杂流程抽离至 `BilliardsService`，Model 仅负责数据持久化。
2. **常量与配置管理**：建立 `config/billiards.php` 或类常量文件，集中管理运营场景码、错误码、页面跳转标识等，彻底消除魔法数字。
3. **性能优化**：
- `build_reward_data()` 中存在隐式 N+1 查询风险，建议将关联数据（门店、套餐、商品）批量查询后通过 `array_column` 建立映射字典，在循环中直接读取。
- 对高频调用的 `time()`、`date()` 进行请求级缓存。
4. **规范与安全加固**：
- 补充 PHP 类型声明（`declare(strict_types=1);`、参数类型、返回类型）。
- 敏感日志脱敏：`do_log($open_id . '-' . var_export($res, true))` 可能泄露用户隐私或第三方接口密钥，建议对 `$open_id` 进行掩码处理，并过滤 `$res` 中的敏感字段。
- 若 `phpci` 为内部定制框架，请核对上述 `$CI` 生命周期管理是否符合其官方规范；若实为 CodeIgniter 3，上述建议完全适用。
> 💡 **提示**：本次审查基于提供的代码片段。若 `Ahead_user_reward_model.php` 末尾存在未提交的完整逻辑，请补充后重新评估 `get_valid_coupon()` 的优惠券过滤规则与并发锁机制。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779190964
|
1779190964
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
227
|
21
|
37
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `3f35b1a10 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `3f35b1a10656366e7b6e98afaaae5cf9bfcb13e1`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 19:44:17
---
## 1. 审查摘要
- **代码质量评分**：5.5/10
- **总体评价**：代码实现了较为复杂的自助台球/包厢业务流转，但存在明显的架构耦合与规范缺失。大量重复的模型加载、全局状态污染、魔法数字硬编码以及未做边界校验的循环逻辑，显著增加了维护成本与运行时风险。部分安全与性能隐患需优先修复。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `check_room()` 方法内 | 直接修改全局 CI 实例属性 (`$CI->merchant_id = $merchant_id;` 等)，破坏请求隔离性。在多并发或异步任务中极易引发数据串扰与状态泄漏。 | 移除对 `$CI` 超全局对象的直接赋值。应通过方法参数传递、Session 存储、或使用框架的 `Config`/`Registry` 组件管理上下文。 | `$this->config->set('merchant_id', $merchant_id);`<br>或封装为独立的 `RoomContext` 对象传递。 |
| 🔴 严重 | `get_room_package_list()` 约第 180 行 | `for` 循环步长依赖 `$this->ahead_shop_book_time_info_model->min_minute_unit_time`，未做 `>0` 校验。若配置异常为 `0`，将触发死循环耗尽 CPU/内存。 | 增加步长防御性校验，失败时抛出明确异常或 fallback 到默认值。 | `if ($step <= 0) { throw new \InvalidArgumentException('时间步长必须大于0'); }` |
| 🔴 严重 | `get_room_page_info()` 约第 230 行 | 使用字符串拼接构造 `where` 条件 (`FIND_IN_SET(...)`) 并传入查询构建器。未使用参数绑定或严格转义，存在潜在 SQL 注入风险。 | 优先使用 CI 查询构建器的安全方法，或对拼接变量进行强制类型转换/转义。 | `$this->db->where("FIND_IN_SET(" . (int)$this->room_data['_id'] . ", _room_ids)");` |
| 🟠 警告 | 全局多处 | 每个方法开头重复调用 `$this->load->model()`。CI 框架虽支持重复加载，但频繁 I/O 会降低性能，且破坏代码整洁度。 | 在 `__construct()` 中统一加载依赖模型，或配置 `config/autoload.php` 自动加载。 | `public function __construct() { parent::__construct(); $this->load->model('ahead_xxx_model'); }` |
| 🟠 警告 | 全局多处 | 大量魔法数字/字符串（如 `'1'`, `'2'`, `2333`, `10`, `11`）散落各处，业务语义模糊，后续迭代极易误改。 | 提取为类常量或独立配置文件，统一枚举管理。 | `const SCENE_KTV = '1'; const SCENE_CHESS = '3'; const ERR_ROOM_NOT_FOUND = 2333;` |
| 🟠 警告 | `buy_room_package()` 约第 380 行 | `defined('FACILITATOR')` 常量名疑似拼写错误（常见应为 `FACILITATOR` 或 `FACILITATOR`？），可能导致服务商模式分支永远不执行。 | 核对全局常量定义，修正拼写并严格使用 `===` 比较。 | `if (defined('FACILITATOR') && FACILITATOR === 1)` |
| 🟡 建议 | `check_room_status()` 等 | 核心方法过长（超 150 行），嵌套 `if/switch` 极深，违反单一职责原则（SRP），可读性与可测试性差。 | 按 `operational_scene` 拆分逻辑至独立私有方法，主方法仅做路由分发。 | `private function handleTavernStatus($uid, $params) { ... }` |
| 🟡 建议 | 全局日志处 | `do_log($open_id . '-' . var_export($res, true), ...)` 直接打印完整响应数组，可能泄露 OpenID、Token 或敏感业务数据。 | 日志记录前进行脱敏，或仅记录关键状态码/错误信息。 | `do_log("{$open_id}-status:" . ($res['code'] ?? 'unknown'), 'billiardsPush');` |
| 🟡 建议 | PHPDoc 注释 | 注释不规范，如 `@return true` 非标准类型声明；方法签名缺少 PHP 7+ 类型提示，不利于静态分析与 IDE 提示。 | 遵循 PSR-5/PSR-12，补充参数与返回值类型声明。 | `public function send_mini_msg(string $open_id, int $room_id, int $merchant_id, int $shop_id): bool` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **消除全局状态污染**：立即移除 `$CI->xxx = $value` 的写法。这是导致线上偶发性数据错乱的常见根源。建议改用 `Session` 或方法参数透传。
2. **防御性编程加固**：为 `min_minute_unit_time` 等外部配置增加 `>0` 校验；对 `FIND_IN_SET` 等动态 SQL 片段强制类型转换或使用查询构建器安全接口。
3. **常量与枚举化**：将散落的 `'1'`/`'2'`/`2333` 等提取为 `const`，建立业务状态字典，降低后续维护的认知负荷。
### 🛠 后续重构与优化方向
- **方法拆分与策略模式**：当前 `check_room_status` 和 `get_room_package_list` 承载了台球、KTV、棋牌、酒馆等多套逻辑。建议引入 **策略模式 (Strategy Pattern)**，将不同 `operational_scene` 的处理逻辑抽离为独立类，主 Model 仅负责上下文组装与路由。
- **查询性能优化**：`get_room_package_list` 中存在多次 `foreach` 遍历、`unset` 与 `array_values` 重建索引。可考虑在数据库层使用更精准的 `WHERE` 条件过滤，或使用 `array_filter` 替代手动 `unset`，减少内存拷贝。
- **日志规范化**：建议接入结构化日志（如 Monolog），对 `var_export` 输出进行 JSON 序列化与敏感字段过滤，便于 ELK 等日志平台检索与告警。
- **框架适配说明**：注：当前代码结构高度符合 **CodeIgniter 3** 规范。若 `phpci` 为基于 CI3 的定制框架，上述建议可直接应用；若为全新架构，请查阅 `phpci` 官方文档确认其依赖注入（DI）容器与模型加载机制，逐步替换 `$this->load->model()` 为构造函数注入。
> ⚠️ **局限性提示**：提供的代码在 `get_valid_room_package_coupon()` 方法末尾截断，未能完整审查该方法的后续逻辑（如优惠券校验、库存扣减等）。建议补充完整代码后再次进行针对性审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779191057
|
1779191057
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
228
|
21
|
38
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `9508f796c ## 自动代码审查报告
**分支**: pay-260519
**提交**: `9508f796c462fe49f6d673e0f662e51fa6a7cfdc`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-19 19:57:05
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该模型承载了极其复杂的计费、时段匹配、跨天处理与VIP折扣逻辑，业务实现完整但高度耦合。代码中存在多处影响财务精度的浮点运算、数组遍历指针误用、潜在SQL注入风险及性能瓶颈。模型职责过重，混合了数据查询、业务计算与视图数据格式化，不符合现代 MVC 分层规范。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_timing_by_room_id` (约第 70 行) | `foreach ($timingData as $key => &$timeItem)` 循环内部混用 `next($timingData)` 修改数组内部指针，且使用引用传递。PHP 的 `foreach` 会复制数组指针，混用会导致遍历错乱、跳过元素或死循环。 | 移除 `next()`，改用索引遍历或提前将“次日数据”独立查询并合并。避免在 `foreach` 中操作迭代器指针。 | `// 错误做法<br>foreach ($arr as $k => &$v) { next($arr); }<br><br>// 正确做法：使用 for 循环或提前构建映射数组<br>for ($i = 0; $i < count($timingData); $i++) { ... }` |
| 🔴 严重 | `get_now_price`, `get_date_time_price_info` 等多处 | `where` 条件中直接拼接变量至 SQL 字符串（如 `FIND_IN_SET('{$room_id}', _room_ids)`）。若框架查询构造器未对该键值进行强制转义，将导致 SQL 注入。 | 使用参数绑定或框架提供的安全查询方法，确保所有外部输入经过严格过滤/转义。 | `$this->db->where("FIND_IN_SET(?, _room_ids)", $room_id);<br>// 或框架封装的安全写法<br>$where['where'][] = ['FIND_IN_SET(?, _room_ids)', $room_id];` |
| 🔴 严重 | `calculate_timing_cost`, `calculate_timing_cost_count` 等多处 | 使用浮点数进行金额累加（`$cost += $priceFlag * $till;`）。PHP 浮点数精度缺陷会导致 `0.00000001` 级误差，长期累积或高并发下极易引发财务对账失败。 | 金额计算统一转为“分”（整数）或使用 `bcmath` 扩展。仅在最终返回时格式化为元。 | `$cost = bcadd($cost, bcmul($priceFlag, $till, 4), 2);<br>// 返回前转换<br>'cost' => number_format(bcdiv($cost, 100, 2), 2, '.', '')` |
| 🟠 警告 | `get_date_time_price_info` (约第 450 行) | 使用 `for ($i = $start_time; $i < $end_time; $i += 300)` 按 5 分钟步长生成时间数组。跨天或长时段会生成数百个数组元素，内存占用高且无必要。 | 改为区间逻辑计算，仅在 API 响应前按需生成；或引入缓存/预计算表，避免实时循环生成。 | `// 改为区间记录，前端/视图层按需展开<br>$ranges[] = ['start' => $start_time, 'end' => $end_time, 'price' => $price];` |
| 🟠 警告 | 全文多处 | 频繁调用未声明的全局函数（`throwError`, `hourToTime`, `preMinute`, `getNextUnitTime` 等）。若 Helper 未自动加载，将触发 `Fatal Error`。 | 在 `config/autoload.php` 中统一加载对应 Helper，或封装为静态工具类 `TimingHelper::hourToTime()` 并添加 `function_exists()` 防御。 | `if (!function_exists('hourToTime')) { throw new \RuntimeException('Helper not loaded'); }` |
| 🟡 建议 | 全文 | 魔法数字泛滥（`86400`, `3600`, `0.01`, `8`, `9`, `300` 等），降低可读性与后期维护成本。 | 提取为类常量，集中管理业务阈值与类型标识。 | `const SECONDS_PER_DAY = 86400;<br>const TYPE_BD = 8;<br>const TYPE_NEXT_BD = 9;` |
| 🟡 建议 | `get_timing_by_room_id` 等 | 参数命名不一致（`$extraParams` vs `$extParams`），存在拼写错误（`$startInitTiem`），且模型内重复调用 `$this->load->model()`。 | 统一参数命名规范；修复拼写错误；将依赖模型加载移至构造函数或父类初始化方法。 | `public function __construct() {<br> parent::__construct();<br> $this->load->model(['Ahead_family_servers_model', 'Ahead_yc_shop_model']);<br>}` |
| 🟡 建议 | 整体架构 | 模型承担了大量业务计算、价格策略匹配与数据格式化逻辑，违反单一职责原则（SRP）。 | 将计费、时段匹配、VIP折扣逻辑抽离至独立的 `Service` 层（如 `RoomPricingService`），Model 仅保留数据存取与基础查询。 | `// Controller 调用<br>$pricing = new RoomPricingService($this->ahead_room_timing_model);<br>$result = $pricing->calculate($merchantId, $roomId, $start, $end);` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复财务精度隐患**：立即将所有涉及金额加减乘除的逻辑替换为 `bcmath` 函数或整数（分）运算。这是计费系统的核心红线。
2. **消除数组遍历 Bug**：重构 `get_timing_by_room_id` 中的 `foreach` + `next()` 逻辑，改用索引遍历或独立构建 `$nextTimingData` 数组，确保时段匹配逻辑稳定。
3. **封堵 SQL 注入风险**：审查所有包含 `FIND_IN_SET`、`like`、`where` 的查询条件，确保外部参数通过参数绑定传入，禁止直接字符串拼接。
### 🛠 后续重构与优化方向
1. **架构分层解耦**：当前 Model 已演变为“上帝类”。建议按职责拆分为：
- `TimingModel`：仅负责数据库 CRUD 与基础查询。
- `PricingService`：处理计费规则匹配、跨天计算、VIP折扣策略。
- `TimingFormatter`：负责将原始数据转换为前端所需的 `time_str`、`is_default` 等展示格式。
2. **性能优化**：
- 将 `get_date_time_price_info` 中的 5 分钟循环改为区间计算，或引入 Redis 缓存热点时段的定价规则。
- 统一在构造函数中加载依赖模型，避免方法内重复调用 `$this->load->model()`。
3. **规范与可维护性**：
- 提取所有魔法数字为 `const` 常量。
- 统一参数命名风格（推荐 `$extraParams`），修复 `$startInitTiem` 等拼写错误。
- 补充 PHPDoc 类型声明（如 `@param int $merchantId`），便于静态分析工具（如 PHPStan/Psalm）介入。
4. **框架适配说明**：代码结构高度类似 CodeIgniter 3。若 `phpci` 为定制框架，请重点核对 `$this->select()` 与 `$this->get_one()` 对 `where` 数组中原始 SQL 片段的转义策略。若框架未自动转义，必须手动使用查询构造器的参数绑定语法。
> 💡 **提示**：建议在合并前补充单元测试（PHPUnit），重点覆盖：跨天时段匹配、VIP折扣叠加、不满一小时计费规则、以及边界时间（如 `23:59` 与 `00:00`）的精度验证。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779191825
|
1779191825
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
231
|
21
|
41
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `7bc8899d9 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `7bc8899d9e76df8b5780014e1339a037561beb71`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-20 10:58:31
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了完整的预订、支付、退款及消息通知业务流程，但存在明显的遗留架构特征。核心问题集中在**事务控制不规范**、**循环内数据库查询**、**原始SQL拼接风险**以及**魔法数字泛滥**。整体可维护性较低，在高并发或异常场景下易引发数据不一致或性能瓶颈。
- **风险等级**：🔴 高（存在潜在SQL注入风险、事务状态机异常隐患及硬编码配置泄露风险）
> 📌 **框架说明**：从 `$CI = &get_instance()`、`$this->load->model()`、`$this->db->trans_start()` 等特征判断，该代码高度契合 **CodeIgniter 3** 架构。若 `phpci` 为基于 CI3 的定制框架，以下建议同样适用；若为全新架构，请优先确认其事务与模型加载的生命周期规范。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_book_order_model.php` ~L330 | **SQL 注入风险**：`$log_where` 使用字符串拼接传入自定义 `up()` 方法，未做参数绑定或过滤，若 `_id` 含特殊字符将导致注入或语法错误。 | 使用框架查询构造器或确保底层方法支持预处理参数。避免直接拼接 SQL 片段。 | `$this->db->where('_relation_id', $order_data['_id'])->where('_status', 1)->where_in('_type', [5, 13]);`<br>`$this->ahead_pay_log_model->update($log_up, $where_array);` |
| 🔴 严重 | `Ahead_book_order_model.php` L100-L140 | **事务控制不规范**：混用 `trans_start()` 与手动 `trans_rollback()`。CI 框架内部维护事务计数器，手动回滚可能破坏状态机，导致后续查询不在事务中或连接池异常。 | 遵循 CI 标准事务模式：`trans_start()` → 业务逻辑 → `trans_complete()` → 检查 `trans_status()`。异常捕获中仅记录日志，交由框架自动回滚。 | `$this->db->trans_start();`<br>`try { /* 业务逻辑 */ $this->db->trans_complete(); }`<br>`catch(Exception $e) { doLog($e->getMessage()); $this->db->trans_rollback(); }`<br>`if ($this->db->trans_status() === FALSE) { /* 处理失败 */ }` |
| 🟠 警告 | `Ahead_book_order_model.php` L380-L390 | **N+1 查询性能瓶颈**：`get_list()` 的 `foreach` 循环内调用 `get_one()` 查询商家信息，数据量大时将产生大量 DB 连接与查询开销。 | 提取所有 `merchant_id`，使用 `WHERE IN` 批量查询，构建映射数组后在循环中赋值。 | `$ids = array_unique(array_column($order_info, 'merchant_id'));`<br>`$merchants = $this->ahead_merchant_model->get_list(['_id' => $ids], '_id,_business_model');`<br>`$map = array_column($merchants, '_business_model', '_id');` |
| 🟠 警告 | 两个文件顶部 | **全局 `$CI` 实例化与重复加载**：文件顶部 `$CI = &get_instance();` 在类未实例化时执行，违反框架生命周期；方法内频繁 `load->model()` 增加 I/O 开销。 | 移除文件顶部 `$CI` 赋值；将高频依赖模型移至 `__construct()` 中加载，或确保按需加载一次。 | `public function __construct() { parent::__construct(); $this->load->model('ahead_vip_model'); $this->load->model('ahead_shop_model'); }` |
| 🟠 警告 | 全局多处 | **魔法数字泛滥**：`_pay_platform` (1,3,14)、`_status` (-1,1,4)、`_pay_scene` (5,8,9) 等硬编码散落各处，可读性差且极易引发逻辑遗漏。 | 定义类常量或独立配置文件集中管理枚举值，业务逻辑中统一引用。 | `const PAY_WX = 1; const PAY_VIP = 3; const STATUS_PENDING = -1;`<br>`if ($data['_pay_platform'] === self::PAY_WX) { ... }` |
| 🟡 建议 | 全局 | **代码规范不统一**：混用 `array()` 与 `[]`；类名大小写不一致（如 `Ahead_shop_model` vs `ahead_shop_model`）；`doLog` 与 `do_log` 混用。 | 严格遵循 PSR-12：统一使用短数组语法 `[]`；统一类名与加载名的大小写；统一日志函数命名。 | `['key' => 'value']`<br>`$this->load->model('Ahead_shop_model');`<br>`do_log($msg, $channel);` |
| 🟡 建议 | `Ahead_book_order_model.php` L135 | **日志记录性能与安全隐患**：`json_encode($e->getTrace(), 256)` 记录完整调用栈，生产环境易暴露敏感路径且日志体积庞大。 | 仅记录关键错误信息、行号及脱敏上下文。避免在生产日志输出完整 Trace。 | `doLog('支付失败: ' . $e->getMessage() . ' at line ' . $e->getLine(), 'book_order');` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **重构事务控制逻辑**：立即统一 `check_notify`、`refund`、`create_book_order` 中的事务写法，采用 `trans_start()` + `trans_complete()` + `trans_status()` 的标准模式，移除冗余的手动 `trans_rollback()`，防止高并发下数据库连接状态错乱。
2. **消除 SQL 拼接隐患**：将 `refund_by_notify` 中的 `$log_where` 字符串替换为查询构造器或参数化数组。若 `ahead_pay_log_model::up()` 为自定义方法，需确保其底层使用 PDO 预处理。
3. **优化列表查询性能**：修复 `get_list()` 的 N+1 查询问题，改为批量 `WHERE IN` 查询。该优化可显著降低数据库 CPU 与网络延迟。
### 🛠 后续重构与优化方向
- **枚举与配置抽离**：建立 `config/payment_platforms.php` 与 `config/order_status.php`，或使用类常量集中管理状态机。支付场景（`_pay_scene`）与平台（`_pay_platform`）的判断逻辑建议抽离至独立的 `PaymentStrategy` 策略类，降低 `if/else` 嵌套深度。
- **服务层拆分**：当前 Model 承载了过多业务逻辑（支付路由、退款计算、短信发送、社区收入结算）。建议引入 **Service 层**（如 `BookOrderService`、`RefundService`），Model 仅负责数据持久化，符合单一职责原则（SRP）。
- **框架适配确认**：若 `phpci` 为自研框架，请核对以下两点：
1. 模型加载是否支持自动加载（Autoloading）？若支持，可移除所有 `$this->load->model()`。
2. 事务驱动是否兼容 CI3 的计数器机制？若为全新实现，需查阅官方文档确认 `trans_start()` 与手动回滚的兼容性。
- **代码片段局限性说明**：`create_community_shop_book_order` 方法在末尾被截断，无法完整评估其支付路由、团购券核销及异常回滚逻辑。建议补充完整代码后二次审查。
> 💡 **专家提示**：支付与退款链路属于资金敏感型业务，建议在核心节点（如 `refund_by_notify`、`check_notify`）增加**幂等性校验**（如基于 `_trade_no` 或 `_log_id` 的唯一索引/Redis 锁），并补充单元测试覆盖退款分支与事务回滚场景。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779245911
|
1779245911
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
236
|
21
|
42
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `98d481964 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `98d481964b8c1f4240e5b71e6c1edf49a80bba3d`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-20 13:12:50
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该文件为典型的业务逻辑密集型服务类，承担了订单价格计算、会员折扣、优惠券抵扣、服务费核算及套餐组装等核心职责。代码具备完整的业务闭环，但存在**严重违反单一职责原则**、**遗留调试代码**、**潜在 SQL 注入风险**及**财务计算精度隐患**等问题。整体可维护性较低，重构优先级高。
- **风险等级**：🔴 高
> 📌 **框架说明**：代码结构（`BASEPATH`、`get_instance()`、`$this->CI->load->model()`）明确属于 **CodeIgniter 3** 架构，而非 `phpci`（phpci 为 PHP 持续集成服务器）。以下审查将基于 CI3 最佳实践与通用 PHP 规范进行。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `getOrderTypeInfo` 方法内 | **遗留调试输出**：循环中存在 `echo $vip_upgrade_data_actual_pay;`。在生产环境中会破坏 JSON/XML 响应结构，且可能泄露内部计算逻辑。 | 立即删除 `echo`。如需追踪，应使用 CI 日志系统 `$this->CI->log->write_log('debug', $msg);`。 | `// 删除 echo 语句<br>if ($this->CI->config->item('environment') === 'development') {<br> log_message('debug', '升级计算: ' . $vip_upgrade_data_actual_pay);<br>}` |
| 🔴 严重 | `getOrderTypeInfo` 方法内 | **SQL 注入风险**：`$pack_goods_where = "wares_package._package_id in (" . implode(",", $id_array['package_id']) . ")";` 直接拼接数组至 SQL 字符串。若 `$id_array['package_id']` 含未过滤的用户输入，将导致注入。 | 使用 `array_map('intval', ...)` 强制类型转换，或改用 CI 查询构建器。 | `$safe_ids = array_map('intval', $id_array['package_id']);<br>$pack_goods_where = "wares_package._package_id IN (" . implode(',', $safe_ids) . ")";` |
| 🔴 严重 | `getOrderTypeInfo` 方法内 | **数组键覆盖逻辑错误**：`$order['_prime_service_charge']` 被连续赋值两次，第二次 `$service_charge` 覆盖了第一次 `$prime_after_paid_service_charge`，导致业务数据错乱。 | 核对业务定义，保留正确的一次赋值，或重命名键名避免冲突。 | `$order['_prime_service_charge'] = $prime_after_paid_service_charge; // 保留原始值<br>// 删除下方重复赋值行` |
| 🟠 警告 | 全局/多处 | **频繁动态加载模型**：在多个方法内部重复调用 `$this->CI->load->model(...)`。CI3 虽支持懒加载，但高频调用会增加文件 I/O 与内存开销。 | 将依赖模型统一移至 `__construct()` 中加载，或配置 `config/autoload.php`。 | `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>}` |
| 🟠 警告 | `_create_insert_infos_data` 等 | **静态属性访问模型实例**：`$this->CI->Ahead_vip_level_model::VIP_LEVEL_DEFAULT_NAME`。CI3 模型为对象实例，`::` 通常用于类常量。若为属性应使用 `->`，若为常量建议直接引用类名。 | 明确访问方式。若为类常量，使用 `Ahead_vip_level_model::VIP_LEVEL_DEFAULT_NAME`；若为实例属性，使用 `->`。 | `$vip_max_level = count(Ahead_vip_level_model::VIP_LEVEL_DEFAULT_NAME);` |
| 🟠 警告 | 全局价格计算 | **浮点数精度与舍入隐患**：大量使用 `sprintf("%.2f", ...)` 及直接乘除。`sprintf` 仅返回字符串，不改变底层浮点精度，财务累加易产生 `0.000000001` 误差。 | 财务计算统一使用 `round($val, 2)` 或 `bcmath` 扩展。累加前确保为 `float` 类型。 | `$actual_pay = round($goods_price_data['actual_pay'] * $discount_goods_reward, 2);` |
| 🟡 建议 | 类定义 | **违反单一职责原则 (SRP)**：该类同时处理订单组装、价格策略、会员逻辑、优惠券、服务费、套餐解析等，且大量使用 `public` 属性存储中间状态，导致类膨胀且难以测试。 | 按领域拆分：`OrderCalculator`（核心计算）、`VipPriceStrategy`（会员价策略）、`CouponDeductor`（优惠券抵扣）。属性改为 `private/protected`，通过方法参数传递上下文。 | `// 重构方向示例<br>class OrderCalculator {<br> public function calculate(OrderContext $ctx): array { ... }<br>}` |
| 🟡 建议 | 全局 | **不符合 PSR-12 规范**：变量命名随意（`$vv`, `$vls`, `$mar_goods`），缺少类型声明，注释与代码混杂，缩进不一致。 | 启用 IDE 自动格式化，添加 PHP 7.4+ 类型提示（`array`, `int`, `float`），统一使用驼峰命名。 | `private function _create_insert_infos_data(array $goods, int $package_id = 0): array { ... }` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即移除 `echo` 调试语句**：防止生产环境接口响应污染。
2. **修复 SQL 拼接注入风险**：对 `$id_array['package_id']` 进行严格的 `intval` 过滤或改用 Query Builder。
3. **修正 `$order['_prime_service_charge']` 覆盖 Bug**：核对财务字段定义，确保服务费计算链路准确。
4. **统一财务计算精度**：将 `sprintf` 替换为 `round()`，并在关键累加节点增加精度校验。
### 🛠 后续重构与优化方向
1. **架构拆分（核心）**：当前 `getOrderTypeInfo` 方法超过 600 行，嵌套层级深，维护成本极高。建议采用 **策略模式 (Strategy Pattern)** 处理不同订单类型（酒水/套餐/开房），将价格计算、优惠券抵扣、服务费核算抽离为独立服务类。
2. **状态管理优化**：移除类级别的 `public` 状态变量（如 `$room_id`, `$vip_data` 等），改为通过构造函数或方法参数注入。避免并发请求下的状态污染。
3. **异常处理标准化**：当前使用全局函数 `throwError()`，不利于上层捕获与统一响应。建议改为 `throw new \InvalidArgumentException()` 或自定义业务异常类，配合全局异常处理器返回标准 JSON。
4. **性能优化**：
- 模型预加载至构造函数。
- 循环内避免重复调用 `$this->CI->load->model()` 或 `$this->CI->load->helper()`。
- 对 `$goods_quantity`、`$id_array` 等入参增加类型校验与边界限制（如 `max_quantity` 校验）。
5. **代码规范**：引入 `PHP_CodeSniffer` 配合 `PSR-12` 规则集进行 CI 流水线卡点，逐步清理历史技术债。
> ⚠️ **局限性说明**：您提供的代码在 `$result['have_good` 处被截断，未能完整审查 `case '2'/'4'` 的后续逻辑及类末尾的闭合部分。若后续逻辑包含数据库事务控制、支付回调或库存扣减，请补充完整代码以便进行事务一致性与并发安全审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779253970
|
1779253970
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
237
|
21
|
43
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `d0e7d691b ## 自动代码审查报告
**分支**: pay-260519
**提交**: `d0e7d691b58ee95524879913eb502c0f45974de9`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-20 13:52:10
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：业务逻辑覆盖较全面，但存在**严重的密码学误用**、**安全配置隐患**及**分布式事务一致性风险**。代码结构偏向过程式，核心方法（如退款、回调处理）过于臃肿，违反单一职责原则（SRP）。部分金额计算、IP获取及签名逻辑存在明显缺陷，需优先修复。
- **风险等级**：🔴 高
> 📌 **框架说明**：提交代码实际基于 **CodeIgniter 3** 架构（典型特征：`get_instance()`、`$this->load->model()`、`$this->db->trans_start()`）。若确为 `phpci` 定制版，请确认其底层加载机制与 CI3 完全一致。以下审查将基于 CI3 规范及现代 PHP 标准进行。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `GuoTong.php`<br>`checksign()` / `create_sing()` | **密码学逻辑错误**：签名验证误用 `openssl_public_decrypt`，且 `$data` 被 `str_split` 覆盖导致原始数据丢失；签名生成误用公钥加密（应使用私钥签名）。标准 RSA 签名应使用 `openssl_sign()` 与 `openssl_verify()`。 | 替换为标准的非对称签名流程。签名使用私钥+`openssl_sign`，验签使用公钥+`openssl_verify`。 | ```php<br>// 签名<br>openssl_sign($str, $sign, $privateKey, OPENSSL_ALGO_SHA256);<br>return base64_encode($sign);<br><br>// 验签<br>$pubKey = openssl_pkey_get_public($key_pem);<br>$verify = openssl_verify($signStr, base64_decode($sign), $pubKey, OPENSSL_ALGO_SHA256);<br>return $verify === 1;<br>``` |
| 🔴 严重 | `GuoTong.php`<br>`request()` | **SSL 证书验证关闭**：`CURLOPT_SSL_VERIFYPEER` 与 `CURLOPT_SSL_VERIFYHOST` 设为 `false`，生产环境极易遭受中间人攻击（MITM），导致支付数据被劫持或篡改。 | 生产环境必须开启证书验证，并配置正确的 CA 证书路径。 | ```php<br>curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);<br>curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);<br>curl_setopt($ch, CURLOPT_CAINFO, APPPATH.'config/cacert.pem');<br>``` |
| 🔴 严重 | `GuoTong.php`<br>`get_client_ip()` | **IP 伪造漏洞**：直接信任 `HTTP_CLIENT_IP` 和 `HTTP_X_FORWARDED_FOR`，攻击者可轻易伪造 IP 绕过风控或日志追踪。 | 增加 IP 格式校验，或优先使用框架内置安全方法。仅在内网可信代理下才解析 `X-Forwarded-For`。 | ```php<br>$ip = $_SERVER['REMOTE_ADDR'];<br>if (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) {<br> $list = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']);<br> $ip = trim($list[0]);<br>}<br>return filter_var($ip, FILTER_VALIDATE_IP) ? $ip : '0.0.0.0';<br>``` |
| 🟠 警告 | `GuoTong.php`<br>`create_wx_orderss()` | **浮点数金额计算隐患**：`round($order['totalFee'] * 100, 2)` 仍返回浮点数，后续参与整数运算或入库时可能产生精度丢失（如 `0.1*100 = 10.000000000000002`）。 | 支付金额统一转为**整数分**处理，使用 `(int)round()` 或 `bcmul()`。 | `$params['txamt'] = (int)round($order['totalFee'] * 100);` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`refund()` / `refund_by_notify()` | **事务与外部 API 混合调用**：在 `$this->db->trans_start()` 内调用微信/银联退款 API。若 API 成功但后续 DB 操作失败，事务回滚无法撤销已发生的资金退款，导致**资金不一致**。 | 采用**最终一致性**设计：先落库记录退款单（状态：处理中），异步或独立流程调用支付网关，成功后更新状态。增加幂等键防重。 | 见下方“行动建议”第 2 点 |
| 🟠 警告 | `Ahead_book_order_change_pay_log_model.php`<br>`refund()` | **循环退款无原子性保障**：`refund_by_order()` 遍历多条记录调用 `refund()`，若中途某条失败直接 `return`，已成功的退款无法回滚，且未使用数据库事务包裹。 | 使用 `$this->db->trans_start()` 包裹循环，或改为批量处理+状态机。失败时记录异常日志并触发补偿任务。 | ```php<br>$this->db->trans_start();<br>foreach ($log_data as $log) {<br> $res = $this->refund($log, $book_order);<br> if (!$res['status']) { $this->db->trans_rollback(); return $res; }<br>}<br>$this->db->trans_complete();<br>``` |
| 🟡 建议 | `GuoTong.php`<br>`create_wx_orderss()` / `create_ali_orderss()` | **代码高度重复**：两个方法 90% 逻辑一致，仅 `payWay`、`wxAppid`/`zfbappid` 及日志标识不同，违反 DRY 原则。 | 提取公共方法 `create_order($order, $payType)`，通过配置数组区分渠道。 | 见下方“行动建议”第 3 点 |
| 🟡 建议 | 全局文件 | **魔法数字泛滥**：`1, 2, 3, 4, 5, 8, 9, 10` 等硬编码表示支付渠道、场景、状态，可读性差且易引发维护错误。 | 定义常量或枚举类（PHP 8.1+），如 `PayPlatform::WECHAT = 1`。 | `const PAY_PLATFORM_WECHAT = 1;` |
| 🟡 建议 | 全局文件 | **不符合 PSR-12 规范**：缺少类型声明（参数/返回值）、`array()` 与 `[]` 混用、方法职责过重（如 `refund_by_notify` 超 200 行）、拼写错误 `create_sing`。 | 逐步添加类型提示，统一数组语法，拆分大方法，修正拼写。启用 PHPStan/Psalm 静态检查。 | `public function create_sign(array $params): string` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题（P0/P1）
1. **立即修正签名/验签逻辑**：当前 `GuoTong` 类的加解密用法完全违背非对称密码学规范，会导致第三方回调验签失败或伪造签名通过。请严格替换为 `openssl_sign()` / `openssl_verify()`。
2. **开启 SSL 证书验证**：支付网关通信必须启用 `CURLOPT_SSL_VERIFYPEER = true`，否则存在资金劫持风险。
3. **修复 IP 获取逻辑**：增加 `FILTER_VALIDATE_IP` 校验，避免风控策略被绕过。
4. **金额计算转整数**：所有涉及支付、退费的金额在入库或请求前统一转为**分（整数）**，杜绝浮点精度问题。
### 🛠 后续重构与优化方向
1. **引入支付服务层（Service Layer）**：
- 将 `GuoTong`、微信、银联等支付逻辑抽象为独立的 `PaymentService`，采用**策略模式**按渠道路由。
- 模型层仅负责数据持久化，不直接调用外部 HTTP API。
2. **重构退款事务模型（最终一致性）**：
- 退款流程改为：`创建退款单(状态:待处理) -> 调用网关 -> 接收异步回调 -> 更新退款单状态 -> 更新业务订单状态`。
- 增加**幂等性控制**（如基于 `out_refund_no` 唯一索引），防止网络重试导致重复退款。
3. **代码规范与现代化**：
- 统一使用 PHP 7.4+ 类型声明：`public function checksign(array $params): string`
- 使用常量/枚举替代魔法数字，提升可读性。
- 拆分 `refund_by_notify` 等超长方法，按业务域拆分为 `refundWx()`, `refundVip()`, `refundCommunityRevenue()` 等私有方法。
4. **框架适配提示**：
- 代码中大量使用 `$this->load->model()` 动态加载，建议在 CI3 中通过 `$autoload['model']` 预加载高频模型，或使用构造函数一次性加载，减少运行时开销。
- 若后续计划升级至 PHP 8+ 或现代框架（如 Laravel/Symfony），建议尽早剥离 `get_instance()` 强耦合，转向依赖注入（DI）。
> ⚠️ **局限性说明**：`Ahead_book_order_model.php` 末尾代码被截断（`create_community_shop_book_order` 方法未完成），无法评估该分支的完整逻辑与异常处理。建议补充完整代码后再次审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779256330
|
1779256330
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
249
|
21
|
46
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `c2f698590 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `c2f6985906699521199792adbee2115351bbaf66`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-20 18:09:59
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该模型承载了核心的预订、支付回调、退款及消息推送逻辑，业务链路完整。但存在**事务边界混乱、SQL拼接注入风险、财务计算精度隐患、方法严重超长违反单一职责原则**等问题。代码风格不统一，硬编码与魔法数字较多，且文件末尾代码被截断，无法评估完整逻辑。
- **风险等级**：🔴 高（涉及资金流转与支付回调，当前实现存在数据不一致与注入风险）
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `check_notify` 方法 | **事务与异常处理冲突**：`$this->db->trans_complete()` 在 `try` 块中提前执行，若后续 `send_success_msg()` 抛出异常，`catch` 块会调用 `trans_rollback()`。此时事务已提交，回滚无效，且会导致支付回调响应超时被平台重试。 | 严格限定事务仅包裹数据库操作。外部API调用（微信/短信/VIP回调）必须移至事务提交后，或放入异步队列。移除包裹外部调用的 `try-catch` 或拆分逻辑。 | ```php<br>// 正确做法：<br>$this->db->trans_start();<br>// ... 仅数据库操作 ...<br>$this->db->trans_complete();<br><br>if ($this->db->trans_status() === FALSE) {<br> // 处理DB失败<br>} else {<br> // 事务成功后再执行外部通知<br> $this->send_success_msg($order_data);<br>}``` |
| 🔴 严重 | `refund_by_notify` 方法 | **SQL 注入漏洞**：`$log_where = '_relation_id="' . $order_data['_id'] . '" and ...'` 直接拼接字符串传入 `up()` 方法。若 `_id` 未严格校验，攻击者可构造恶意输入执行任意 SQL。 | 废弃字符串拼接，全面使用查询构造器或参数绑定。 | ```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', $update_data);``` |
| 🟠 警告 | `refund_by_notify` / `check_notify` | **浮点数精度丢失**：金额计算直接使用 `float` 乘除（如 `$total_amount * 100`），在 PHP 中极易产生 `0.000000001` 级误差，导致退款金额对账失败。 | 财务计算统一转为“分”（整数）处理，或使用 `bcmath` 扩展函数。 | ```php<br>// 使用 bcmath 保证精度<br>$total_fee = bcmul($total_amount, '100', 0);<br>$refund_fee = bcmul($can_refund_amount, '100', 0);``` |
| 🟠 警告 | 文件顶部 | **框架规范违规**：`$CI = &get_instance();` 定义在类外部。CI/类CI框架中，全局获取实例应在类方法内部按需调用，否则可能在自动加载前引发 `Fatal Error`。 | 删除顶部代码，在类内部方法中按需 `$CI =& get_instance();`，或使用 `$this->load->config()` 替代。 | ```php<br>class Ahead_book_order_model extends Simple_model {<br> public function some_method() {<br> $CI =& get_instance();<br> $CI->config->load('wx', TRUE);<br> }<br>}``` |
| 🟠 警告 | `get_list` 方法 | **N+1 查询隐患**：虽使用 `$merchant_business_model` 局部缓存，但循环内仍可能触发多次 DB 查询。若订单列表跨多个商家，性能会显著下降。 | 提取所有 `merchant_id` 使用 `where_in` 批量查询，或在 Service 层统一组装数据。 | ```php<br>$merchant_ids = array_column($order_info, 'merchant_id');<br>$merchants = $this->ahead_merchant_model->get_many(['_id' => $merchant_ids], '_id,_business_model');<br>// 转为 key-value 映射后循环赋值``` |
| 🟡 建议 | 全文件 | **魔法数字与硬编码泛滥**：状态码 `-1, 1, 2, 3, 4, 5, 14, 56, 58, 99` 直接散落在代码中，可读性差且后期维护极易出错。 | 在类顶部定义常量枚举，如 `const STATUS_PENDING = -1; const STATUS_PAID = 1;`。 | ```php<br>class Ahead_book_order_model extends Simple_model {<br> const STATUS_PENDING = -1;<br> const STATUS_PAID = 1;<br> // ...<br>}``` |
| 🟡 建议 | `check_notify`, `refund_by_notify`, `create_community_shop_book_order` | **违反单一职责原则 (SRP)**：单个方法超过 150~200 行，混合了参数校验、库存扣减、事务控制、第三方退款、日志记录、消息推送。 | 按业务域拆分为独立服务类：`OrderValidator`、`InventoryService`、`RefundProcessor`、`NotificationDispatcher`。模型仅保留数据访问层逻辑。 | *(架构级建议，无需具体代码)* |
| 🟡 建议 | 全文件 | **代码规范不统一**：数组语法混用 `array()` 与 `[]`；日志函数名不一致 (`doLog` vs `do_log`)；存在大量注释掉的死代码。 | 统一使用短数组语法 `[]`；统一日志函数命名；清理无用注释代码；严格遵循 PSR-12。 | *(使用 PHP-CS-Fixer 或 IDE 格式化即可)* |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复事务边界**：立即将 `check_notify` 中的 `$this->db->trans_complete()` 移至所有数据库操作结束后，确保外部 API 调用不在事务块内。若外部调用失败，不应影响已提交的支付状态，应记录日志并走补偿机制。
2. **消除 SQL 注入**：全局搜索 `$this->...->up($log_up, $log_where)` 及类似字符串拼接查询，全部替换为 CI Query Builder 或预处理语句。
3. **金额精度改造**：所有涉及支付、退款、分账的金额计算，强制使用 `bcmul`/`bcadd` 或统一转为整数（分）运算，避免财务对账差异。
### 🛠 后续重构与优化方向
1. **架构分层**：当前 Model 承担了 Controller/Service 的职责。建议引入 `Service` 层处理业务编排（如支付回调流程、退款流程），Model 仅负责 `CRUD` 与基础查询。
2. **异步化改造**：支付成功后的微信模板消息、短信通知、VIP 积分回调等耗时操作，应通过消息队列（如 Redis Queue / RabbitMQ）异步执行，确保支付回调接口在 `2s` 内返回，避免被支付平台判定超时并重复回调。
3. **常量与配置管理**：将散落的魔法数字、短信模板ID、微信配置等抽离至配置文件或常量类，提升可维护性。
4. **代码截断说明**：您提供的代码在 `if ($this->tuangou->consume_check_time == '1') {` 处被截断。若该分支涉及团购券核销或退款逻辑，请补充完整代码以便进行针对性审查。
> 💡 **框架适配提示**：代码结构高度符合 **CodeIgniter 3** 规范。若 `phpci` 为内部定制框架，请确认其事务管理器（`trans_start/complete`）与 CI3 行为是否一致。若存在差异，请以官方文档的事务生命周期为准。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779271799
|
1779271799
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
268
|
21
|
57
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `bbb443cea ## 自动代码审查报告
**分支**: pay-260519
**提交**: `bbb443cead2db3ca65e1002c021bb1dd8de0475a`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-21 13:21:15
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了多业务场景下的营收明细记录功能，业务分支覆盖较全，但存在严重的架构反模式（如模型中使用 `exit()`、全局实例化、数据库连接切换缺乏异常保护）。性能层面存在明显的 N+1 查询与循环内频繁切换连接的问题。代码规范与类型安全性有待提升。
- **风险等级**：🔴 高（存在流程中断、连接状态污染及潜在的性能雪崩风险）
> 📌 **框架说明**：根据目录结构 (`system/`, `application/`) 及 `get_instance()` 用法，推断该项目基于 **CodeIgniter 3** 架构（或深度定制版）。以下审查基于 CI3 最佳实践与通用 PHP 规范。若 `phpci` 为内部定制框架，请结合其官方生命周期文档调整。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `update_room_info` 方法内 | 模型中使用 `exit()` 终止脚本执行。在 Web 请求或异步任务中会直接中断响应流，破坏 MVC 分层原则，且无法被上层捕获处理。 | 移除 `exit()`，改为抛出异常或返回结构化错误数组。由 Controller/Service 层统一处理错误响应。 | `if ($merchant_id <= 0) { throw new \InvalidArgumentException('商家ID无效'); }` |
| 🔴 严重 | `_add_log` / `update_room_info` 中的 `enforce_con_db()` | 数据库连接切换 (`enforce_con_db()`) 与恢复 (`enforce_con_db(2)`) 之间无异常保护。若中间发生 SQL 错误或 PHP 异常，连接将停留在错误状态，污染后续请求。 | 使用 `try...finally` 确保无论成功或失败，连接状态必定恢复。 | `try { $this->enforce_con_db(); $this->insert($insert); } finally { $this->enforce_con_db(2); }` |
| 🔴 严重 | 文件顶部 (第2行) | `$CI = &get_instance();` 在类外部全局执行。每次 `require/include` 该文件都会实例化一次，浪费资源且可能引发不可预知的状态覆盖。 | 删除文件顶部代码。在类方法内部使用 `$this->load` 或 `$CI =& get_instance()`（仅限 CI3 兼容场景），推荐优先使用 `$this`。 | 直接删除顶部两行，改用 `$this->load->model()` 或构造函数加载。 |
| 🟠 警告 | `_add_log` / `add_by_order` 等 | `in_array()` 与数组键比对未开启严格模式。PHP 弱类型特性可能导致 `'1' == 1` 误判，引发业务逻辑错乱。 | 所有 `in_array()` 添加第三个参数 `true`；常量数组键建议统一使用整型或字符串，比对时保持类型一致。 | `in_array($insert['_pay_platform'], $this->revenues_pay_platform_arr, true)` |
| 🟠 警告 | `update_room_info` 循环体 | `foreach` 内部频繁调用 `enforce_con_db()`、`load->model()` 及 `update()`。单次处理 100 条数据将产生数百次 DB 切换与模型加载，极易导致超时或连接池耗尽。 | 将 DB 切换移至循环外；模型加载移至构造函数或按需缓存；批量更新替代逐条更新。 | 见下方重构建议 |
| 🟠 警告 | 多处 `$this->load->model()` | 同一模型在多个方法中重复加载。CI 框架虽会缓存，但重复调用仍增加解析开销，且不利于依赖管理。 | 在 `__construct()` 中统一加载，或使用懒加载+静态缓存机制。 | `public function __construct() { parent::__construct(); $this->load->model('ahead_yc_merchant_model'); ... }` |
| 🟡 建议 | 全局类与方法命名 | 类名 `Jh_community_shop_revenues_detail_model` 与方法名不符合 PSR-12 规范（应为大驼峰 `JhCommunityShopRevenuesDetailModel`，方法小驼峰）。 | 遵循 PSR-12 命名规范。若受历史包袱限制，至少保证新增方法使用驼峰命名，并添加 `@deprecated` 标记旧方法。 | `class JhCommunityShopRevenuesDetailModel extends Report_model` |
| 🟡 建议 | `get_record_order_data` 末尾 | `$room_info` 变量在 `if (!empty($order_data))` 块内定义，若条件不满足则未初始化。虽使用 `?? []` 兜底，但会触发 PHP Notice。 | 方法开头显式初始化 `$room_info = [];`，提升可读性与静态分析兼容性。 | `$room_info = []; if (!empty($order_data)) { $room_info = $this->get_room_info_by_order($order_data); } return $room_info;` |
| 🟡 建议 | `del_by_order` / `get_duplicate_order` | 硬编码 `_order_type => 4` 且无注释说明。后续维护者难以理解为何只操作特定类型，易引发误删或漏查。 | 将硬编码值提取为类常量，或作为参数传入，并补充业务注释。 | `const TYPE_SCAN_OPEN_ROOM = 4; // 扫码开房` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **移除模型中的 `exit()`**：立即替换为异常抛出或错误码返回，确保业务流可被上层捕获与降级。
2. **修复数据库连接切换逻辑**：所有涉及 `enforce_con_db()` 的代码必须包裹在 `try...finally` 中，防止异常导致连接状态泄漏。
3. **消除文件级 `get_instance()`**：删除顶部全局调用，改为在类内部按需加载或使用 `$this` 上下文。
### 🛠 后续重构与优化方向
1. **性能批量处理**：
`update_room_info` 方法应改为“批量查询 -> 内存组装 -> 批量更新”模式。示例：
```php
// 优化后伪代码
$this->enforce_con_db();
try {
$data = $this->select($where, '*', '_id asc', 1, 100);
if (empty($data)) return ['status' => 'Finish', 'last_id' => $last_id];
$batchUpdate = [];
foreach ($data as $v) {
$roomInfo = $this->get_record_order_data($v);
if ($roomInfo) {
$batchUpdate[] = ['_id' => $v['_id'], 'data' => $roomInfo];
}
$last_id = $v['_id'];
}
// 假设框架支持批量更新，否则可分批执行
$this->update_batch($batchUpdate);
} finally {
$this->enforce_con_db(2);
}
return ['status' => 'Continue', 'last_id' => $last_id];
```
2. **类型安全与常量管理**：
- 将 `ORDER_TYPE` 的键改为整型 `1 => '在线预订'`，并在所有比对处使用严格类型 `===` 或 `in_array(..., true)`。
- 支付方式数组 `$revenues_pay_platform_arr` 建议转为整型数组或使用 `array_flip()` 提升 `isset()` 查询性能。
3. **依赖注入/模型预加载**：
将频繁加载的模型（如 `ahead_yc_merchant_model`, `ahead_family_servers_model` 等）移至构造函数中初始化，减少运行时 I/O 开销。
4. **框架适配确认**：
若 `phpci` 为 CI4 或自研框架，请确认 `enforce_con_db()` 是否为官方推荐的多库切换方式。CI4 推荐使用 `$this->db->setDatabase()` 或配置多连接组，避免手动切换底层连接。
> 💡 **提示**：建议在合并前补充单元测试覆盖 `_add_log` 的边界条件（如金额≤0、表不存在、退款单号拼接等），并使用静态分析工具（如 PHPStan/Psalm）检查类型一致性。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779340875
|
1779340875
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
274
|
21
|
59
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `5d31b5604 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `5d31b56044a16cb5b46fa6ec83c79701df0309ec`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-21 15:47:23
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：代码整体实现了预订、支付、退款及营收流水的核心业务逻辑，具备一定的事务意识与异常捕获机制。但存在**资金状态与第三方API调用顺序倒置**的严重逻辑缺陷，模型中频繁动态加载组件导致性能损耗，且大量硬编码魔法数字与不规范的日志/中断处理降低了可维护性。部分核心方法过长，违反单一职责原则。
- **风险等级**：🔴 高（涉及资金流转状态不一致、潜在数据脏写、模型层强制中断流程）
> 📌 **框架说明**：基于提供的目录结构（`system/`、`application/`）及 `$CI->load->model()` 语法，推测该项目基于 **CodeIgniter 3.x** 架构或深度定制版（`phpci`）。以下审查建议基于 CI3 最佳实践与通用 PHP 规范，若为自研框架请对照官方文档调整。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_book_order_change_pay_log_model.php` / `refund()` | **状态提前更新导致资金不一致**：在调用微信/银联退款 API 前，已执行 `$this->update(['_status' => 4], ...)`。若第三方 API 返回失败或网络超时，数据库状态已变更为“退款完成”，但资金未退回，造成严重账务差异。 | 将状态更新移至 API 调用成功之后；或使用数据库事务包裹状态更新，API 失败时回滚。 | `// 1. 调用 API<br>$res = WxPayApi::refund($input);<br>if ($res['result_code'] !== 'SUCCESS') { return ['status'=>false, 'msg'=>...]; }<br>// 2. API 成功后再更新状态<br>$this->update(['_status' => 4], ['_id' => $data['_id']]);` |
| 🔴 严重 | `Ahead_book_order_model.php` / `refund_by_notify()` | **退款后置操作缺乏事务保护**：支付网关退款成功后，执行了 `ahead_book_order_refund_model`、`ahead_pay_log_model`、`jh_community_shop_revenues_detail_model` 等多表更新。若中途报错或超时，将产生部分成功、部分失败的脏数据。 | 使用 CI3 事务机制包裹 API 成功后的所有数据库写操作。 | `$this->db->trans_start();<br>// ... 执行所有 update/insert ...<br>$this->db->trans_complete();<br>if ($this->db->trans_status() === FALSE) { $this->db->trans_rollback(); return ['status'=>false, 'msg'=>'数据更新异常']; }` |
| 🟠 警告 | 全局多处 | **浮点数直接参与金额计算**：`$data['_actual_pay'] * 100` 在 PHP 中可能因 IEEE 754 精度问题产生 `100.00000000000001` 或 `99.99999999999999`，导致支付/退款金额差 1 分。 | 金额计算统一转为“分”整数处理，或使用 `bcmul()` / `round()` 确保精度。 | `$total_fee = (int)round($data['_actual_pay'] * 100, 0);` |
| 🟠 警告 | `Jh_community_shop_revenues_detail_model.php` / `update_room_info()` 等 | **模型层使用 `exit()` 中断流程**：直接调用 `exit()` 会破坏框架生命周期，导致无法捕获异常、无法返回标准 JSON 响应，且极难进行单元测试。 | 改为抛出异常或返回状态数组，交由控制器统一处理错误响应。 | `if (!$this->check_table_exist(false)) { throw new RuntimeException('商家分表不存在'); }` |
| 🟠 警告 | 多个 Model 文件 | **方法内频繁动态加载模型**：如 `$this->load->model('ahead_yc_shop_model')` 散落在业务方法中，每次调用都会触发文件包含与实例化，增加 I/O 与内存开销。 | 将依赖模型统一移至 `__construct()` 中加载，或配置 CI 自动加载。 | `public function __construct() { parent::__construct(); $this->load->model(['ahead_yc_shop_model', 'ahead_chinaums_set_model']); }` |
| 🟡 建议 | `Ahead_book_order_model.php` / `refund_by_notify()` | **潜在 SQL 注入风险**：`$log_up = '_status=4,_refund_amount=_actual_pay'; $this->ahead_pay_log_model->up($log_up, $log_where);` 若 `up()` 为自定义方法且直接拼接 SQL，未使用 Query Builder 或参数绑定，存在注入隐患。 | 优先使用 CI 的 `$this->db->set()` 与 `$this->db->update()`，或确保自定义 `up()` 内部严格转义。 | `$this->db->set('_status', 4);<br>$this->db->set('_refund_amount', '_actual_pay', FALSE);<br>$this->db->where($log_where);<br>$this->db->update('table_name');` |
| 🟡 建议 | 全局 | **魔法数字泛滥**：`1, 3, 4, 8, 14` 等状态码、平台码硬编码在逻辑中，可读性差且后期维护极易出错。 | 提取为类常量或独立配置文件。 | `const PAY_PLATFORM_WX = 1; const PAY_PLATFORM_VIP = 3; const STATUS_REFUNDED = 4;` |
| 🟡 建议 | 全局 | **日志函数命名不一致 & 敏感信息泄露**：混用 `doLog` 与 `do_log`；且 `doLog(var_export($res, true), ...)` 可能将包含 `sign`、`access_token` 的完整 API 响应写入日志。 | 统一日志函数名；记录前过滤敏感字段。 | `do_log($this->filter_sensitive_data($res), 'wx_refund');` |
| 🟡 建议 | `Ahead_book_order_model.php` (末尾) | **代码片段截断**：`if ($this->tuangou->con` 未闭合，无法评估完整逻辑与潜在缺陷。 | 请补充完整代码以便进行闭环审查。 | N/A |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复退款状态时序问题**：立即调整 `Ahead_book_order_change_pay_log_model::refund()` 的执行顺序，确保**第三方退款 API 成功返回后再更新本地数据库状态**。这是当前最高优先级的资金安全漏洞。
2. **补全事务边界**：在 `Ahead_book_order_model::refund_by_notify()` 中，将支付网关调用后的所有关联表更新（退款日志、流水记录、营收明细、团购核销撤销等）包裹在 `$this->db->trans_start()` 与 `$this->db->trans_complete()` 中，失败时自动回滚。
3. **移除模型层 `exit()`**：将 `Jh_community_shop_revenues_detail_model` 中的 `exit()` 替换为异常抛出或状态返回，确保 Web 请求能正常返回 HTTP 响应码与业务提示。
### 🛠 后续重构与优化方向
- **架构解耦与单一职责**：当前 `refund()`、`refund_by_notify()`、`send_success_msg()` 等方法均超过 150 行，嵌套过深。建议按业务域拆分：
- 将支付网关调用封装为独立的 `PaymentGatewayService`。
- 将消息推送（微信模板、短信）抽离为 `NotificationService`。
- Model 层仅保留数据读写与基础校验，复杂编排逻辑下沉至 Service 层。
- **金额计算规范化**：全局统一金额存储与计算单位（建议底层统一使用“分”整数，展示层再格式化）。废弃 `float` 直接运算，引入 `bcmath` 扩展或封装 `Money` 值对象。
- **依赖注入与自动加载**：利用 CI3 的 `config/autoload.php` 或模型构造函数预加载高频依赖模型，消除运行时动态加载的性能损耗。
- **常量与配置集中化**：建立 `config/payment.php` 与 `config/order_status.php`，将平台标识、状态码、超时阈值等魔法数字集中管理，提升代码可读性与多环境适配能力。
- **日志安全规范**：制定日志脱敏规范，禁止直接 `var_export` 第三方 API 全量响应。关键资金操作日志需包含 `trace_id`、操作人、前后状态快照，便于审计与对账。
> 💡 **提示**：若 `phpci` 为内部定制框架，请重点核对框架对数据库事务的自动提交机制、自定义 `up()` 方法的底层实现是否支持预处理语句，以及全局异常处理器是否已覆盖模型层抛出的异常。建议补充完整代码后，可进一步进行静态扫描（如 PHPStan / Psalm）与支付沙箱联调验证。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779349643
|
1779349643
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
276
|
21
|
60
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `e5c5ca71d ## 自动代码审查报告
**分支**: pay-260519
**提交**: `e5c5ca71d6b9fc7e2037ae7b3165e84bab8d83c1`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-21 15:49:02
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该模型承载了预订、支付回调、退款、消息推送等核心交易链路，业务逻辑较为完整。但存在**严重的事务管理缺陷、SQL注入隐患、支付回调同步阻塞**等高风险问题。代码结构冗长，违反单一职责原则，且存在多处框架使用反模式与性能瓶颈。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `refund_by_notify` ~L230 | **SQL注入风险**：`$log_where = '_relation_id="' . $order_data['_id'] . '" ...'` 直接拼接变量到SQL条件中，未做转义或参数绑定。若 `_id` 被恶意构造，将导致注入。 | 废弃字符串拼接，全面改用 CI 查询构造器（Query Builder）或 `$this->db->escape()`。 | `$this->db->where('_relation_id', $order_data['_id'])<br>->where('_status', 1)<br>->where_in('_type', [5, 13])<br>->update('pay_log_table', $update_data);` |
| 🔴 严重 | `check_notify` ~L60-115 | **事务管理混乱**：混用 `trans_start()`、手动 `trans_rollback()` 与 `trans_complete()`。`trans_complete()` 被放在 `else` 分支中，若前置逻辑失败直接 `return`，事务未正确关闭，极易导致数据库连接泄漏或死锁。 | 统一使用 `trans_begin()` / `trans_commit()` / `trans_rollback()` 显式控制，或依赖 CI 的 `trans_start()` / `trans_complete()` 自动回滚机制，移除手动回滚。 | `$this->db->trans_begin();<br>try { /* 业务逻辑 */ $this->db->trans_commit(); }<br>catch (\Exception $e) { $this->db->trans_rollback(); /* 记录日志 */ }` |
| 🟠 警告 | `check_notify` ~L100-120 | **支付回调同步阻塞**：在支付成功回调中同步执行微信模板消息、短信发送、外部API调用。极易导致接口响应超时，支付平台会触发重试机制，引发重复扣款或状态覆盖。 | 将非核心链路（消息推送、日志、第三方同步）剥离，通过消息队列（Redis/RabbitMQ）或异步任务执行。回调仅更新核心状态并立即返回 `SUCCESS`。 | `// 回调末尾<br>Queue::push(new SendOrderSuccessJob($order_data));<br>return ['status' => true, 'msg' => 'success'];` |
| 🟠 警告 | `get_list` ~L280-295 | **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->get_many(['_id' => $ids]);<br>$map = array_column($merchants, '_business_model', '_id');` |
| 🟠 警告 | 文件顶部 L1-3 | **框架反模式**：在类外部直接调用 `$CI = &get_instance();` 并加载模型。该代码会在每次文件被 `include` 时执行，破坏框架生命周期与单例模式。 | 移除顶部全局代码，将依赖模型加载移至 `__construct()` 或按需延迟加载。 | `public function __construct() {<br> parent::__construct();<br> $this->load->model('Simple_model');<br>}` |
| 🟡 建议 | `create_book_order` ~L240 | **浮点数精度丢失**：金额计算使用普通浮点运算 `($price * $discount_rate) / 100`。金融场景下浮点数存在精度丢失风险（如 `0.1+0.2=0.30000000000000004`）。 | 财务计算统一使用 `BCMath` 扩展，或统一以“分”为单位进行整数运算，展示时再转换。 | `$actual_pay = bcdiv(bcmul($price, $discount_rate, 2), 100, 2);` |
| 🟡 建议 | 全局多处 | **魔法数字泛滥**：大量硬编码状态码（`-1, 1, 2, 3, 14, 56, 99` 等），可读性差，后期维护极易出错。 | 在类顶部定义语义化常量，统一引用。 | `const STATUS_PENDING = -1; const STATUS_PAID = 1;`<br>`if ($status === self::STATUS_PAID) { ... }` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复 SQL 注入漏洞**：立即替换 `refund_by_notify` 中的字符串拼接 SQL 条件，全面启用查询构造器或参数绑定。
2. **重构事务控制流**：清理 `check_notify` 中的事务逻辑，确保 `begin/commit/rollback` 成对出现，避免连接池耗尽与数据不一致。
3. **解耦支付回调阻塞**：将 `send_success_msg` 及短信、微信推送逻辑移出同步回调链路，改为异步队列处理。这是保障支付系统稳定性的核心。
4. **消除 N+1 查询**：优化 `get_list` 方法，采用批量查询替代循环单查。
### 🛠 后续重构与优化方向
- **拆分巨型方法**：`check_notify`、`refund_by_notify`、`send_success_msg` 均超过 150 行，严重违反单一职责原则（SRP）。建议按业务域拆分为 `PaymentCallbackService`、`RefundService`、`NotificationService` 等独立服务类，Model 仅负责数据持久化。
- **统一金额处理规范**：引入 `Money` 值对象或全局 `bcmath` 封装函数，杜绝浮点数直接参与交易计算。
- **规范框架使用**：当前代码结构高度契合 **CodeIgniter 3** 架构。若 `phpci` 为基于 CI 的定制框架，请严格遵循其生命周期规范（如模型依赖注入、配置项读取 `$this->config->item()` 替代全局常量）。
- **补充单元测试**：针对支付回调、退款金额计算、事务回滚等核心链路编写 PHPUnit 测试用例，覆盖正常流、异常流与边界条件。
> ⚠️ **局限性说明**：您提供的代码片段在 `if ($this->tuangou->verify_token) {` 处被截断，未能包含完整的方法实现与后续逻辑。本次审查仅基于已提供部分进行深度分析。若后续补充完整代码，可进一步评估团购核销、预购单退款等链路的完整性与安全性。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779349743
|
1779349743
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
277
|
21
|
61
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `a1f205967 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `a1f205967928b1d283141eb90b17072f62877ee3`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-21 15:56:15
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：代码具备完整的业务闭环（支付回调、退款、下单、消息推送），但存在明显的架构臃肿问题。核心方法（如 `refund_by_notify`）承担职责过多，混合了支付网关交互、数据库事务、日志记录与第三方通知。部分逻辑存在并发安全隐患与 SQL 拼接风险，且未充分利用现代 PHP 特性与框架最佳实践。
- **风险等级**：🔴 高（存在 SQL 注入隐患、库存超卖风险、事务状态不一致可能）
> 📌 **框架说明**：根据目录结构、`$CI = &get_instance()`、`$this->load->model()` 及 `$this->db->trans_start()` 等特征，判定为 **CodeIgniter 3.x** 架构。若为内部定制框架 `phpci`，请对照官方文档调整组件调用方式。
> ⚠️ **局限性说明**：末尾 `create_community_shop_book_order` 方法代码被截断，本次审查仅基于已提供片段进行静态分析。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `refund_by_notify` ~L145 | **SQL 注入风险**：使用字符串拼接构造 WHERE 条件 `$log_where = '_relation_id="' . $order_data['_id'] . '" ...'`，若传入数据未严格过滤，将导致注入。 | 废弃字符串拼接，统一使用 CI 查询构造器或参数绑定。 | `$this->db->where('_relation_id', $order_data['_id'])<br>->where('_status', 1)<br>->where_in('_type', [5, 13])<br>->update('pay_log', $update_data);` |
| 🔴 严重 | `check_notify` ~L50-80 | **并发超卖风险**：`check_remain_sale_num` 校验库存后直接执行后续扣减，未加行级锁或分布式锁，高并发下极易超卖。 | 引入数据库行级锁 (`SELECT ... FOR UPDATE`) 或 Redis 原子操作保障库存扣减一致性。 | `$this->db->where('_id', $id)->get(..., NULL, NULL, TRUE); // CI3 支持 lock('FOR UPDATE')` |
| 🔴 严重 | 文件顶部 L7-8 | **全局实例化隐患**：`$CI = &get_instance();` 在类外部执行。若文件被提前 `include` 或 CLI 环境加载，将触发致命错误。 | 移除顶部代码。Model 内部应直接使用 `$this->load` 或 `$this->config`。 | 删除顶部两行，内部改用 `$this->load->model()` 或 `$this->config->item()` |
| 🟠 警告 | `check_notify` & `refund_by_notify` | **事务控制不规范**：`try-catch` 中手动 `trans_rollback()` 与 CI 自动回滚机制混用，且 `trans_complete()` 仅在 `else` 分支调用，易导致事务状态残留或重复回滚报错。 | 依赖 CI 的 `trans_start()` / `trans_complete()` 自动机制，移除显式 `trans_rollback()`；失败时直接 `return`，CI 会在脚本结束时自动回滚。 | 移除 `try` 内的 `$this->db->trans_rollback();`，统一在方法末尾调用 `$this->db->trans_complete();` |
| 🟠 警告 | `get_list` ~L200 | **循环查询性能损耗**：虽做了内存缓存 `$merchant_business_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();` |
| 🟠 警告 | 全局多处 | **重复加载模型/配置**：方法内部频繁 `$this->load->model()`，降低可读性且违反依赖注入原则。CI 虽会缓存，但增加解析开销。 | 在 `__construct()` 中集中加载高频模型，或采用 Service 层解耦。 | `public function __construct() { parent::__construct(); $this->load->model(['ahead_merchant_model', 'ahead_vip_model']); }` |
| 🟡 建议 | 全局 | **命名规范与 PSR-12 冲突**：方法名使用 `snake_case`，数组混用 `array()` 与 `[]`，缺少 PHP 7+ 类型声明。 | 遵循 PSR-12，统一使用 `camelCase`，添加类型提示，清理历史注释代码。 | `public function checkNotify(string $orderId, string $transactionId = ''): array` |
| 🟡 建议 | `check_notify` ~L115 | **异常日志泄露敏感信息**：`json_encode($e->getTrace(), 256)` 记录完整堆栈，可能暴露服务器路径、配置或用户隐私。 | 仅记录异常消息、行号及脱敏后的业务主键。 | `doLog('支付失败: ' . $e->getMessage() . ' | Order: ' . $order_id, 'book_order');` |
| 🟡 建议 | `refund_by_notify` | **单一职责违背 (SRP)**：退款逻辑超 200 行，混合支付网关、DB 更新、财务流水、消息推送。维护成本极高。 | 拆分为独立 Service：`RefundService`、`PaymentGatewayService`、`NotificationService`。Model 仅负责数据持久化。 | 将退款核心流程抽离至 `app/services/RefundService.php`，Model 仅暴露 `updateStatus()` 等方法。 |
---
## 3. 总结与行动建议
### 🔑 优先修复项（P0/P1）
1. **修复 SQL 注入漏洞**：立即替换 `refund_by_notify` 中的字符串拼接 WHERE 条件，全面改用 CI Query Builder 或预处理语句。
2. **解决库存超卖问题**：在 `check_notify` 的库存校验环节引入 `SELECT ... FOR UPDATE` 行级锁，或迁移至 Redis `DECR` + Lua 脚本实现原子扣减。
3. **规范事务生命周期**：清理 `try-catch` 中冗余的 `trans_rollback()`，严格遵循 `trans_start() -> 业务逻辑 -> trans_complete()` 模式，避免事务状态污染。
### 🛠 后续重构与优化方向
1. **架构分层解耦**：当前 Model 承担了 Controller 和 Service 的职责。建议引入 Service 层处理复杂业务流（如支付回调、退款、消息推送），Model 仅保留 CRUD 与基础查询。
2. **统一编码规范**：
- 启用 `declare(strict_types=1);`
- 方法名统一转为 `camelCase`（如 `checkNotify`、`refundByNotify`）
- 清理 `//add by nan 18.1.22` 等历史注释及大段注释代码，必要时提交至 Git 历史保留。
3. **性能与可观测性提升**：
- 将循环内的单条查询改为批量 `WHERE IN` 查询。
- 关键业务节点（支付回调、退款发起）增加结构化日志（如 JSON 格式），便于 ELK 等日志系统检索与告警。
- 对 `send_success_msg` 中的微信模板消息与短信发送改为**异步队列**处理，避免阻塞主支付回调流程。
> 💡 **提示**：若 `phpci` 为内部定制框架且与 CI3 行为存在差异（如事务自动回滚机制、查询构造器语法），请以官方文档为准调整上述建议。代码末尾截断部分建议补充完整后再次提交审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779350176
|
1779350176
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
278
|
21
|
62
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `36eddc8c3 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `36eddc8c34290a3af1654792d5b7540e0951706b`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-21 15:57:47
---
## 1. 审查摘要
- **代码质量评分**：4/10 分
- **总体评价**：代码实现了预订变更差价退款的核心流程，但存在严重的架构与业务逻辑缺陷。资金操作缺乏事务保护、状态更新与外部调用顺序颠倒、框架生命周期使用错误，且方法冗长、硬编码严重。需进行结构性重构后方可投入生产环境。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 第 2-3 行 | `$CI = &get_instance();` 与 `$CI->load->model()` 在类外部调用。框架未初始化完成时调用会导致 Fatal Error，且破坏 MVC 生命周期。 | 移除外部代码，将模型加载移至类构造函数 `__construct()` 中，或直接依赖框架自动加载。 | `public function __construct() { parent::__construct(); $this->load->model('ahead_book_order_model'); }` |
| 🔴 严重 | `refund()` 方法 | **先更新状态后调用支付接口**。`_status` 被直接改为 `4`，若后续微信/银联接口失败，方法直接返回 `false`，但数据库状态已变更，导致账务状态不一致且无法自动重试。 | 引入数据库事务。仅在外部接口返回成功后，再执行状态更新；或先更新为“退款中”状态，成功后改为“已退款”，失败则回滚或标记“退款失败”。 | `$this->db->trans_start(); $this->update(...); $api_res = $this->callRefundApi(...); if ($api_res['success']) { $this->db->trans_complete(); } else { $this->db->trans_rollback(); }` |
| 🔴 严重 | `refund()` 方法 | **核心资金操作未使用数据库事务**。退款涉及状态更新、第三方接口调用、社区分账记录写入，任一环节失败都会导致数据不一致。 | 使用 CI 的 `$this->db->trans_start()` / `$this->db->trans_complete()` 包裹整个退款流程，确保原子性。 | 见上条示例 |
| 🟠 警告 | 第 45, 58, 85 行 | 动态加载模型 (`$this->load->model()`) 散落在业务方法中。每次调用都会重复解析、实例化，增加内存与 CPU 开销。 | 将依赖模型统一在 `__construct()` 中加载，或配置 `autoload.php`。 | `public function __construct() { parent::__construct(); $this->load->model(['ahead_yc_shop_model', 'ahead_chinaums_set_model', 'ahead_shop_model']); }` |
| 🟠 警告 | 全文多处 | 大量魔法数字硬编码（如 `1, 3, 4, 8, [5,7,8,9,10]`），业务含义不明，后期维护极易出错。 | 提取为类常量或配置项，使用语义化命名。 | `const PAY_PLATFORM_WX = 1; const PAY_SCENE_HAIZAN_APP = 8; if ($data['_pay_platform'] === self::PAY_PLATFORM_WX) { ... }` |
| 🟠 警告 | 第 53, 71, 102 行 | `doLog(var_export($res, true), ...)` 记录完整 API 响应。可能泄露商户密钥、交易流水号等敏感信息，且 `var_export` 序列化大数组性能较差。 | 仅记录关键字段（状态码、错误信息、流水号），使用 `json_encode` 替代 `var_export`，并对敏感字段脱敏。 | `doLog(json_encode(['code'=>$res['result_code'],'msg'=>$res['err_code_des']]), 'changeBookOrderWxRefund');` |
| 🟡 建议 | `refund()` 方法 | 方法体超 150 行，嵌套层级达 5 层，违反单一职责原则，可读性与可测试性极差。 | 采用**策略模式**或**工厂模式**拆分支付渠道逻辑。将 `WxPay`、`ChinaUMS`、`VIP` 退款逻辑抽离为独立 Service 类。 | `class RefundStrategyFactory { public static function make($platform) { return match($platform) { 1 => new WxRefundService(), 3 => new VipRefundService(), }; } }` |
| 🟡 建议 | `add_data()`, `refund()` | 未对 `$params` / `$data` 进行类型校验与金额边界检查。直接参与计算与入库，存在精度丢失或负数退款风险。 | 增加输入校验，金额统一转为 `int`（分）或使用 `bcmath` 处理，拦截非法值。 | `if (!is_numeric($params['difference_price']) || $params['difference_price'] < 0) { throw new InvalidArgumentException('差价金额非法'); }` |
| 🟡 建议 | 全文 | 数组语法混用 `[]` 与 `array()`，缩进不一致，缺少 PHP 7+ 类型声明，不符合 PSR-12 规范。 | 统一使用短数组语法 `[]`，添加 `declare(strict_types=1);`，补充参数与返回值类型提示。 | `public function add_data(array $params): string|false { ... }` |
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **修复框架生命周期错误**：立即删除文件顶部的 `$CI = &get_instance();`，改为在类构造函数中加载依赖。
2. **引入数据库事务**：所有涉及资金状态变更的操作必须包裹在 `$this->db->trans_start()` 中，确保“状态更新-外部调用-分账记录”的原子性。
3. **修正状态更新时序**：严禁在调用第三方退款接口前将状态置为终态（`_status => 4`）。建议改为：`0(待退款) -> 1(退款中) -> 4(成功) / 5(失败)`。
### 🛠 后续重构与优化方向
1. **架构解耦**：当前 Model 承担了“数据访问 + 业务编排 + 第三方 SDK 调用 + 日志记录”多重职责。建议将支付渠道逻辑下沉至 `application/services/Payment/RefundService.php`，Model 仅保留纯 CRUD 操作。
2. **配置化管理**：将支付平台标识、支付场景、分账规则等硬编码迁移至 `application/config/payment.php`，通过配置项驱动业务分支。
3. **安全与健壮性**：
- 增加金额精度处理（建议全链路使用“分”为单位，避免浮点数计算）。
- 对第三方 API 响应增加超时控制与重试机制（如 Guzzle 或 CI 的 HTTP 库）。
- 日志脱敏，避免生产环境泄露敏感交易凭证。
4. **框架适配说明**：代码特征高度符合 **CodeIgniter 3** 规范。若 `phpci` 为内部定制框架，请确认其是否兼容 CI3 的 `get_instance()` 与 `load->model()` 机制。若为全新架构，建议全面替换为依赖注入（DI）容器管理依赖，以提升可测试性。
> 💡 **提示**：财务类代码的容错率极低。建议在重构完成后，补充单元测试（PHPUnit）覆盖正常退款、接口超时、金额异常、并发重复退款等边界场景，并接入灰度发布与资金对账监控。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779350267
|
1779350267
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
280
|
21
|
63
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `527b37c10 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `527b37c106b743b4e035cf0fe54af5fd99580d7c`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-21 16:51:28
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：代码实现了复杂的门店时段预订逻辑，涵盖了跨天、团购券、最低时长、清扫时间等多维度业务规则。但存在**静态缓存污染、对象状态意外修改、方法职责过重、框架上下文滥用**等典型问题。整体可维护性较低，边界条件与异常处理不够严谨。
- **风险等级**：🟠 中（存在数据串扰与状态污染隐患，高并发或复杂预订场景下易引发逻辑错乱）
> 📌 **注**：代码结构高度符合 `CodeIgniter 3` 规范（如 `get_instance()`、`$this->load->model()`）。若 `phpci` 为内部定制框架，请结合其官方文档调整生命周期与依赖管理。此外，**提交代码在末尾被截断**，以下审查基于已提供部分，未覆盖完整逻辑。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_days_info` 方法 | **静态缓存未区分参数**：`self::$book_days_info` 作为全局静态变量，首次赋值后直接返回，忽略后续传入的 `$merchant_id`、`$shop_id`、`$check_date` 等参数，导致多商户/多日期数据严重串扰。 | 移除静态缓存，或改用基于参数哈希的实例级缓存/Redis缓存。 | `// 错误：直接返回静态变量<br>if (!empty(self::$book_days_info)) return self::$book_days_info;<br><br>// 正确：使用参数键值缓存<br>$cache_key = md5(implode('_', func_get_args()));<br>if (isset($this->cache['book_days'][$cache_key])) return $this->cache['book_days'][$cache_key];` |
| 🔴 严重 | `get_book_days_info` 方法 | **意外修改实例状态**：`$this->book_days += 1;` 直接修改了类属性。若该方法被多次调用（如 `$add_day` 交替为 true/false），将导致后续所有计算基准错误。 | 使用局部变量进行计算，严禁在查询方法中修改类属性。 | `$calc_days = $add_day ? $this->book_days + 1 : $this->book_days;<br>for ($i = 0; $i < $calc_days; $i++) { ... }` |
| 🟠 警告 | `get_book_day_time_info` 方法 | **方法过长且职责混杂**：该方法超 300 行，混合了数据查询、时间切片、团购券校验、营业规则过滤、状态标记等逻辑，违反单一职责原则（SRP），极难测试与维护。 | 拆分为独立私有方法：`_fetch_booking_data()`、`_calculate_time_slots()`、`_apply_voucher_rules()`、`_filter_unavailable_times()`。 | 见下方重构建议 |
| 🟠 警告 | 多处（`set_shop_config`、`set_room_info` 等） | **滥用 `get_instance()` 且越权修改控制器上下文**：模型中频繁调用 `get_instance()`，且直接修改 `$CI->operational_scene`、`$CI->package_not_available_time` 等全局变量，破坏 MVC 分层，易引发请求间状态污染。 | 模型应仅负责数据与业务计算，上下文数据通过参数传入或返回值传出。移除冗余 `get_instance()`。 | `// 错误<br>$CI = &get_instance();<br>$CI->operational_scene = $room_operational_scene;<br><br>// 正确<br>return $room_operational_scene; // 由控制器接收并赋值` |
| 🟠 警告 | `get_book_day_time_info` 循环内 | **数组分块逻辑存在越界风险**：`array_chunk($v['time_range_arr'], $time_range_arr_count / 2)` 依赖偶数长度假设。若数组长度为奇数，后半段切片可能缺失或错位，导致后续 `array_intersect` 判断失效。 | 使用 `ceil()` 明确分界，或改用索引范围截取。 | `$mid = (int)ceil($count / 2);<br>$first_half = array_slice($arr, 0, $mid);<br>$last_half = array_slice($arr, $mid);` |
| 🟡 建议 | `_get_un_book_time` 及多处 | **`json_decode` 未做安全校验**：直接对数据库字段 `_time_info_new` 解码，若数据损坏或非 JSON 格式，将返回 `null`，后续 `foreach` 或数组访问会触发 `Warning`。 | 增加类型校验与默认值回退。 | `$raw = $row['_time_info_new'] ?? '[]';<br>$decoded = json_decode($raw, true);<br>$book_time_info = is_array($decoded) ? $decoded : [];` |
| 🟡 建议 | 类属性定义区 | **魔法数字/字符串泛滥**：大量硬编码如 `86400`、`3600`、`'1'`、`'-1'`、`'7'`，降低可读性且易引发维护错误。 | 提取为类常量或配置文件。 | `const SECONDS_PER_DAY = 86400;<br>const STATUS_AVAILABLE = '1';<br>const STATUS_UNAVAILABLE = '-1';` |
| 🟡 建议 | 构造函数 `__construct` | **依赖隐式加载且无异常处理**：`$this->load->library('Tuangou');` 未校验加载结果，若库不存在或 Redis 连接失败，后续 `$this->tuangou->...` 将触发致命错误。 | 增加加载校验与降级策略，或改用依赖注入。 | `if (!$this->load->is_loaded('tuangou')) {<br> $this->load->library('Tuangou');<br>}<br>if (method_exists($this->tuangou, 'get_voucher_info_from_redis')) {<br> $this->tuangou->get_voucher_info_from_redis();<br>}` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复静态缓存串扰**：立即移除 `self::$book_days_info`、`self::$shop_data` 等静态缓存，或改为基于 `merchant_id + shop_id + date` 的实例级缓存数组。
2. **禁止方法内修改实例属性**：将 `$this->book_days += 1` 改为局部变量计算，确保对象状态纯净。
3. **清理控制器上下文污染**：移除模型中对 `$CI->xxx` 的赋值操作，改为通过方法参数传递或返回值暴露数据。
### 🛠 后续重构与优化方向
1. **方法拆分与职责收敛**：
- 将 `get_book_day_time_info` 拆分为：
- `prepareContext($params)`：加载门店配置、营业时间、团购券信息。
- `fetchBookingData($date)`：查询当日/前后日包厢占用数据。
- `generateTimeSlots($business_from, $business_end)`：生成基础时间片。
- `applyFilters($slots, $rules)`：依次应用最低时长、清扫时间、团购券、停用规则等过滤逻辑。
2. **引入现代 PHP 特性**：
- 添加类型声明（`declare(strict_types=1);`、参数类型、返回类型）。
- 使用 `DateTimeImmutable` 替代 `strtotime` + 字符串拼接，彻底规避时区与跨天计算隐患。
3. **性能优化**：
- 将重复的 `get_shop_setting` 调用合并为批量查询或引入配置缓存层。
- 对 `array_intersect`、`array_merge` 操作的大数组进行预过滤，避免在循环中重复计算。
4. **安全与健壮性**：
- 对 `$params` 输入进行严格类型校验（如 `filter_var`、`ctype_digit`）。
- 为 `json_decode`、`array_chunk`、`strtotime` 等易错函数添加防御性编程。
> 💡 **提示**：由于代码在 `_get_un_book_time` 方法末尾被截断，建议补充完整文件后再次进行边界条件与跨天逻辑的专项审查。若需针对特定业务规则（如团购券跨天校验、最低时长计算）进行深度推演，可提供对应测试用例以便精准验证。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779353488
|
1779353488
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
281
|
21
|
64
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `003261ac5 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `003261ac5a9231513a631299b1032fd0dcd3e8db`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-21 17:07:55
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该模型承载了极其复杂的时段计算、团购券规则校验与多门店配置逻辑。整体业务意图清晰，但存在**静态缓存导致的数据串扰风险**、**方法严重超长**、**缺乏输入校验与类型约束**等问题。代码风格偏向传统 CI3 模式，现代 PHP 特性应用不足，可维护性与运行性能均有较大优化空间。
- **风险等级**：🔴 高（逻辑缺陷与潜在性能瓶颈可能引发线上客诉或超时）
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_days_info` (约第150行) | **静态缓存未区分参数**：`self::$book_days_info` 直接返回缓存，完全忽略传入的 `$merchant_id`、`$shop_id`、`$check_date` 等参数。在多商户/多门店并发请求下会导致严重的数据串扰。 | 移除静态缓存，或改用参数组合键缓存（如 `md5(implode('_', func_get_args()))`）。建议优先改为实例属性或依赖外部缓存服务（Redis）。 | `private static $cache = [];<br>$key = md5($merchant_id . '_' . $shop_id . '_' . $check_date . '_' . (int)$add_day);<br>if (isset(self::$cache[$key])) return self::$cache[$key];` |
| 🔴 严重 | 文件末尾 | **代码截断**：文件在 `_get_un_book_time` 方法中突然中断，缺少闭合括号、`return` 语句及后续逻辑。直接部署将引发 `ParseError` 致命错误。 | 补全完整代码。若为提交遗漏，请提供完整文件以便进行闭环审查。 | N/A |
| 🟠 警告 | `get_book_day_time_info` (约第200-450行) | **方法过长且嵌套过深**：单方法超 300 行，包含大量 `foreach`、`array_intersect`、`array_unique` 及条件分支。时间复杂度呈指数级增长，极易触发 PHP 最大执行时间限制。 | 严格遵循单一职责原则，拆分为：`calculateTimeSlots()`、`applyCouponRestrictions()`、`checkBusinessHours()`、`mergeUnavailableRanges()` 等独立方法。 | 见下方重构示例 |
| 🟠 警告 | 全局 `$params` 使用 | **缺乏输入校验**：直接信任 `$params['date']`、`$params['merchant_id']` 等外部输入。若底层 `Simple_model` 未强制使用预处理语句，存在 SQL 注入或越权查询风险。 | 在方法入口处进行严格类型转换与白名单校验，或使用框架内置验证器。 | `$merchant_id = filter_var($params['merchant_id'] ?? 0, FILTER_VALIDATE_INT);<br>if (!$merchant_id) throwError('商户ID无效');` |
| 🟠 警告 | `set_shop_config` & `set_room_info` | **逻辑重复 (DRY 违反)**：两个方法包含完全相同的场景前缀判断、配置加载逻辑。 | 提取公共逻辑至私有方法 `loadSceneConfig($scene)`，统一复用。 | `private function loadSceneConfig($scene, $merchant_id, $shop_id) { ... }` |
| 🟡 建议 | 全局 | **魔法数字与硬编码泛滥**：`'1'`、`'-1'`、`86400`、`3600` 等散落各处，且大量使用松散比较 `==`。 | 定义类常量或枚举，统一使用严格比较 `===`，提升可读性与静态分析能力。 | `const STATUS_AVAILABLE = '1';<br>const SECONDS_PER_DAY = 86400;<br>if ($status === self::STATUS_AVAILABLE)` |
| 🟡 建议 | 全局 | **缺失现代 PHP 类型声明**：未使用属性类型、参数类型及返回类型声明，降低代码健壮性。 | 升级至 PHP 8.1+ 规范，补充类型提示。 | `public function get_book_days_info(int $merchant_id, int $shop_id, string $check_date = '', bool $add_day = false): array` |
| 🟡 建议 | 构造函数/全局 | **冗余获取 CI 实例**：频繁调用 `$CI = &get_instance()`。在 CI/PHPCI 架构中，模型已继承基类，可直接通过 `$this->load` 访问组件。 | 移除冗余的 `&get_instance()`，统一使用 `$this->load` 或在构造函数中注入依赖。 | `// 删除 $CI = &get_instance();<br>$this->load->model('ahead_shop_config_second_model');` |
> 📌 **框架适配说明**：代码结构高度契合 `CodeIgniter 3` 规范。若 `phpci` 为内部定制框架，请以官方文档为准。上述建议基于通用 PHP/CI 最佳实践，若框架对静态属性生命周期或模型加载有特殊机制，请相应调整。
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复静态缓存串扰**：立即移除 `self::$book_days_info` 等静态缓存，或改为带参数键的缓存策略。这是当前最高优先级的逻辑缺陷。
2. **补全截断代码**：确认 `_get_un_book_time` 及后续方法是否完整提交，避免线上 `ParseError`。
3. **增加输入校验层**：在 `get_book_day_time_info` 入口对 `$params` 进行严格过滤，防止非法参数穿透至数据库查询层。
### 🛠 后续重构与优化方向
1. **巨型方法拆分**：将 `get_book_day_time_info` 拆分为职责单一的子方法。示例结构：
```php
public function get_book_day_time_info(array $params, bool $add_day = false): array
{
$this->validateParams($params);
$this->initBusinessHours($params['date']);
$unavailableRanges = $this->collectUnavailableRanges($params, $add_day);
$timeSlots = $this->generateTimeSlots($params['date']);
return $this->applyRulesToSlots($timeSlots, $unavailableRanges, $params);
}
```
2. **性能优化策略**：
- 避免在循环中重复调用 `array_intersect`、`array_unique`、`sort`。可先将所有不可用时间段合并为连续区间，再使用二分查找或区间树算法快速过滤可用时段。
- 将 `strtotime`、`date` 等时间转换操作提前计算，避免在 `foreach` 中重复执行。
3. **架构规范升级**：
- 引入 PHP 8 类型声明与严格模式 (`declare(strict_types=1);`)。
- 将魔法数字提取为 `const` 或配置项。
- 若项目支持，考虑将复杂的时段计算逻辑抽离至独立的 `Service` 层，模型仅负责数据持久化，符合 MVC 分层原则。
4. **测试覆盖**：该逻辑涉及大量边界条件（跨天营业、套餐时长不足、停用规则、团购券限制），建议补充 PHPUnit 单元测试，重点覆盖时间区间交集、静态缓存隔离、异常参数拦截等场景。
> ⚠️ **局限性说明**：由于提供的代码在 `_get_un_book_time` 方法处截断，且未包含依赖的 `Simple_model`、自定义 Helper 函数（如 `mergeTimeRanges`、`shiftTimeRange`）及控制器调用上下文，部分性能与逻辑推断基于现有片段。建议提供完整文件及关联依赖以便进行闭环验证。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779354475
|
1779354475
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
282
|
21
|
65
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `69dcf87d4 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `69dcf87d468f81f5e15dc67de42fb8960e997a63`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-21 17:10:45
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了较为复杂的门店预订时间计算、团购券校验与冲突检测逻辑，但存在明显的架构越界与状态管理缺陷。模型类承担了过多业务逻辑（上帝类），静态缓存与实例属性混用导致潜在的数据污染，且存在大量重复代码、魔法值与循环内重复计算。整体可维护性、扩展性与性能表现均有较大优化空间。
- **风险等级**：🔴 高（逻辑状态污染可能导致预订时间计算错误；巨型方法易引发边界条件遗漏与超时）
> 📌 **框架说明**：从目录结构（`system/helpers/`, `system/libraries/`）、`get_instance()`、`$this->load->model()` 等特征判断，当前代码基于 **CodeIgniter 3** 框架。`phpci` 实际为 PHP 持续集成服务器，并非 Web 框架。以下审查将基于 CI3 最佳实践与通用 PHP 规范进行。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_days_info()` 方法头部 | **静态缓存与实例状态冲突**：方法顶部使用 `self::$book_days_info` 作为静态缓存，但内部执行了 `$this->book_days += 1`。若首次调用 `$add_day=true`，会永久修改实例属性并缓存结果；后续调用即使 `$add_day=false` 也会返回被篡改的缓存，导致日期状态计算错误。 | 移除静态缓存，或改为带参数的缓存键（如 `self::$book_days_info[$add_day]`）；**严禁在缓存命中后修改实例状态**。 | `if (isset(self::$book_days_info[$add_day])) { return self::$book_days_info[$add_day]; }`<br>`// 计算逻辑...`<br>`self::$book_days_info[$add_day] = $result;` |
| 🔴 严重 | `get_book_day_time_info()` 全方法 | **圈复杂度过高 & 职责越界**：方法超 300 行，混合了配置加载、时间轴生成、团购券校验、营业时段过滤、状态标记等逻辑。违反单一职责原则，极难编写单元测试，且 `foreach` 内嵌套大量 `if/else` 易遗漏边界条件（如跨天、24小时营业）。 | 拆分为独立服务类：`ShopConfigService`（配置）、`TimeRangeCalculator`（时间计算）、`VoucherRuleValidator`（券规则）。模型仅保留数据查询。 | *(架构级重构，见第3部分建议)* |
| 🟠 警告 | `set_shop_config()` 与 `set_room_info()` | **严重违反 DRY 原则**：两个方法逻辑高度重复（约 80% 代码相同），仅触发时机与参数略有差异。维护成本高，易出现同步遗漏。 | 提取为私有统一方法 `load_scene_config($room_id = 0)`，由原方法按需调用。 | `private function load_scene_config($room_id = 0) { /* 统一逻辑 */ }` |
| 🟠 警告 | `get_book_day_time_info()` 循环体内 | **循环内重复计算与频繁 DB 调用**：`foreach` 中多次调用 `strtotime()`、`date()`；`ahead_shop_config_second_model->get_shop_setting()` 在多处被重复调用。增加 CPU 与 I/O 开销。 | 循环外预计算基准时间戳；配置项应在初始化时批量获取并缓存至数组。 | `$base_ts = strtotime($date);`<br>`foreach ($time_info as &$v) { $v['ts'] = $base_ts + $v['time']; }` |
| 🟠 警告 | 多处 `$CI = &get_instance();` | **修改超全局对象引发并发污染**：直接赋值 `$CI->operational_scene`、`$CI->package_not_available_time` 等。在 CI3 中，`$CI` 是单例，高并发或异步任务下会导致请求间数据串扰。 | 避免修改 CI 超全局对象。应通过方法返回值、独立配置类或 Session 传递上下文数据。 | `return ['scene' => $scene, 'config' => $config];` |
| 🟡 建议 | 全文件 | **魔法值泛滥 & 违反 PSR-12**：大量使用 `'1'`, `'-1'`, `86400`, `3600` 等硬编码；属性全部为 `public` 暴露内部状态；缩进、换行、命名不一致。 | 定义常量类/枚举替代魔法值；属性改为 `protected` 并提供 Getter/Setter；严格遵循 PSR-12。 | `const STATUS_AVAILABLE = '1';`<br>`const SECONDS_PER_DAY = 86400;`<br>`protected $book_time_limit = 3600;` |
| 🟡 建议 | `_get_un_book_time()` | **数组操作性能隐患**：频繁使用 `array_merge` + `array_unique` + `sort`，且 `array_intersect(...array_values($all_room_book_time))` 在数组较大时消耗显著。 | 使用时间轴标记法（布尔数组）或提前过滤无效区间；减少不必要的数组合并。 | `$timeline = array_fill(0, 1440, false);`<br>`// 标记不可用时间段` |
| 🟡 建议 | 框架适配 | **模型承担业务逻辑**：CI3 模型应专注数据持久化。当前代码包含大量规则计算、状态流转与第三方库交互，不符合 MVC 分层规范。 | 将业务逻辑迁移至 `application/services/` 或 `application/libraries/`，模型仅保留 `get_one()`, `get_where()` 等基础查询。 | `// 控制器调用`<br>`$bookingService = new BookingTimeService();`<br>`$result = $bookingService->calculateAvailableTimes($params);` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复静态缓存状态污染**：立即调整 `get_book_days_info()` 的缓存策略，确保 `$add_day` 参数变化时能正确重新计算或隔离缓存，避免线上出现日期状态错乱。
2. **拆分巨型方法**：将 `get_book_day_time_info()` 按职责拆分为 3~4 个独立方法或服务类。建议先提取 `filterByBusinessHours()`, `filterByVoucherRules()`, `calculateConflictTimes()`，降低圈复杂度至 15 以下。
3. **消除超全局对象副作用**：移除所有 `$CI->xxx = ...` 赋值，改为通过方法返回值或配置对象传递数据，保障请求隔离性。
### 🛠 后续重构与优化方向
- **引入服务层架构 (Service Layer)**：当前模型已演变为“业务逻辑容器”。建议新建 `BookingTimeCalculator` 服务类，注入 Model、Config、Voucher 依赖，模型仅作为数据访问层（DAO）。
- **时间计算算法优化**：当前使用大量 `strtotime`、`date` 和数组交集运算。可改用 **时间轴标记法**（将一天划分为 5 分钟粒度数组，标记可用/不可用状态）或 **区间合并算法**，将时间复杂度从 `O(n²)` 降至 `O(n)`。
- **配置与状态管理规范化**：
- 使用 `const` 或 `enum` 替代 `'1'/'-1'` 等魔法状态值。
- 将 `$this->book_time_limit`、`$this->minute_unit` 等配置项改为只读属性，通过构造函数或初始化方法注入，避免运行时随意修改。
- **补充测试与静态检查**：
- 针对跨天营业、24小时营业、团购券不可用星期、最低时长限制等边界条件编写 PHPUnit 单元测试。
- 引入 `PHPStan` 或 `Psalm` 进行静态类型分析，提前捕获空指针、类型不匹配及未定义变量问题。
> 💡 **提示**：若代码片段因截断未包含完整逻辑（如 `throwError()` 定义、`Simple_model` 基类实现），建议补充完整上下文以便进行更精准的依赖与安全审查。当前审查基于已提供代码的静态分析与架构推演，可直接作为重构基线。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779354645
|
1779354645
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
303
|
21
|
79
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `af89b01ea ## 自动代码审查报告
**分支**: pay-260519
**提交**: `af89b01ea1204b4e64bf663fcbdb1024f00aaee5`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-25 14:10:29
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：代码实现了完整的会员充值、支付回调、奖励发放及多端订单联动逻辑，业务覆盖全面。但存在**支付回调同步阻塞、并发幂等性不足、全局变量滥用、方法职责过重**等典型架构隐患。部分逻辑耦合度高，不利于后续维护与横向扩展。
- **风险等级**：🔴 高（支付回调超时重试、并发重复处理可能导致资金对账异常或重复发券）
> 📌 **框架说明**：从目录结构（`system/`、`application/`）、`$CI = &get_instance()` 及 `$this->db->trans_start()` 等特征判断，该代码实际基于 **CodeIgniter 3.x** 架构。以下审查基于 CI3 最佳实践，若为内部定制版 `phpci`，请结合其官方文档微调。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `pay_call_back()` 方法 | **支付回调同步调用外部服务**（短信、微信模板消息、App推送、打印机）。支付网关通常要求 2s 内返回 `SUCCESS`，同步阻塞易导致网关超时重试，引发重复回调或资金对账混乱。 | 将非核心链路（通知、短信、打印、日志）剥离，改为**异步队列**（Redis List / RabbitMQ / 定时任务）或至少使用 `fastcgi_finish_request()` 提前响应网关。 | ```php<br>// 提前响应网关<br>echo xml_encode(['code'=>'SUCCESS','msg'=>'OK']);<br>fastcgi_finish_request();<br>// 后续执行异步任务<br>Queue::push('VipRechargeNotifyJob', $rechargeId);<br>``` |
| 🔴 严重 | `pay_call_back()` 方法 | **状态更新缺乏原子性，存在并发竞态条件**。先 `get_one` 判断状态，再 `update` 状态。高并发下两个回调可能同时通过状态检查，导致重复扣款/发券。 | 使用**条件更新**或**分布式锁**保证幂等性。优先使用数据库原子更新：`UPDATE table SET _status=1 WHERE _id=? AND _status=-1`。 | ```php<br>$this->db->where('_id', $rechargeId)<br> ->where('_status', -1)<br> ->update($this->table_name, ['_status' => 1, '_trade_no' => $transaction_id]);<br>if ($this->db->affected_rows() === 0) {<br> return ['code'=>'SUCCESS','msg'=>'已处理'];<br>}<br>``` |
| 🟠 警告 | 文件顶部 (第4行) | **全局 `$CI = &get_instance();` 在类外实例化**。文件被 `include/require` 时即执行，浪费内存且可能在未初始化环境下抛出致命错误。 | 移除全局实例化。在 Model 构造函数中赋值，或直接在方法内按需调用 `$this->load->`。 | ```php<br>class Ahead_vip_recharge_order_model extends Simple_model {<br> protected $ci;<br> public function __construct() {<br> parent::__construct();<br> $this->ci =& get_instance();<br> }<br>}<br>``` |
| 🟠 警告 | `recharge()` / `pay_call_back()` | **频繁调用 `$this->load->model()`**。每次请求重复加载相同模型，增加 I/O 与内存开销。 | 将高频依赖模型移至 `__construct()` 中加载，或配置 `config/autoload.php` 自动加载。 | ```php<br>public function __construct() {<br> parent::__construct();<br> $this->load->model(['ahead_vip_model', 'ahead_shop_model', 'ahead_user_model']);<br>}<br>``` |
| 🟠 警告 | `recharge()` 方法 | **类型比较不一致**。`$from` 可能为整型，但 `in_array($from, ['2','4'...])` 使用松散比较，且 `$from == '1'` 混用字符串/整型，易引发逻辑误判。 | 统一类型转换或开启严格模式。建议将 `$from` 强转为整型后再比较。 | ```php<br>$from = (int)($params['from'] ?? 1);<br>if (in_array($from, [2,4,5,6,7,8,9,11,12,13], true)) { ... }<br>``` |
| 🟠 警告 | `pay_call_back()` 方法 | **事务回滚逻辑与 CI 自动模式冲突**。`$this->db->trans_start()` 开启手动模式，但 `catch` 中手动 `trans_rollback()` 后直接 `return`，未调用 `trans_complete()`，可能导致后续 DB 操作处于未定义状态。 | 统一使用 CI 事务标准写法：`$this->db->trans_begin(); ... if($err) { $this->db->trans_rollback(); return; } ... $this->db->trans_commit();` 或保持 `trans_start()` 但确保 `trans_complete()` 必执行。 | ```php<br>$this->db->trans_start();<br>try {<br> // 业务逻辑<br> $this->db->trans_complete();<br>} catch (Exception $e) {<br> $this->db->trans_rollback();<br> throw $e;<br>}<br>``` |
| 🟡 建议 | 全局 | **魔法数字与硬编码值泛滥**。如 `256`、`1800`、`1`、`-1`、`22`、`50`、`0.08` 等散落在代码中，可读性差且难以维护。 | 提取为类常量，集中管理业务枚举与配置阈值。 | ```php<br>const REDIS_EXPIRE_SEC = 1800;<br>const JSON_UNESCAPED_UNICODE = 256;<br>const PAY_PLATFORM_FREE = 22;<br>const SMS_MIN_BALANCE = 0.08;<br>``` |
| 🟡 建议 | `recharge()` / `pay_call_back()` | **方法过长（>300行），违反单一职责原则**。支付路由、订单组装、奖励计算、通知发送全部耦合在一个 Model 方法中。 | 按领域拆分：`PaymentGatewayService`（支付适配）、`VipRewardService`（奖励/邀请）、`OrderDispatchService`（订单生成）。Model 仅负责数据持久化。 | 建议后续重构时采用 Service 层架构，Model 保持纯净。 |
| 🟡 建议 | `add_free_order()` | **代码片段不完整**。方法在 `if ($registration_fee > 0) {//需要办卡费用的去生成办卡费用订单` 处截断，无法评估后续逻辑。 | 请补充完整代码以便审查边界条件与事务一致性。 | 无 |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **支付回调幂等性与原子更新**：立即将 `pay_call_back` 中的状态检查与更新合并为一条 `UPDATE ... WHERE _status = -1` 语句，或引入 Redis 分布式锁（`SETNX`），彻底杜绝并发重复处理导致的资金/发券异常。
2. **回调响应解耦**：支付成功回调必须**秒级返回**。将短信、微信模板消息、App推送、打印机调用移至异步队列。若暂无队列中间件，可临时使用 `ignore_user_abort(true)` + `fastcgi_finish_request()` 提前返回网关，后台继续执行。
3. **全局 `$CI` 实例化修复**：移除文件顶部的 `&get_instance()`，改为构造函数注入或按需加载，避免框架初始化阶段的潜在 Fatal Error。
### 🛠 后续重构与优化方向
- **架构分层**：当前 Model 承担了 Controller 与 Service 的职责。建议引入 `Service` 层处理复杂业务编排（如：`VipRechargeService::initiate()`、`VipRechargeService::handleCallback()`），Model 仅保留 `insert`、`update`、`get_one` 等数据访问方法。
- **配置与枚举集中化**：将 `FROM_MAP`、支付平台标识、Redis 库 ID、短信阈值等提取至 `config/vip_recharge.php` 或类常量中，便于多环境部署与后期审计。
- **安全加固**：
- 确保所有 `$this->db->where()` 或基础 Model 的查询方法底层使用 Query Builder 或 PDO 预处理，杜绝 SQL 注入。
- `doLog()` 记录异常时，过滤掉 `$params` 中的敏感字段（如 `openId`、`mobile`、`sms_code`），防止日志泄露。
- 若该接口对外暴露，需补充 CSRF Token 校验（Web端）或签名验签机制（API端）。
- **框架适配提示**：若 `phpci` 为 CI3 的定制版，请确认 `$this->db->trans_start()` 是否启用了 `strict_mode`。建议统一使用 `$this->db->trans_begin()` + `$this->db->trans_commit()` / `$this->db->trans_rollback()` 显式控制，避免隐式状态混乱。
> 💡 **下一步建议**：优先完成回调幂等改造与异步化拆分，可立即降低线上资金风险。后续可安排 1~2 个迭代进行 Service 层重构与常量提取，提升代码可测试性与可维护性。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779689429
|
1779689429
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
307
|
21
|
82
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `d712d39b4 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `d712d39b4237953f9e9cd9a4623af65a0e6a1259`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-25 15:29:04
---
## 1. 审查摘要
- **代码质量评分**：6.0 / 10 分
- **总体评价**：业务逻辑覆盖较全面，能支撑 AI 预订、多业态（KTV/台球/棋牌/酒馆）套餐推荐与支付流程。但代码存在明显的架构反模式：大量使用公开属性存储中间状态、频繁修改全局 `$CI` 对象、静态缓存未隔离导致跨店数据污染、超长方法违反单一职责原则。性能与可维护性存在较大优化空间。
- **风险等级**：🟠 中高（存在数据隔离缺陷、全局状态污染、潜在 N+1 查询瓶颈）
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_merchant_room_type_model.php`<br>L15, L28-40 | **静态缓存未隔离导致跨店数据污染**：`self::$room_type_data` 为扁平数组，首次查询门店A后，后续查询门店B会直接返回门店A的缓存数据。 | 移除静态缓存或改为带唯一键的缓存结构，或交由框架缓存组件管理。 | `if (!isset(self::$room_type_data[$merchant_id . '_' . $shop_id])) { ... }`<br>`return self::$room_type_data[$merchant_id . '_' . $shop_id] ?? [];` |
| 🔴 严重 | `Ahead_ai_book_model.php`<br>`Ahead_billiards_model.php`<br>文件头部 L1-3 | **类外部使用 `$CI = &get_instance();` 违反框架规范**：在模型文件顶部直接获取实例并加载模型，易引发未初始化错误，且破坏 CI 生命周期。 | 删除文件头部代码。依赖加载应移至 `__construct()` 或具体业务方法内。 | `// 删除顶部代码`<br>`public function __construct() { parent::__construct(); $this->load->model('Simple_model'); }` |
| 🟠 警告 | `Ahead_ai_book_model.php`<br>L18-27 | **公开属性滥用存储中间状态**：`$time_eligible_package_data` 等大量公开数组用于累积计算结果，破坏封装性，若实例复用会导致状态残留。 | 改为 `private` 属性，并在方法入口处显式重置，或改为局部变量通过返回值传递。 | `private $time_eligible_package_data = [];`<br>`// 方法开头：$this->time_eligible_package_data = [];` |
| 🟠 警告 | `Ahead_ai_book_model.php`<br>L102, L360<br>`Ahead_billiards_model.php`<br>L52 | **频繁修改 `$CI` 超全局属性**：如 `$CI->operational_scene = $operational_scene;` 污染全局上下文，极易引发并发请求或后续逻辑的隐蔽冲突。 | 避免修改 `$CI`。应通过方法参数传递业务上下文，或使用独立的 `Context` 对象。 | 移除 `$CI->xxx = ...`，改为参数传递或依赖注入。 |
| 🟠 警告 | `Ahead_ai_book_model.php`<br>L250-260 | **循环逐日查询引发性能瓶颈**：`for ($i = 0; $i < 7; $i++)` 每次循环调用 `_get_date_room_list_info`，触发完整模型加载与 DB 查询，存在严重 N+1 问题。 | 改为批量查询未来 7 天数据，或在 SQL 层使用 `BETWEEN` 一次性拉取，内存中过滤。 | `WHERE book_date BETWEEN ? AND ?` 替代循环查询。 |
| 🟠 警告 | `Ahead_ai_book_model.php`<br>L130-160 | **手动括号匹配解析 JSON 脆弱**：依赖 `strpos` 和计数器提取 JSON，若 AI 返回嵌套字符串或格式微调，极易解析失败或越界。 | 使用正则提取或要求 AI 严格输出 JSON 块，配合 `json_decode` 与异常捕获。 | `preg_match('/book_params=\s*(\{.*\})/s', $str, $m);`<br>`$data = json_decode($m[1], true);` |
| 🟡 建议 | 全局多处 | **重复加载模型/库**：每个方法内部频繁调用 `$this->load->model()`，浪费 I/O 与内存。 | 将高频依赖移至构造函数，或配置框架自动加载。 | `public function __construct() { parent::__construct(); $this->load->model(['xxx','yyy']); }` |
| 🟡 建议 | `Ahead_billiards_model.php`<br>L180-200 | **存在大量注释死代码**：如 `/*if ($result['operational_scene'] == '2')...*/` 影响可读性与静态分析。 | 彻底清理注释掉的代码，历史版本交由 Git 管理。 | 直接删除注释块。 |
| 🟡 建议 | 全局 | **违反 PSR-12 与类型规范**：命名不统一（`minToStr` vs `mintoStr`）、使用 `array()`、缺乏类型声明、方法过长（>300行）。 | 统一驼峰/蛇形命名，使用 `[]`，为 PHP 7.4+ 添加类型提示，拆分超长方法。 | `public function get_page_info(int $uid, int $mid, int $sid, array $params): array` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复静态缓存隔离缺陷**：立即修改 `Ahead_merchant_room_type_model::get_shop_room_type_list` 中的 `self::$room_type_data`，按 `merchant_id_shop_id` 键值隔离，否则会导致严重的跨店数据错乱。
2. **清理全局状态污染**：移除所有 `$CI = &get_instance();` 及 `$CI->xxx = ...` 赋值。业务上下文（如 `operational_scene`、`merchant_id`）应通过方法参数或独立的 `RequestContext` 对象传递。
3. **优化 7 天循环查询**：将 `get_ai_book_recommend` 中的 `for ($i=0; $i<7; $i++)` 替换为单次范围查询（如 `WHERE date >= CURDATE() AND date <= DATE_ADD(CURDATE(), INTERVAL 7 DAY)`），在 PHP 层按日期分组处理，预计可降低 60%+ DB 交互耗时。
### 🛠 后续重构与优化方向
- **遵循单一职责原则 (SRP)**：`get_ai_book_recommend` 方法已超 400 行，建议拆分为：
- `resolve_booking_time()`：处理时间解析、模糊时间转换、卡券时间校验。
- `fetch_available_rooms()`：批量获取空闲包厢与套餐。
- `calculate_recommendation_priority()`：封装推荐权重排序逻辑。
- **引入数据校验层**：当前 `$params` 仅使用 `??` 默认值，建议在入口增加严格校验（如 `book_date` 格式、`book_hour` 范围），可使用框架自带的 `Form_validation` 或自定义 DTO 类。
- **统一异常处理**：`throwError()` 若为自定义函数，建议统一替换为 `throw new \DomainException()` 或 `BusinessException`，便于全局捕获与标准化错误码返回。
- **框架适配说明**：代码结构高度符合 **CodeIgniter 3** 规范。若 `phpci` 为内部定制框架，请确认其是否支持依赖注入容器（DIC）或 PSR-11 规范。若支持，建议逐步将 `$this->load->model()` 替换为构造函数注入，以提升可测试性与生命周期可控性。
> 💡 **提示**：`Ahead_billiards_model.php` 末尾代码被截断，若包含支付回调或订单状态机逻辑，请补充完整以便进行事务一致性审查。当前审查基于已提供片段，建议结合完整调用链进行集成测试。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779694144
|
1779694144
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
324
|
21
|
91
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `c9973db30 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `c9973db30df7b2dd76ea9b396f517d5b08229f5c`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-26 14:18:53
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该模型承载了极其复杂的预订时间计算逻辑，业务覆盖全面（含跨天、套餐、清扫、锁定、多业态等）。但代码存在明显的架构设计缺陷：方法严重超长、静态状态管理混乱、框架基础用法冗余、时间格式混用且缺乏统一抽象。整体可维护性较低，在并发或高负载场景下易出现状态污染与性能瓶颈。
- **风险等级**：🟠 中高（逻辑边界隐患、并发状态污染、性能退化风险）
> 📌 **框架说明**：您提及的 `phpci` 通常为 PHP 持续集成工具，而非 Web 框架。从代码结构（`get_instance()`、`$this->load->model()`、目录规范）判断，该代码实际基于 **CodeIgniter 3 (CI3)**。以下审查将严格遵循 CI3 最佳实践与 PHP 现代编码规范。若确为自研框架，请忽略框架特定提示，其余逻辑与规范建议依然适用。
> ⚠️ **局限性说明**：代码在 `$this->next_date_room_book_time = [...]` 处截断，以下审查基于已提供部分。若后续存在关键逻辑差异，请补充完整文件以便二次评估。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 全局/多处 | **框架误用：Model 中冗余调用 `get_instance()`**<br>在 CI3 中，Model 继承自 `CI_Model`，`$this` 本身即为 CI 超级对象。频繁使用 `$CI = &get_instance()` 是反模式，增加内存开销且破坏框架设计初衷。 | 移除所有 `$CI = &get_instance();`，直接使用 `$this->load->model()`、`$this->merchant_id` 等。若需访问 Controller 专属属性，应通过方法参数显式传递。 | `$this->load->model('ahead_shop_model');`<br>`$merchant_id = $this->merchant_id ?? 0;` |
| 🔴 严重 | 全局/静态属性 | **静态属性缓存导致状态污染与并发隐患**<br>`public static $book_days_info = [];` 等静态变量在单次请求内可复用，但若同一请求处理不同商户/门店数据，会返回脏数据。长进程（如 CLI/Worker）下易内存泄漏。 | 改为实例属性，或引入带维度的请求级缓存。若必须静态缓存，需拼接 `merchant_id_shop_id_date` 作为 Key。 | `private static $cache = [];`<br>`$key = "book_days_{$m}_{$s}";`<br>`if (isset(self::$cache[$key])) return self::$cache[$key];` |
| 🟠 警告 | `get_book_day_time_info` 方法 | **方法严重超长且违反单一职责原则 (SRP)**<br>该方法超 250 行，混杂了参数校验、配置加载、时间计算、套餐校验、营业时间判断、锁定状态检查等逻辑，调试与单元测试极其困难。 | 拆分为多个私有方法：`validateParams()`, `loadShopConfig()`, `calculateAvailableSlots()`, `checkPackageRules()`, `checkBusinessHours()` 等。 | `private function validateBookingParams(array $params): void { ... }`<br>`private function filterByPackageRules(array $slots): array { ... }` |
| 🟠 警告 | 时间处理逻辑 | **时间格式混用与边界计算风险**<br>代码中混用 `YmdHi`、`H:i`、Unix 时间戳、秒数(`86400`)。`strtotime()` 强依赖服务器时区，跨天/夏令时/闰秒处理极易出错。 | 引入 `nesbot/carbon` 或封装统一时间工具类。所有计算统一转为时间戳或 `DateTime` 对象，仅在输出时格式化。 | `$start = Carbon::createFromFormat('YmdHi', $date.'0000');`<br>`$end = $start->copy()->addHours(24);`<br>`$diff = $end->diffInSeconds($start);` |
| 🟠 警告 | `_get_un_book_time` 及数组操作 | **数组操作性能瓶颈与潜在崩溃**<br>`array_intersect(...array_values($all_room_book_time))` 使用参数展开，数据量大时易触发 `ArgumentCountError` 或内存溢出。循环内频繁 `array_merge`/`array_unique`。 | 使用迭代方式求交集，或预先过滤。将去重操作移至循环外。避免在循环中重复分配数组。 | `function intersectMulti(array $arrays): array {`<br>` return array_reduce($arrays, fn($carry, $item) => array_intersect($carry, $item), $arrays[0] ?? []);`<br>`}` |
| 🟡 建议 | 全局 | **魔法数字泛滥**<br>`1, 2, 3, 4, 7, 86400, 3600, 1800` 等硬编码散落各处，降低可读性且后期调整需全局搜索。 | 提取为类常量或配置项，集中管理。 | `const SCENE_KTV = 1;`<br>`const SECONDS_PER_DAY = 86400;`<br>`const MINUTE_UNIT_DEFAULT = 30;` |
| 🟡 建议 | 属性定义 | **属性可见性设计不当**<br>大量业务状态属性声明为 `public`，外部可随意修改，破坏封装性且易引发不可预知的副作用。 | 改为 `protected` 或 `private`，提供必要的 `getter` 方法。 | `protected $book_room_id = 0;`<br>`public function getBookRoomId(): int { return $this->book_room_id; }` |
| 🟡 建议 | 输入处理 | **缺乏参数类型校验与防御性编程**<br>`$params['date']` 等直接用于 `strtotime`，未校验格式、范围或类型。`throwError()` 依赖全局函数，不利于异常栈追踪。 | 增加类型检查、格式校验，失败时抛出标准异常或返回明确错误码。 | `if (!preg_match('/^\d{8}$/', $params['date'])) {`<br>` throw new InvalidArgumentException('日期格式必须为 Ymd');`<br>`}` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **清理框架冗余调用**：全局搜索并替换 `$CI = &get_instance();`，统一使用 `$this` 访问 CI 组件，消除不必要的引用开销。
2. **隔离静态缓存状态**：将 `public static` 属性改为带业务维度 Key 的缓存机制，或降级为实例属性，防止多商户/多门店请求交叉污染。
3. **拆分巨型方法**：将 `get_book_day_time_info()` 按职责拆分为 4~6 个子方法，每个方法不超过 50 行，显著提升可读性与可测试性。
4. **统一时间处理规范**：废弃 `YmdHi` 字符串直接参与数学运算的做法，全面转为时间戳或 `DateTime` 对象计算，彻底规避跨天与时区边界 Bug。
### 🛠 后续重构与优化方向
- **引入策略模式处理多业态**：当前 `if/elseif` 判断 `book_room_operational_scene`（KTV/台球/棋牌/酒馆）的逻辑散落在多处。建议抽象为 `BookingStrategyInterface`，按场景注入不同策略类，符合开闭原则。
- **配置与数据缓存层**：`ahead_shop_config_second_model->get_shop_setting()` 被高频调用。建议在 Service 层或 CI Cache 驱动中增加 Redis/Memcached 缓存，设置合理 TTL，降低 DB 压力。
- **标准化错误处理**：逐步替换全局 `throwError()`，改用 `throw new \DomainException()` 或 CI3 的 `show_error()`，并配合日志记录（`log_message()`），便于生产环境排查。
- **补充单元测试**：时间计算与状态机逻辑极易出错。建议使用 `PHPUnit` 针对 `_get_un_book_time()`、套餐时长校验、跨天逻辑编写边界测试用例（如：23:55 预订、跨零点、营业结束前 5 分钟等场景）。
> 💡 **提示**：若需针对截断部分（如次日不可用时间计算、最终结果组装逻辑）进行深度审查，请提供完整文件。当前建议已覆盖核心风险点，按优先级实施可显著提升代码健壮性与团队维护效率。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779776333
|
1779776333
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
333
|
21
|
97
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `783fccb96 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `783fccb96970e1dafb1004f28bca3cf1aad18a60`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-26 15:42:23
---
## 1. 审查摘要
- **代码质量评分**：4.5 / 10 分
- **总体评价**：代码整体呈现典型的“测试/调试控制器”特征，但混杂了大量未经验证的业务逻辑。存在严重的 SQL 注入风险、框架反模式（如污染 CI 超类对象）、硬编码敏感数据及输入校验缺失。模型层部分方法仍使用原始字符串拼接 SQL，未充分利用现代 PHP 类型声明与框架安全机制。
- **风险等级**：🔴 高
> *注：代码结构高度符合 **CodeIgniter 3 (CI3)** 规范。若 `phpci` 为内部定制框架，以下安全与架构原则依然通用。*
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_vip_model.php`<br>`check_is_register` / `pay_order` / `notify_book` | **SQL 注入漏洞**：直接将外部变量拼接到 SQL 字符串中（如 `$orStr .= "(_ahead_user_id='" . $uid . "'";` 及 `$up = "_account=_account-'" . $order_data['_actual_pay'] . "'";`），未使用查询绑定或构造器。若传入恶意字符将导致数据泄露或破坏。 | 严格使用 CI3 查询构造器或参数绑定。金额/ID 字段必须强制类型转换。 | `$this->db->where('_ahead_user_id', (int)$uid);`<br>`$this->db->set('_account', '_account - ' . (float)$pay, FALSE);` |
| 🔴 严重 | `TestHlj.php`<br>`check_params()` 方法 | **属性名拼写错误引发致命异常**：`$family_server_id = $this->param['family_server_id'] ?? '';` 中 `$this->param` 未定义，应为 `$this->params`。在严格模式下将直接抛出 `Undefined property` 错误。 | 统一修正为 `$this->params`，并建议在类顶部声明属性类型。 | `$family_server_id = $this->params['family_server_id'] ?? '';` |
| 🟠 警告 | `TestHlj.php`<br>`__construct()` | **滥用全局实例污染框架核心对象**：`$CI->merchant_id = ...` 动态向 CI 超类注入属性。破坏封装性，易引发并发请求下的状态覆盖、内存泄漏及单元测试困难。 | 使用 Session、配置类或依赖注入传递上下文，避免全局状态污染。 | `$this->session->set_userdata(['merchant_id' => $id]);`<br>或通过方法参数显式传递 |
| 🟠 警告 | `TestHlj.php`<br>`jsonEcho()` | **输出缓冲与响应机制不规范**：手动 `ob_end_clean()`/`ob_start()` 易与 CI 的 Output 类冲突；硬编码 `die()` 终止流程不利于中间件/钩子执行。 | 使用 CI 内置 `$this->output` 类标准化 JSON 响应。 | `$this->output->set_status_header($code)`<br>`->set_content_type('application/json')`<br>`->set_output(json_encode($result, JSON_UNESCAPED_UNICODE))`<br>`->_display();` |
| 🟠 警告 | `TestHlj.php`<br>多处方法 | **硬编码敏感数据与调试输出**：包含明文 Token、固定 UID(`66`)、`var_dump`/`print_r`，且未对 `$_GET`/`$_REQUEST` 做过滤。若部署至生产环境将导致信息泄露与越权。 | 移除所有调试输出；敏感配置移至 `.env` 或 `config`；API 入口统一接入验证层。 | 移除 `var_dump`，使用 `$this->form_validation` 或自定义 Validator 拦截非法请求 |
| 🟡 建议 | `TestHlj.php`<br>`updateShopShiftTurnoverCount` | **使用 JS 跳转实现服务端批处理**：`echo '<script>window.location.href=...` 对 API/CLI 无效，且易被浏览器拦截或破坏 RESTful 规范。 | 改为返回 JSON 状态，由前端轮询或使用 CLI 脚本 + 消息队列执行。 | 返回 `['status' => 'processing', 'next_cursor' => $last_id]` |
| 🟡 建议 | 全局 | **缺乏现代 PHP 类型声明与 PSR-12 规范**：无参数类型、返回值类型；魔法数字多（如 `json_encode($data, 256)`）；注释与业务逻辑混杂。 | 逐步引入 PHP 7+ 类型声明；使用常量替代魔法数字；遵循 PSR-12 缩进与命名规范。 | `public function getCommunityShopList(): void`<br>`const JSON_FLAGS = JSON_UNESCAPED_UNICODE \| JSON_THROW_ON_ERROR;` |
## 3. 总结与行动建议
### 🚨 优先修复（P0）
1. **修复 SQL 注入**：立即重构 `Ahead_vip_model` 中所有直接拼接 SQL 字符串的方法。全面替换为 `$this->db->where()`、`$this->db->set()` 或 `$this->db->query($sql, $bindings)`。
2. **修正致命拼写错误**：将 `TestHlj::check_params()` 中的 `$this->param` 统一改为 `$this->params`，并补充空值防御逻辑。
3. **移除生产环境调试代码**：清理 `TestHlj.php` 中的 `var_dump`、`print_r`、硬编码 Token 及固定测试账号（如 `uid=66`）。测试控制器应通过环境变量或独立路由隔离，严禁随业务代码发布。
### 🛠 后续重构与优化方向
1. **统一响应与输入校验机制**：
- 废弃 `jsonEcho()`，封装统一的 `ApiResponse` 服务类，利用 CI3 的 `$this->output` 输出。
- 在 `__construct()` 或前置钩子中引入参数校验（如 `Form_validation` 或自定义 DTO），拦截非法 `$_GET`/`php://input` 数据。
2. **解耦全局状态**：
- 停止使用 `$CI->xxx` 传递业务上下文。推荐方案：使用 `$this->session->set_userdata()` 存储用户态，或通过构造函数/方法参数显式注入依赖。
3. **架构规范化**：
- 将 `TestHlj` 中的批量更新逻辑（如 `updateShopShiftTurnoverCount`）迁移至 CLI 命令或队列任务（如 Redis Queue / Supervisor），避免 HTTP 超时与 JS 跳转依赖。
- 逐步为 Model/Controller 方法添加 PHP 类型声明（`declare(strict_types=1);`），提升静态分析能力与运行时安全性。
4. **框架适配提示**：
- 若 `phpci` 为 CI3 的二次封装，请确认其是否重写了 `$this->output` 或数据库驱动。若为标准 CI3，上述建议可直接落地。建议查阅官方文档中 `Output Class` 与 `Query Builder` 章节以对齐最佳实践。
> 本次审查基于静态代码分析。建议在修复后配合 `SonarQube` 或 `PHPStan` 进行自动化扫描，并补充核心链路的单元测试（PHPUnit）以覆盖边界条件与并发场景。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779781343
|
1779781343
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
366
|
21
|
110
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `eb0f6c752 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `eb0f6c752ec531d38f10fc74a1315f68591405a9`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-27 16:10:04
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了复杂的业务逻辑（时段预订计算、评价发券、触摸屏设备交互），但存在明显的架构与安全缺陷。模型层承担了过多服务层与控制器职责，存在 SQL 注入隐患、`goto` 滥用、异常静默吞没、异步状态不同步等问题。整体耦合度高，可维护性与扩展性较弱。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `ScreenApi.php` / `case "2001"` | 使用 `goto famail_close;` 破坏控制流，且标签拼写为 `famail`（应为 `family`），极易引发逻辑跳跃与维护灾难。 | 提取关房后置逻辑为独立私有方法，使用条件分支或 `return` 替代 `goto`。 | `if ($family_data['_status'] == 1) { return $this->_handle_auto_close($family_data, $open_room_data); }` |
| 🔴 严重 | `Ahead_shop_comment_model.php` / `checkWriteable()` | `$this->db->where($openLogWhereStr)` 直接拼接外部参数 `$uniqueKey` 与 `$uid`，存在 SQL 注入风险。 | 使用 CI3 查询构造器或参数绑定，避免原生字符串拼接。 | `$this->db->where('_unique_key', $uniqueKey)->where("FIND_IN_SET($uid, _join_customer) > 0");` |
| 🔴 严重 | `ScreenApi.php` / `case "2001"` | `$upOpenLogStr` 直接拼接 `$cost` 到 SQL 更新语句中，违反安全编码规范，且易因类型转换引发语法错误。 | 使用 Query Builder 的 `set()` 方法，并强制类型转换。 | `$this->db->set('_unpaid_amount', '_unpaid_amount + ' . floatval($cost), FALSE)->update('table', $where);` |
| 🔴 严重 | `ScreenApi.php` / 文件头部 | `header("Access-Control-Allow-Origin:*");` 允许任意域名跨域，易被恶意站点利用发起 CSRF 或数据窃取。 | 根据业务需求配置可信域名白名单，或动态读取 `HTTP_ORIGIN` 校验后返回。 | `header("Access-Control-Allow-Origin: " . ($allowed_origin ?: 'https://yourdomain.com'));` |
| 🟠 警告 | `Ahead_shop_book_time_info_model.php` / `get_book_day_time_info()` | `array_intersect(...array_values($all_room_book_time))` 当数组元素不足 2 个时，PHP 8+ 会抛出 `ArgumentCountError` 致命错误。 | 增加数量校验，或使用兼容写法。 | `if (count($all_room_book_time) > 1) { $un_book_time = array_intersect(...array_values($all_room_book_time)); }` |
| 🟠 警告 | `Ahead_shop_comment_model.php` / `add_shop_comment()` | `catch (Exception $e)` 仅返回“评价失败”，未记录异常堆栈，导致线上故障无法定位。 | 捕获后写入日志，并返回脱敏提示。 | `log_message('error', '评价提交异常: ' . $e->getMessage()); return ['success'=>false, 'msg'=>'系统繁忙，请稍后重试'];` |
| 🟠 警告 | `service-receipt.js` / `addService()` | 图片上传为异步操作，但提交时直接读取 `this.data.imageList`，未等待上传完成，可能导致提交空数组或部分失败数据。 | 使用 `Promise.all` 聚合上传任务，全部成功后再调用提交接口。 | `Promise.all(uploadTasks).then(urls => this.submitComment(urls)).catch(err => wx.showToast({title:'上传失败'}))` |
| 🟠 警告 | `Ahead_shop_book_time_info_model.php` / 多处 | 频繁在方法内部调用 `$CI = &get_instance()`，且部分逻辑重复加载 Model。 | 在构造函数中统一获取并赋值给实例属性，后续直接复用。 | `protected $ci; public function __construct(){ parent::__construct(); $this->ci =& get_instance(); }` |
| 🟡 建议 | `ScreenApi.php` / 全局 | 控制器过于臃肿（God Object），`switch` 包含数百行业务逻辑，违反单一职责与开闭原则。 | 按功能域拆分为独立 Service 类，控制器仅负责路由分发、参数校验与响应格式化。 | 引入策略模式：`$handler = ScreenHandlerFactory::create($function); $handler->handle($params);` |
| 🟡 建议 | `Ahead_shop_book_time_info_model.php` / 多处 | 大量使用 `self::$xxx` 静态变量缓存数据。在长连接/CLI 环境下易导致内存泄漏或请求间数据污染。 | 改用实例属性缓存，或接入 Redis 等外部缓存并设置 TTL。 | `private $requestCache = [];` 替代 `public static $xxx = [];` |
| 🟡 建议 | 全局 | 代码风格未严格遵循 PSR-12（缩进不一致、大括号位置混用、命名规范不统一）。 | 配置 `PHP-CS-Fixer` 或 `PHP_CodeSniffer` 进行自动化格式化与静态检查。 | `php-cs-fixer fix . --rules=@PSR12` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **安全漏洞修复**：立即替换 `checkWriteable()` 与关房逻辑中的原生 SQL 拼接，全面改用 CI3 Query Builder 或预处理语句；限制 CORS 白名单。
2. **控制流重构**：彻底移除 `goto` 语句，将关房后的状态更新、消息推送、任务生成等逻辑封装为独立方法，通过 `return` 或条件判断流转。
3. **致命错误防御**：修复 `array_intersect` 空数组展开问题，增加 `json_decode` 后的类型校验（如 `is_array()`），避免线上 500 错误。
4. **前端异步治理**：小程序端 `addService` 需引入 `Promise.all` 等待图片上传完成，并增加 loading 状态与失败重试机制。
### 🛠 后续重构与优化方向
1. **架构分层解耦**：当前 Model 层严重越权（承担了 Service、Helper、甚至部分 Controller 职责）。建议引入 `Service` 层处理复杂业务（如时段计算、发券逻辑、微信推送），Model 仅保留数据存取与基础查询。
2. **控制器瘦身**：`ScreenApi.php` 建议采用 **命令模式（Command Pattern）** 或 **策略模式（Strategy Pattern）** 替代巨型 `switch`。每个 `function` 对应一个独立 Handler 类，便于单元测试与后续扩展。
3. **缓存策略升级**：静态变量缓存改为请求级缓存（实例属性）或 Redis 分布式缓存。对于高频查询的门店配置、包厢状态，建议增加缓存失效机制（如发布订阅或版本号控制）。
4. **框架适配说明**：
> ⚠️ 注：提交代码实际基于 **CodeIgniter 3** 架构（特征：`get_instance()`、`load->model()`、`BASEPATH`、`$this->db`）。若 `phpci` 为内部定制框架，请对照其官方生命周期文档调整组件加载方式。CI3 已停止官方维护，若项目处于长期迭代期，建议评估平滑迁移至 CI4 或现代 PHP 框架（如 Laravel/Symfony）的可行性，以获得更好的类型安全、依赖注入与中间件支持。
5. **质量保障**：引入 PHPStan 或 Psalm 进行静态类型分析；为核心时段计算逻辑补充 PHPUnit 单元测试，覆盖边界条件（如跨天、24小时营业、最低时长限制、并发预订冲突）。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779869404
|
1779869404
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
367
|
21
|
111
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `58b9c6915 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `58b9c6915931a7b047a3cba8208be79183192a18`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-27 16:14:28
---
## 1. 审查摘要
- **代码质量评分**：4 / 10 分
- **总体评价**：该类承担了订单创建、价格计算、会员折扣、优惠券匹配、服务费核算等核心业务，逻辑复杂度高。但实现方式较为陈旧，存在**SQL注入隐患、浮点数精度丢失、关键变量重复覆盖**等严重问题。方法体过长（超600行），严重违反单一职责原则，可维护性与扩展性较差。
- **风险等级**：🔴 高
- **⚠️ 局限性说明**：提交代码在 `$result['have_good` 处截断，本次审查仅基于可见部分。若截断处包含关键事务提交或状态更新逻辑，请补充后复核。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `getOrderTypeInfo` 约 L240 | **SQL 注入风险**：使用 `implode` 拼接 `IN` 查询条件 `$pack_goods_where = "... in (" . implode(",", $id_array['package_id']) . ")"`，未对 `$id_array['package_id']` 进行类型过滤或参数绑定。 | 严格使用框架查询构建器的 `where_in` 方法，或对输入数组进行强制整型转换。 | `$ids = array_map('intval', $id_array['package_id']);`<br>`$this->CI->db->where_in('wares_package._package_id', $ids);` |
| 🔴 严重 | 全文多处 | **金额计算精度丢失**：直接使用浮点数进行货币乘除（如 `$goods['_cost_price'] * $quantity`），PHP 浮点运算会导致 `0.1+0.2=0.30000000000000004` 类问题，极易引发财务对账差异。 | 财务计算必须使用 `bcmath` 扩展函数，或统一转换为“分”为单位的整数运算。 | `bcmul($price, $quantity, 2)`<br>或 `$price_cents = (int)round($price * 100);` |
| 🔴 严重 | `getOrderTypeInfo` 约 L330 | **逻辑覆盖/冗余赋值**：`$order['_prime_service_charge']` 被连续赋值两次，后者直接覆盖前者，导致前置计算结果丢失，业务逻辑错误。 | 删除重复赋值行，明确业务意图。若需区分“折前”与“折后”服务费，应使用不同键名。 | 移除 `$order['_prime_service_charge'] = $service_charge;` 或改为 `$order['_final_service_charge'] = $service_charge;` |
| 🟠 警告 | 全文多处 | **模型重复加载**：在方法内部多次调用 `$this->CI->load->model(...)`。虽然 CI 框架会缓存实例，但频繁调用增加解析开销且破坏代码整洁性。 | 将模型加载统一移至 `__construct()` 或方法顶部，按需使用。 | `// __construct 中统一加载`<br>`$this->CI->load->model(['Ahead_merchant_goods_model', 'Ahead_vip_level_model', ...]);` |
| 🟠 警告 | `_create_insert_infos_data` 等 | **静态属性访问不规范 & 重复计算**：通过实例访问静态属性 `$this->CI->Ahead_vip_level_model::VIP_LEVEL_DEFAULT_NAME`，且在多处重复调用 `count()`。PHP 8+ 已废弃此写法。 | 直接通过类名访问静态属性，并将结果缓存为类属性，避免重复计算。 | `private $vip_max_level;`<br>`// 构造时赋值`<br>`$this->vip_max_level = count(Ahead_vip_level_model::VIP_LEVEL_DEFAULT_NAME);` |
| 🟠 警告 | `getOrderTypeInfo` | **异常处理不规范**：使用全局函数 `throwError()` 中断流程，破坏面向对象封装，且无法被上层 `try-catch` 统一捕获，不利于事务回滚。 | 改用标准 `throw new \Exception()` 或自定义业务异常类，配合事务机制处理。 | `throw new \InvalidArgumentException("商品{$val['_goods_name']}已被禁用");` |
| 🟡 建议 | 类定义/方法名 | **命名不符合 PSR-12**：类名 `Neworderservice` 未使用大驼峰；方法 `rest_goods_price_by_un_vip` 存在拼写错误（应为 `reset`）；变量命名风格混杂。 | 遵循 PSR-12 规范：类名 `NewOrderService`，方法名 `resetGoodsPriceByUnVip`，属性使用小驼峰。 | `class NewOrderService { public function resetGoodsPriceByUnVip(...) }` |
| 🟡 建议 | `getOrderTypeInfo` | **方法过长/违反单一职责**：该方法超 600 行，混合了数据校验、价格计算、优惠券匹配、订单组装等逻辑，圈复杂度过高，极难测试与维护。 | 拆分为独立私有方法或策略类，如 `validateGoods()`, `calculatePrice()`, `applyDiscounts()`, `buildOrderData()`。 | 提取 `private function calculatePackagePrice(...)` 等方法，主方法仅负责流程编排。 |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即修复 SQL 注入漏洞**：将 `implode` 拼接的 SQL 条件替换为框架查询构建器或严格类型过滤，防止恶意输入导致数据泄露或篡改。
2. **统一财务计算精度**：全局替换浮点数直接运算，引入 `bcmath` 或“分”单位整数计算，并在输出前统一格式化，确保财务数据绝对准确。
3. **修正重复赋值逻辑**：排查 `$order['_prime_service_charge']` 及 `$result['service_charge']` 的重复赋值问题，避免业务计算结果被意外覆盖。
### 🛠 后续重构与优化方向
1. **架构拆分（SRP 原则）**：
- 将 `getOrderTypeInfo` 拆分为：`校验层`（商品状态/库存/权限）、`计算层`（原价/会员价/折扣/服务费）、`组装层`（订单结构/明细）。
- 针对订单类型 `1/13` 与 `2/4`，建议引入 **策略模式（Strategy Pattern）**，将不同订单类型的计价逻辑抽离为独立类，消除庞大的 `switch-case`。
2. **依赖注入与模型管理**：
- 避免在业务方法中动态 `load->model()`，改为在构造函数中注入或统一加载。若 `phpci` 支持 DI 容器，建议通过容器解析模型依赖。
3. **异常与事务控制**：
- 使用 `try-catch` 包裹核心下单流程，结合数据库事务（`$this->CI->db->trans_start()` / `trans_complete()`），确保价格计算失败或库存校验不通过时能安全回滚。
4. **框架适配提示**：
> 基于代码特征（`defined('BASEPATH')`, `get_instance()`, `$this->CI->load->model()`），该代码高度符合 **CodeIgniter 3** 架构。若 `phpci` 为内部定制框架，请查阅其官方文档确认：
> - 查询构建器是否支持 `where_in` 参数绑定
> - 模型加载机制是否支持自动依赖注入
> - 全局异常处理钩子（`_exception_handler`）的配置方式
如需对截断部分或特定业务分支（如优惠券抵扣逻辑、会员升级推荐算法）进行深度审查，请提供完整代码片段。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779869668
|
1779869668
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
368
|
21
|
112
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `957cbb6a7 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `957cbb6a73dfead2972a3f1e02720cb6c81d94bc`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-27 16:18:07
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：业务逻辑覆盖全面，能处理多场景（KTV/台球/棋牌/酒馆）、套餐规则、跨天营业等复杂预订需求。但代码存在严重的架构设计缺陷：静态缓存未隔离租户、直接污染全局 `$CI` 实例、核心方法严重违反单一职责原则。时间处理依赖大量字符串拼接与未定义的辅助函数，可维护性与可测试性较低。
- **风险等级**：🔴 高
> 📌 **框架说明**：根据目录结构、`get_instance()`、`$this->load->model()` 等特征，该代码实际基于 **CodeIgniter 3** 架构。若 `phpci` 为内部定制框架，请对照其官方文档调整。以下审查基于 CI3 最佳实践与现代 PHP 规范。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 静态属性/缓存 | `self::$book_days_info`、`self::$shop_data` 等静态缓存未区分 `merchant_id` 与 `shop_id`。在多租户/多门店并发或长连接环境下，会导致严重的数据串扰与越权访问。 | 为静态缓存增加复合键，或改用 CI Cache/Redis 驱动，并设置合理 TTL。避免在 Model 中使用无状态隔离的静态变量。 | `private static $cache = [];`<br>`$key = md5($merchant_id . '_' . $shop_id . '_' . $date);`<br>`if (isset(self::$cache[$key])) return self::$cache[$key];`<br>`self::$cache[$key] = $result;` |
| 🔴 严重 | 多处 | 直接修改全局 `$CI` 实例属性（如 `$CI->operational_scene`、`$CI->package_not_available_time`、`$CI->change_book_order_id`）。破坏框架请求隔离机制，极易引发并发状态污染与难以追踪的隐蔽 Bug。 | 严禁修改 `$CI` 全局状态。应通过类属性、方法返回值、Session 或 Config 传递上下文数据。 | 移除 `$CI->xxx = ...`，改为 `$this->operational_scene = $scene;` 或作为参数/返回值传递。 |
| 🔴 严重 | `get_book_day_time_info` | 方法超 300 行，混合了配置加载、时间区间计算、多规则校验（套餐/锁定/营业/清扫）、数据格式化。严重违反单一职责原则(SRP)，无法进行单元测试，后期维护成本极高。 | 拆分为独立私有方法，或抽离为 `BookingTimeCalculator` 服务类。按职责分层：配置获取 → 基础时间生成 → 规则过滤 → 结果组装。 | 见下方【重构方向】建议。 |
| 🟠 警告 | 多处 | 大量使用硬编码魔法值（如 `'1'`, `'2'`, `'merchantApp'`, `'-1'`, `'7'`），缺乏语义化常量。业务逻辑变更时极易遗漏或误改。 | 定义类常量或全局配置常量，提升代码可读性与安全性。 | `const SCENE_KTV = '1'; const SCENE_BILLIARDS = '2';`<br>`const STATUS_AVAILABLE = '1'; const STATUS_UNAVAILABLE = '-1';` |
| 🟠 警告 | `_get_un_book_time` 及循环内 | 频繁调用 `get_shop_setting()` 获取配置，未做批量查询或内存缓存。在复杂请求链路中易引发 N+1 查询与数据库性能瓶颈。 | 在方法入口一次性批量获取所需配置，或使用 CI Cache 缓存门店配置项。 | `$keys = ['book_minute_unit', 'book_hour_options', ...];`<br>`$configs = $this->ahead_shop_config_second_model->get_batch_settings($mid, $sid, $keys);` |
| 🟠 警告 | `array_intersect(...)` | `array_intersect(...array_values($all_room_book_time))` 在数组为空或仅含一个元素时，PHP 会抛出 `Warning`，且解包逻辑不符合预期。 | 增加数组长度安全判断，或使用循环计算交集。 | `if (count($all_room_book_time) > 1) { $un_book_time = array_intersect(...array_values($all_room_book_time)); } else { $un_book_time = $all_room_book_time[0] ?? []; }` |
| 🟡 建议 | 全局 | 未遵循 PSR-12 规范：缺少严格类型声明、属性可见性不统一、注释不完整、行过长。部分辅助函数（如 `timeToHour`, `shiftTimeRange`）未提供定义，难以评估其边界行为。 | 补充 `declare(strict_types=1);`，为方法参数/返回值添加类型提示，统一使用 `private/protected` 属性，完善 PHPDoc。 | `public function get_book_days_info(int $merchant_id, int $shop_id, string $check_date = '', bool $add_day = false): array` |
| 🟡 建议 | 时间处理 | 依赖大量自定义辅助函数与字符串拼接处理时间，缺乏时区控制与 `DateTimeImmutable` 对象封装。跨天、24小时制、边界分钟计算易出现逻辑漏洞。 | 引入 `DateTimeImmutable` 或专用时间区间 Value Object 替代字符串操作，提升类型安全与可读性。 | 建议使用 `Carbon` 或原生 `DateTimeImmutable` 进行区间计算，避免 `strtotime` + 字符串拼接。 |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **隔离静态缓存**：立即为所有 `self::$xxx` 静态属性添加 `merchant_id` + `shop_id` + `date` 的复合键，或彻底移除静态缓存改用 CI Cache/Redis，杜绝多租户数据串扰。
2. **清除全局 `$CI` 污染**：全面排查并移除 `$CI->xxx = ...` 赋值操作。将上下文数据改为通过方法参数传递或封装在类实例属性中。
3. **拆分超长方法**：将 `get_book_day_time_info` 拆分为至少 4 个独立步骤：
- `loadBookingConfig()`：加载门店与场景配置
- `generateBaseTimeSlots()`：生成基础时间轴
- `applyBookingRules()`：应用套餐、锁定、清扫、营业规则过滤
- `formatTimeSlots()`：组装最终返回结构
### 🛠 后续重构与优化方向
- **引入策略模式**：不同场景（KTV/台球/棋牌/酒馆）的预订规则差异较大，建议定义 `BookingRuleInterface`，按场景注入对应策略类，替代冗长的 `if/elseif` 分支。
- **时间区间对象化**：创建 `TimeRange` 值对象，封装 `start`, `end`, `isOverlap()`, `merge()`, `shift()` 等方法，彻底替代当前散落的字符串与数组操作。
- **完善输入校验**：对 `$params` 数组进行严格类型校验与白名单过滤，避免未定义键导致 `Undefined index` 警告或逻辑跳过。
- **补充单元测试**：核心时间计算逻辑必须覆盖边界用例（如跨天 23:55-00:05、24小时营业、套餐时长不足、并发锁定等），建议引入 `PHPUnit` 建立测试基线。
> ⚠️ **局限性说明**：您提供的代码片段在 `_get_un_book_time` 方法末尾被截断，无法完整评估次日时间计算、清扫逻辑闭环及最终返回结构。建议补充完整文件后再次提交审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779869887
|
1779869887
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
372
|
21
|
113
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `ccc72448c ## 自动代码审查报告
**分支**: pay-260519
**提交**: `ccc72448c881e39cebbc23ef0bd26770da488063`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-27 16:20:13
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该文件为典型的业务核心计价与订单组装类，承载了商品/套餐价格计算、VIP折扣、服务费、优惠券抵扣等复杂逻辑。整体功能完整，但存在**严重的方法臃肿、重复代码、遗留调试输出、潜在SQL注入及金额精度风险**。代码结构偏向过程式，未充分利用面向对象设计原则，且多处违反现代 PHP 与 CI3 最佳实践。
- **风险等级**：🔴 高（存在破坏 API 响应、数据覆盖、SQL 注入及金额计算偏差风险）
> 📌 **框架说明**：从 `defined('BASEPATH')`、`get_instance()`、目录结构及加载方式判断，该项目实际使用的是 **CodeIgniter 3** 框架，而非 `phpci`（phpci 为 CI/CD 持续集成工具）。以下审查基于 CI3 架构与 PSR-12 规范进行。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | ~L388 | 遗留调试代码 `echo $vip_upgrade_data_actual_pay;` 会直接输出到响应流，破坏 JSON/XML 结构，导致前端解析崩溃。 | 立即删除该 `echo`。生产环境严禁使用 `echo`/`print_r`/`var_dump`，应使用日志组件记录。 | `// 删除此行，如需记录请使用：log_message('debug', 'Upgrade pay: ' . $vip_upgrade_data_actual_pay);` |
| 🔴 严重 | ~L155 & L160 | 数组键 `$order['_prime_service_charge']` 被重复赋值，后者 `$service_charge` 覆盖前者，导致业务逻辑错乱。 | 明确业务意图，保留正确赋值，删除冗余行。 | `$order['_prime_service_charge'] = $service_charge; // 确认意图后仅保留一行` |
| 🔴 严重 | ~L248 | SQL 注入风险：`implode(",", $id_array['package_id'])` 直接拼接进 SQL 字符串传入模型。若 `$id_array` 含用户输入，将导致注入。 | 使用 CI3 Query Builder 的 `where_in()` 或参数绑定，严禁手动拼接 `IN` 条件。 | `$this->CI->db->where_in('_package_id', $id_array['package_id'])->get('wares_package_goods')->result_array();` |
| 🟠 警告 | 全文多处 | 模型重复加载：`$this->CI->load->model()` 在循环或方法内多次调用，增加不必要的 I/O 与内存开销。 | 将高频使用的模型统一在 `__construct()` 或方法顶部加载一次。 | `public function __construct() { $this->CI->load->model(['Ahead_merchant_goods_model', 'Ahead_vip_level_model', ...]); }` |
| 🟠 警告 | ~L100, L280 | 浮点数精度丢失：金额计算直接使用 `*`、`/` 和 `sprintf("%.2f")`，PHP 浮点运算易产生 `0.1+0.2=0.30000000000000004` 类偏差。 | 涉及财务计算统一转为“分”（整数运算）或使用 `bcmath` 扩展。 | `$actual_pay = bcmul($price, $quantity, 2); // 或使用 int 分单位计算后除以 100` |
| 🟠 警告 | ~L300 | 魔法数字泛滥：`-1`, `1`, `100`, `9999999999999` 等硬编码散落全文，状态含义不透明，维护成本高。 | 提取为类常量，使用语义化命名。 | `private const STATUS_DISABLED = -1; const MAX_REWARD_AMOUNT = 9999999999999; const DISCOUNT_RATE_BASE = 100;` |
| 🟡 建议 | ~L40 | `getOrderTypeInfo` 方法过长（>600行），嵌套深，违反单一职责原则（SRP），可读性与可测试性极差。 | 拆分为独立私有方法：`processGoodsOrder()`, `processPackageOrder()`, `calculateServiceCharge()`, `applyVipDiscount()` 等。 | 采用策略模式或提取子方法，将主方法控制在 50 行以内。 |
| 🟡 建议 | 全文 | 类名与属性不符合 PSR-12：`Neworderservice` 应为 `NewOrderService`；大量 `public` 属性暴露内部状态，易被外部误改。 | 遵循 PSR-12 命名规范；将属性改为 `private/protected`，通过构造函数或 Setter 注入必要参数。 | `class NewOrderService { private $room_id = 0; public function setRoomId(int $id): self { $this->room_id = $id; return $this; } }` |
| 🟡 建议 | ~L20 | `throwError()` 非 PHP 原生机制。若其内部调用 `exit/die`，将导致数据库事务无法回滚、中间件生命周期中断。 | 改用标准异常 `throw new \RuntimeException(...)`，确保上层可 `try-catch` 并安全回滚。 | `throw new \RuntimeException("商品已售完，请联系商家", 100);` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即移除 `echo` 调试输出**：防止线上 API 响应格式损坏。
2. **修复重复赋值逻辑**：确认 `$order['_prime_service_charge']` 与 `$result['service_charge']` 的正确业务含义，消除覆盖 Bug。
3. **修复 SQL 拼接隐患**：将 `implode` 拼接的 `IN` 查询替换为 CI3 的 `where_in()` 或预处理语句。
4. **统一异常处理机制**：将 `throwError` 替换为 `throw new \Exception()`，确保事务与框架生命周期可正常回滚。
### 🛠 后续重构与优化方向
1. **方法拆分与职责分离**：`getOrderTypeInfo` 承载了太多职责。建议按订单类型（商品/套餐/开房）拆分为独立处理器，或引入**策略模式**（`OrderTypeStrategy`）动态路由计算逻辑。
2. **财务计算规范化**：引入 `Money` 值对象或使用 `bcmath`/整数分单位进行所有金额运算，避免浮点精度漂移导致的对账差异。
3. **依赖注入与模型预加载**：在 `__construct` 中集中加载模型，避免运行时重复 `load->model()`。考虑逐步向 CI4 或现代 PHP 的依赖注入容器过渡。
4. **常量与枚举替代魔法值**：将状态码（如 `-1` 禁用、`1` 启用、`100` 折扣基数）定义为 `const` 或 PHP 8.1+ `enum`，提升代码自解释性。
5. **单元测试覆盖**：该计价逻辑复杂度高，强烈建议补充 PHPUnit 测试用例，覆盖 VIP 折扣边界、服务费计算、优惠券叠加、免单逻辑等核心分支。
> ⚠️ **局限性说明**：您提供的代码在 `$result['have_good` 处被截断，未能完整展示方法结尾及后续逻辑。若截断部分包含事务提交、数据库写入或关键返回逻辑，请补充完整代码以便进行闭环审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779870013
|
1779870013
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
374
|
21
|
114
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `f60da7484 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `f60da748498cde8057bf3eb5a1f033392744a180`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-27 16:28:55
---
## 1. 审查摘要
- **代码质量评分**：5/10 分
- **总体评价**：该模型承载了极其复杂的预订时间计算与业务规则判断，逻辑耦合度高。存在多处架构设计缺陷（如顶部全局实例调用、静态属性滥用、巨型方法）、潜在运行时崩溃风险（空数组展开）以及明显的代码重复。整体可维护性、测试性与安全性较弱，需系统性重构。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 文件顶部 (第2行) | 在类外部直接调用 `$CI = &get_instance();`。在 PHP 请求生命周期中，框架实例尚未初始化或已销毁，会导致 `Fatal Error` 或不可预期的行为。 | 删除顶部全局调用。在类内部统一使用 `$this->load->model()` / `$this->load->library()` 加载依赖。 | `// 删除: $CI = &get_instance();`<br>`// 改为在方法内使用: $this->load->model('Simple_model');` |
| 🔴 严重 | `get_book_day_time_info` 方法内 | `array_intersect(...array_values($all_room_book_time))` 当 `$all_room_book_time` 为空数组时，展开运算符 `...` 会传递 0 个参数，触发 `ArgumentCountError` 致命错误。 | 增加数组长度校验，或使用 `call_user_func_array` 安全调用。 | `if (count($all_room_book_time) > 1) {<br> $un_book_time = array_intersect(...array_values($all_room_book_time));<br>} elseif (count($all_room_book_time) === 1) {<br> $un_book_time = reset($all_room_book_time);<br>}` |
| 🔴 严重 | 多处 (`self::$book_days_info` 等) | 滥用 `public static` 属性作为请求级缓存。在 PHP-FPM、Swoole 或常驻内存环境中会导致**数据串扰**与**内存泄漏**，且严重破坏单元测试的隔离性。 | 移除静态缓存。改用框架 Cache 组件（如 Redis/Memcached）或依赖注入容器管理请求级状态。 | `// 移除 public static $book_days_info = [];`<br>`// 改用: $cache_key = "book_days:{$merchant_id}:{$shop_id}";`<br>`$result = $this->cache->get($cache_key);` |
| 🟠 警告 | `set_shop_config()` & `set_room_info()` | 两个方法存在约 80% 的重复逻辑（场景前缀计算、配置加载、分钟单位换算），违反 DRY 原则，后期维护极易遗漏同步。 | 提取私有方法 `_get_scene_prefix()` 与 `_apply_shop_config()` 统一处理配置加载。 | `private function _get_scene_prefix(string $scene): string {<br> return match($scene) {<br> '2' => 'billiards_',<br> '3' => 'card_',<br> '4' => 'tavern_',<br> default => ''<br> };<br>}` |
| 🟠 警告 | `get_book_day_time_info()` | 方法超过 300 行，混合了数据查询、时间区间计算、状态标记、套餐规则校验、营业时间过滤等，违反单一职责原则(SRP)，极难调试与测试。 | 拆分为独立方法：`_fetch_booking_data()`, `_calculate_time_slots()`, `_apply_package_rules()`, `_filter_by_business_hours()`。 | 建议将时间区间交集判断封装为独立工具类 `TimeRangeCalculator::hasOverlap($a, $b)`。 |
| 🟠 警告 | 多处 `$params['key']` | 直接访问 `$params` 数组键未做存在性检查，当外部传入缺失字段时会触发 `Undefined index` 警告，可能导致逻辑分支异常。 | 使用空值合并运算符 `??` 或提前进行参数校验。 | `$date = $params['date'] ?? '';`<br>`$book_model = $params['book_model'] ?? '1';` |
| 🟡 建议 | 全局 | 大量硬编码魔法值（如 `'1'`, `'2'`, `'-1'`, `'merchantApp'`, `'7'`）散落在业务逻辑中，可读性差且易出错。 | 定义类常量或枚举类集中管理。 | `const SCENE_KTV = '1';`<br>`const SCENE_BILLIARDS = '2';`<br>`const STATUS_AVAILABLE = '1';` |
| 🟡 建议 | 全局 | 缺乏现代 PHP 类型声明（参数类型、返回值类型、属性可见性），不符合 PSR-12 及 PHP 8+ 最佳实践。 | 为所有公开方法添加类型提示，明确属性可见性（`protected`/`private`）。 | `public function get_book_days_info(int $merchant_id, int $shop_id, string $check_date = '', bool $add_day = false): array` |
| 🟡 建议 | 时间处理逻辑 | 依赖 `date()` 和 `strtotime()` 未显式指定时区，在多租户或跨时区部署时极易产生“差一天/差一小时”的边界 Bug。 | 统一使用 `DateTimeImmutable` 或框架时区配置，避免隐式时区转换。 | `$dt = new DateTimeImmutable($date, new DateTimeZone('Asia/Shanghai'));` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **移除顶部 `$CI = &get_instance();`**：这是导致应用启动崩溃或状态污染的根源。所有框架实例访问必须收敛至类方法内部。
2. **修复 `array_intersect` 空数组展开崩溃**：在调用前增加 `count() > 1` 判断，避免生产环境 500 错误。
3. **废弃 `public static` 缓存**：立即替换为框架 Cache 组件或请求级单例模式，防止持久化进程下的数据串扰与内存泄漏。
4. **补充 `$params` 参数校验**：在方法入口处统一校验必填字段，使用 `??` 提供安全默认值，阻断 `Undefined index` 传播。
### 🛠 后续重构与优化方向
- **架构拆分**：将 `get_book_day_time_info` 拆分为“数据获取层”、“时间计算层”、“规则过滤层”。建议引入策略模式处理不同预订模型（时长预订 vs 套餐预订）的差异逻辑。
- **配置加载优化**：当前多次调用 `get_shop_setting` 获取不同配置项，建议改为批量查询或一次性加载门店配置到内存数组中，减少数据库 I/O。
- **时间区间计算标准化**：当前大量使用 `array_intersect`、`shiftTimeRange`、`mergeTimeRanges` 等自定义函数处理时间交集。建议引入成熟的时间区间处理库（如 `spatie/period`）或封装独立的 `TimeSlotManager` 类，提升边界条件（跨天、重叠、包含）的准确性。
- **规范与静态分析**：全面对齐 PSR-12 规范，补充 PHPDoc 与类型声明。建议接入 `PHPStan` 或 `Psalm` 进行静态代码分析，提前捕获类型不匹配与未定义变量问题。
- **框架适配说明**：代码结构高度类似 CodeIgniter 3。若 `phpci` 为内部定制框架，请查阅其官方文档确认 `get_instance()` 的生命周期与模型加载规范。但无论何种框架，**模型层不应承担视图/控制器职责**，且应严格遵循依赖注入或标准加载器模式。
> 💡 **提示**：由于未提供 `Simple_model` 父类实现及外部辅助函数（如 `throwError`, `mergeTimeRanges` 等）的定义，本次审查主要聚焦于当前文件可见的逻辑与架构问题。建议在完整上下文中补充单元测试，重点覆盖跨天预订、套餐时长不足、营业时间边界等核心场景。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779870535
|
1779870535
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
377
|
21
|
115
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `7a26bc126 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `7a26bc126a88c6deedb8b70b5c8031ae5b33e1bb`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-27 16:33:56
---
## 1. 审查摘要
- **代码质量评分**：6.0 / 10 分
- **总体评价**：代码实现了较为复杂的订单计价与包厢预订时间计算逻辑，业务覆盖全面。但存在典型的“上帝方法（God Method）”特征，方法体过长、职责不单一；遗留了调试输出语句；金额计算缺乏高精度控制；且未遵循现代 PHP 类型声明规范。整体可维护性较低，存在线上稳定性与精度风险。
- **风险等级**：🔴 高（涉及金额精度、调试输出污染、逻辑覆盖风险）
> ⚠️ **局限性说明**：提供的代码片段在末尾被截断（如 `getOrderTypeInfo` 未闭合、`Ahead_shop_book_time_info_model.php` 结尾不完整）。本次审查仅基于可见代码进行，若截断部分包含关键事务提交、锁机制或异常回滚逻辑，请补充后二次审查。
> 📌 **框架说明**：代码结构高度符合 `CodeIgniter 3` 规范（`BASEPATH`、`get_instance()`、`$this->load->model()`）。若 `phpci` 为内部定制框架，请结合其官方文档确认组件加载与生命周期差异。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Neworderservice.php` (约第 380 行) | 循环体内遗留 `echo $vip_upgrade_data_actual_pay;` 调试语句。在 API 或 JSON 响应场景下会直接破坏输出结构，导致前端解析失败。 | 立即移除 `echo`，替换为日志记录（如 `log_message('debug', ...)`）或直接删除。 | `// 移除该行，或改为：<br>log_message('debug', 'VIP升级金额累加: ' . $vip_upgrade_data_actual_pay);` |
| 🔴 严重 | `Neworderservice.php` (多处) | 金额计算全程使用浮点数直接乘除累加（如 `$actual_pay += ...`），PHP 浮点数精度缺陷会导致 `0.1+0.2=0.30000000000000004` 类问题，最终结算金额可能偏差。 | 引入 `bcmath` 扩展进行高精度计算，或统一将金额转为“分（整数）”计算，仅在输出时格式化。 | `$actual_pay = bcadd($actual_pay, bcmul($price, $quantity, 2), 2);` |
| 🟠 警告 | `Neworderservice.php` (约第 400 行) | `$order['_prime_service_charge']` 与 `$result['service_charge']` 被重复赋值覆盖，逻辑冗余且易掩盖真实业务意图。 | 清理重复赋值，明确变量职责。若为笔误，保留最终计算值即可。 | `// 删除重复行：<br>$order['_prime_service_charge'] = $service_charge;` |
| 🟠 警告 | `Neworderservice.php` / `Model` 多处 | 频繁在业务方法内部调用 `$this->CI->load->model()` 或 `get_instance()`。CI 框架每次调用均会触发文件包含与实例化检查，造成不必要的性能损耗。 | 将依赖模型统一在 `__construct` 中加载，或配置 CI 的 `autoload.php`。 | `public function __construct() {<br> $this->CI =& get_instance();<br> $this->CI->load->model(['Ahead_vip_level_model', 'Ahead_merchant_goods_model']);<br>}` |
| 🟠 警告 | `Ahead_shop_book_time_info_model.php` (多处) | 大量使用 `strtotime()` + `date()` 进行时间区间运算，未处理时区/夏令时边界，且在循环中重复调用性能较差。 | 使用 PHP `DateTime` 与 `DateInterval` 对象替代，提升准确性与可读性。 | `$dt = new DateTime($date, new DateTimeZone('Asia/Shanghai'));<br>$dt->modify('+1 day');<br>$nextDate = $dt->format('Ymd');` |
| 🟠 警告 | `Neworderservice.php` (约第 100 行) | `count($this->CI->Ahead_vip_level_model::VIP_LEVEL_DEFAULT_NAME)` 通过实例访问静态属性。PHP 8.2+ 已弃用此语法，将触发 `Deprecated` 警告。 | 直接使用类名访问静态属性。 | `count(Ahead_vip_level_model::VIP_LEVEL_DEFAULT_NAME)` |
| 🟡 建议 | `Neworderservice.php` (方法名) | `rest_goods_price_by_un_vip` 存在拼写错误，语义应为 `reset`（重置）。 | 重命名方法并全局替换调用处，保持命名一致性。 | `public function reset_goods_price_by_un_vip(...)` |
| 🟡 建议 | 两文件全篇 | 缺乏类型声明（属性、参数、返回值），违反 PSR-12 规范，降低静态分析工具（PHPStan/Psalm）检测能力与 IDE 提示体验。 | 逐步补充 PHP 7.4+/8.0+ 类型提示。 | `public function getOrderTypeInfo(string $type, array $id_array, array $goods_quantity, int $get_actual_pay = -1, array &$goods_reward = []): array` |
| 🟡 建议 | `Neworderservice.php` (多处) | 魔法数字泛滥（如 `9999999999999`、`1000`、`100`、`-1`、`1`），业务含义不透明，后期维护困难。 | 提取为类常量或配置文件，增强语义。 | `const MAX_REWARD_AMOUNT = 9999999999999;<br>const VIP_DISCOUNT_BASE = 100;` |
## 3. 总结与行动建议
### 🚨 优先修复项（P0）
1. **立即移除 `echo` 调试代码**：防止破坏 API 响应结构或引发前端白屏。
2. **统一金额计算精度**：将核心计价逻辑中的浮点运算替换为 `bcmath` 函数族（`bcadd`, `bcmul`, `bcsub`），或在入库/返回前强制 `round($val, 2)`。
3. **清理重复赋值与冗余逻辑**：检查 `$order['_prime_service_charge']` 等覆盖赋值，确认业务真实意图，避免财务对账差异。
### 🛠 后续重构与优化方向
1. **拆分“上帝方法”**：`getOrderTypeInfo` 与 `get_book_day_time_info` 均超过 300 行，圈复杂度极高。建议按业务域拆分为独立方法或类：
- `calculateGoodsPrice()`
- `calculatePackagePrice()`
- `applyVipDiscount()`
- `calculateServiceCharge()`
- 使用 **策略模式（Strategy Pattern）** 替代冗长的 `switch ($type)`，提升扩展性。
2. **优化模型加载与依赖注入**：CI 框架中频繁 `load->model` 会拖慢响应。建议在 `__construct` 中集中加载，或考虑迁移至依赖注入容器（若框架支持）。
3. **强化输入校验与安全边界**：
- `$id_array`、`$params` 等外部传入数据应使用 CI 的 `form_validation` 或自定义校验器进行类型/范围过滤。
- `throwError()` 若直接输出异常信息，需确保已过滤敏感路径或 SQL 语句，避免信息泄露。
4. **补充现代 PHP 规范**：逐步添加 `declare(strict_types=1);`、属性类型声明、方法返回值类型。可借助 `PHP_CodeSniffer` (PSR-12) 与 `PHPStan` 进行自动化流水线检查。
5. **时间计算重构**：预订逻辑涉及大量跨天、时段合并、区间交集运算。建议封装独立的 `TimeRangeCalculator` 工具类，使用 `DateTimeImmutable` 保证不可变性，避免隐式状态污染。
> 💡 **提示**：若 `phpci` 框架内置了事务管理、缓存驱动或权限中间件，请优先使用框架原生组件替代手写逻辑。建议查阅 `phpci` 官方文档中关于 `Database Transactions`、`Cache` 及 `Middleware` 的最佳实践章节。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779870837
|
1779870837
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
378
|
21
|
116
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `d51040a64 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `d51040a64d4ca444a5aa3542ab2812879528d3ff`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-27 16:34:53
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了较为复杂的订单计价、会员折扣、包厢预订时段计算等核心业务逻辑，但存在明显的调试代码残留、变量覆盖、SQL 拼接隐患及方法过长等问题。整体架构偏向“过程式堆砌”，缺乏模块化拆分与常量管理，可维护性与扩展性较弱。
- **风险等级**：🔴 高（存在破坏 API 响应、服务费计算错误及潜在 SQL 注入风险）
> 📌 **框架说明**：代码结构、`BASEPATH`、`get_instance()` 及 `$this->CI->load->model()` 等特征高度符合 **CodeIgniter 3** 规范。若 `phpci` 为贵司内部定制分支，请确保以下建议与底层核心兼容。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Neworderservice.php` ~L450 | 遗留 `echo $vip_upgrade_data_actual_pay;` 调试语句。在 API 场景下会直接输出到响应体，破坏 JSON/XML 结构，导致客户端解析崩溃。 | 立即移除 `echo`，如需记录日志请使用 CI 日志组件 `$this->CI->log->write_log()`。 | `// 删除该行，或替换为：<br>$this->CI->log->write_log('debug', 'vip_upgrade_actual_pay: ' . $vip_upgrade_data_actual_pay);` |
| 🔴 严重 | `Neworderservice.php` ~L520 | 变量重复赋值覆盖：`$order['_prime_service_charge']` 先被赋值为 `$prime_after_paid_service_charge`，紧接着又被 `$service_charge` 覆盖，导致原始服务费计算结果丢失。 | 核对业务意图，若需保留两个值请重命名变量；若为笔误则删除冗余赋值。 | `$order['_prime_service_charge'] = $prime_after_paid_service_charge;<br>// 删除下方重复的 $order['_prime_service_charge'] = $service_charge;` |
| 🟠 警告 | `Neworderservice.php` ~L280 | 直接拼接 SQL 条件：`"wares_package._package_id in (" . implode(",", $id_array['package_id']) . ")"`，未对数组元素进行类型过滤，存在 SQL 注入风险。 | 使用 CI3 查询构造器 `where_in()`，或对 ID 进行 `(int)` 强转清洗。 | `$clean_ids = array_map('intval', $id_array['package_id']);<br>$this->CI->db->where_in('_package_id', $clean_ids);` |
| 🟠 警告 | `Neworderservice.php` 多处 | 频繁在业务方法内 `$this->CI->load->model()`，增加框架 I/O 开销；且 `$this->CI->Ahead_vip_level_model::VIP_LEVEL_DEFAULT_NAME` 静态访问方式不规范。 | 将常用模型加载移至 `__construct()`；静态常量应通过类名直接访问。 | `// __construct 中：<br>$this->CI->load->model('Ahead_vip_level_model');<br>// 使用时：<br>$vip_max_level = count(Ahead_vip_level_model::VIP_LEVEL_DEFAULT_NAME);` |
| 🟠 警告 | `Ahead_shop_book_time_info_model.php` 多处 | 使用 `self::$book_days_info`、`self::$shop_data` 等静态属性缓存数据。在 PHP-FPM 长进程环境下易跨请求残留，且无失效机制，可能引发脏数据或内存泄漏。 | 改用 CI Cache 驱动或请求级单例，并设置合理 TTL。 | `$key = "shop_book_days_{$merchant_id}_{$shop_id}";<br>if (!$data = $this->cache->get($key)) {<br> // 计算逻辑...<br> $this->cache->save($key, $data, 300);<br>}` |
| 🟡 建议 | `Neworderservice.php` ~L150 | 财务金额计算使用 `sprintf("%.2f", ...)` 返回字符串类型，后续参与加减乘除会触发隐式类型转换，存在精度丢失隐患。 | 统一使用 `round($val, 2)` 返回浮点型，或引入 `bcmath` 扩展进行高精度计算。 | `$__wares_vip_price = round($wares_price_data['vip_price'] * $discount_goods_reward, 2);` |
| 🟡 建议 | 两个文件多处 | 核心方法过长（`getOrderTypeInfo` 超 500 行，`get_book_day_time_info` 超 400 行），严重违反单一职责原则（SRP），难以单元测试与后续迭代。 | 按业务边界拆分为独立私有方法，主方法仅负责流程编排。 | `private function calculateGoodsPricing($goods, $vip_info) {...}<br>private function calculatePackagePricing($package, $vip_info) {...}<br>public function getOrderTypeInfo(...) {<br> $goods_res = $this->calculateGoodsPricing(...);<br> $pkg_res = $this->calculatePackagePricing(...);<br> return $this->assembleOrderResult($goods_res, $pkg_res);<br>}` |
| 🟡 建议 | 两个文件多处 | 大量魔法数字散落（如 `-1`, `1`, `100`, `9999999999999`, `7`），缺乏语义化定义，可读性与维护成本高。 | 在类顶部定义 `const` 常量集中管理状态与阈值。 | `const STATUS_DISABLED = -1;<br>const DISCOUNT_BASE = 100;<br>const MAX_REWARD_AMOUNT = 9999999999999;<br>const PAY_PLATFORM_SCAN = 7;` |
---
## 3. 总结与行动建议
### 🚨 优先修复项（P0）
1. **清除调试输出**：全局搜索 `echo`、`var_dump`、`print_r`，确保生产环境无意外输出。
2. **修复变量覆盖**：定位 `$order['_prime_service_charge']` 重复赋值处，确认业务逻辑后修正，避免服务费结算错误引发客诉。
3. **SQL 注入防御**：将所有 `implode` 拼接的 `IN` 查询替换为 `$this->db->where_in()` 或严格类型过滤。
### 🛠 重构与优化方向
1. **方法拆分与职责收敛**：建议将 `Neworderservice` 拆分为 `OrderPriceCalculator`、`VipDiscountStrategy`、`PackageHandler` 等独立类，利用策略模式处理不同支付平台与会员等级的计价逻辑。
2. **财务计算规范化**：金额计算统一使用 `round($value, 2, PHP_ROUND_HALF_UP)`，若涉及分账或高精度对账，强烈建议迁移至 `bcmath` 函数族（如 `bcadd`, `bcmul`）。
3. **缓存机制升级**：移除模型中的静态数组缓存，改用 CI 内置 Cache 库（Redis/Memcached/File）并设置合理过期时间，避免 PHP-FPM 进程池数据污染。
4. **常量与枚举管理**：建立全局配置类或枚举文件，将 `-1`（禁用/不可用）、`1`（启用/可用）、`100`（折扣基数）等魔法值集中管理，提升代码自解释能力。
> ⚠️ **局限性说明**：由于提供的代码片段在 `Neworderservice.php` 末尾及 `Ahead_shop_book_time_info_model.php` 末尾被截断，部分上下文（如 `throwError` 实现、辅助函数 `shiftTimeRange`/`mergeTimeRanges` 定义、数据库事务控制）未能完整评估。建议在完整代码合并前补充上述缺失部分进行二次审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779870893
|
1779870893
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
379
|
21
|
117
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `1297c9757 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `1297c97575e9eb332e955aaa4f63a84310cf42eb`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-27 16:37:11
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了复杂的包厢预订时段计算逻辑，涵盖跨天营业、团购券校验、最低时长限制、清扫缓冲等业务场景。但存在明显的架构设计缺陷：静态缓存滥用导致状态污染、方法职责过重、时间计算缺乏时区安全、强依赖全局超对象且缺乏输入校验。整体可维护性与健壮性较低，需进行结构性重构。
- **风险等级**：🔴 高（静态缓存脏数据、时间计算边界漏洞、方法过长导致逻辑难以追踪）
> 📌 **注**：代码呈现典型的 **CodeIgniter 3** 架构特征（如 `get_instance()`、`$this->load->model()`）。若 `phpci` 为内部定制框架，请确认其生命周期与 CI 一致。以下审查基于 CI/PHP 通用最佳实践。此外，**文件末尾代码被截断**，部分逻辑（如下一天不可用时间的完整计算）无法全面评估。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 约 145-150 行 | **静态缓存状态污染**：`self::$book_days_info` 等静态变量在首次赋值后直接返回，未区分 `$merchant_id`、`$shop_id`、`$add_day` 等参数。同一请求处理不同门店/日期时将返回错误数据。 | 改为实例级缓存或带复合键的静态缓存，或在方法入口清空/校验缓存键。 | `private static $book_days_cache = [];<br>public function get_book_days_info(...) {<br> $cache_key = md5(implode('_', func_get_args()));<br> if (isset(self::$book_days_cache[$cache_key])) return self::$book_days_cache[$cache_key];<br> // ... 计算逻辑 ...<br> return self::$book_days_cache[$cache_key] = $result;<br>}` |
| 🔴 严重 | 约 200-210 行 | **静态门店数据缓存未区分门店**：`self::$shop_data` 仅缓存首次查询的门店配置。若同请求切换 `$shop_id`，将复用错误营业时间，导致时段计算全面错乱。 | 移除静态缓存，或改为 `self::$shop_data[$shop_id]` 键值对缓存。 | `if (!isset(self::$shop_data[$shop_id])) {<br> self::$shop_data[$shop_id] = $this->ahead_shop_model->get_one(...);<br>}<br>$shop_data = self::$shop_data[$shop_id];` |
| 🟠 警告 | 全文多处 | **频繁调用 `get_instance()`**：每次调用都会产生函数开销，且破坏 OOP 封装。CI 框架推荐在构造函数中绑定一次。 | 在类属性中声明 `$ci`，构造函数中赋值，后续统一使用 `$this->ci`。 | `private $ci;<br>public function __construct() {<br> parent::__construct();<br> $this->ci =& get_instance();<br>}` |
| 🟠 警告 | 约 250-400 行 | **时间计算未处理时区/夏令时**：大量使用 `strtotime()`、`date()` 及硬编码 `86400` 进行加减。在跨天、夏令时切换或服务器时区变更时极易产生 `±1小时` 偏差。 | 统一使用 `DateTimeImmutable` 或 `Carbon` 库，显式指定时区，避免直接操作时间戳。 | `$dt = new DateTimeImmutable($date, new DateTimeZone('Asia/Shanghai'));<br>$end = $dt->modify('+1 day')->setTime(0,0);` |
| 🟠 警告 | 约 280-350 行 | **魔法数字与状态码硬编码**：`'1'`、`'-1'`、`86400`、`3600`、`'7'` 等散落各处，语义不明且极易在后续维护中引发逻辑错误。 | 提取为类常量，统一命名规范。 | `const STATUS_AVAILABLE = '1';<br>const STATUS_UNAVAILABLE = '-1';<br>const SECONDS_PER_DAY = 86400;` |
| 🟠 警告 | 约 230-550 行 | **方法职责过重（SRP 违反）**：`get_book_day_time_info` 超过 300 行，混合了数据查询、时间区间合并、套餐校验、状态标记、前端展示字段组装。难以测试与维护。 | 拆分为独立方法：`fetchBookingData()`、`calculateUnavailableSlots()`、`applyPackageRules()`、`formatTimeSlots()`。 | 见下方重构建议 |
| 🟡 建议 | 约 300 行 | **数组解包潜在风险**：`array_intersect(...array_values($all_room_book_time))` 在数组为空时会抛出 `ArgumentCountError`。虽有 `count > 1` 保护，但边界仍脆弱。 | 使用 `array_reduce` 或显式循环求交集，或确保数组非空。 | `if (count($all_room_book_time) > 1) {<br> $un_book_time = array_intersect(...array_values($all_room_book_time));<br>} else {<br> $un_book_time = reset($all_room_book_time) ?? [];<br>}` |
| 🟡 建议 | 约 100-130 行 | **输入参数缺乏校验**：`$params` 直接用于数据库查询与逻辑分支，未校验类型、必填项或合法范围。 | 增加前置校验或使用 CI 的 `form_validation`/自定义验证器。 | `if (empty($params['merchant_id']) || empty($params['shop_id'])) {<br> throwError('缺少必要参数');<br>}` |
| 🟡 建议 | 全文 | **PSR-12 规范与注释缺失**：属性声明混杂、部分方法无 PHPDoc、长行未换行、全局函数（如 `throwError`、`mergeTimeRanges`）依赖隐式加载。 | 遵循 PSR-12 格式化，补充 `@param`、`@return`、`@throws`，显式加载依赖或使用 DI。 | 使用 `php-cs-fixer` 自动格式化，补充类型声明：`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` 和 `self::$shop_data` 的缓存策略。这是导致线上“时段显示错乱/不可预订”的高频根因。
2. **时间计算安全**：将所有 `strtotime` + 秒数加减的逻辑替换为 `DateTimeImmutable` 或 `Carbon`，并统一时区配置（建议在 `index.php` 或框架入口设置 `date_default_timezone_set('Asia/Shanghai')`）。
3. **魔法数字常量化**：将 `'1'/'-1'`、`86400`、`3600` 等提取为类常量，提升代码可读性与可维护性。
### 🛠 后续重构与优化方向
1. **拆分巨型方法**：将 `get_book_day_time_info` 按职责拆分为 4~5 个私有方法。例如：
```php
private function calculateBaseUnavailableSlots($params): array
private function applyPackageConstraints(array &$slots): void
private function applyBusinessHoursConstraints(array &$slots): void
private function formatResponseSlots(array $slots): array
```
2. **引入策略模式处理规则**：当前大量 `if ($this->tuangou->verify_token)`、`if ($this->ignore_tuangou_time_limit)` 嵌套。建议抽象为 `BookingRuleInterface`，通过工厂或配置动态加载规则链，避免 `if-else` 爆炸。
3. **依赖注入替代全局加载**：逐步将 `$this->load->model()` 和 `$this->load->library()` 移至构造函数或通过 Service Container 注入，便于单元测试与 Mock。
4. **性能优化**：
- 对 `array_intersect`、`array_merge` 等高频数组操作，若数据量 > 1000，建议改用位运算或预计算索引。
- 考虑将 `prev_date` 和 `next_date` 的数据库查询合并为 `WHERE _date IN (...)` 批量查询，减少 DB 往返次数。
5. **补充单元测试**：针对跨天营业、套餐时长不足、清扫缓冲、不可用星期等边界场景编写 PHPUnit 用例，确保重构不破坏核心业务逻辑。
> 💡 **提示**：由于代码在 `$this->next_date_room_book_time = [...]` 处截断，后续关于“下一天不可用时间”的计算逻辑未完整展示。建议在完整提交后补充审查，重点关注跨天时间区间的合并算法与边界条件处理。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779871031
|
1779871031
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
380
|
21
|
118
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `9526c8bb4 ## 自动代码审查报告
**分支**: pay-260519
**提交**: `9526c8bb434751493f71e1b7d7d1e13f97bc89bf`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-27 16:37:55
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了复杂的包厢预订时间计算逻辑，但存在明显的架构反模式（如模型强状态化、静态缓存键冲突、超长方法违反单一职责）。业务规则交织严重，可维护性与并发安全性较低。部分逻辑存在重复与潜在的性能瓶颈。
- **风险等级**：🔴 高（状态污染与缓存键冲突可能导致线上预订数据错乱）
> 📌 **框架说明**：从目录结构（`system/helpers/`、`application/models/`）及 `$CI = &get_instance()` 的调用方式判断，该代码实际基于 **CodeIgniter 3** 架构。若 `phpci` 为内部定制框架，请结合其官方文档对生命周期与组件加载方式进行微调。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_days_info` (约 L158) | **静态缓存键冲突**：`self::$book_days_info` 未区分 `$merchant_id`、`$shop_id`、`$date` 等参数。同一请求内多次调用不同参数时，会返回错误缓存数据，导致日期状态错乱。 | 移除静态变量缓存，改用 CI 缓存驱动（`$this->cache->save()`）或构建复合键。若必须用静态缓存，需使用参数哈希作为键名。 | `// 推荐方案：使用复合键缓存<br>$cache_key = md5(__METHOD__ . serialize(func_get_args()));<br>if (isset(self::$cache_pool[$cache_key])) return self::$cache_pool[$cache_key];` |
| 🔴 严重 | 全局 (Model 属性) | **模型强状态化反模式**：大量 `public` 属性（如 `$book_room_id`, `$ignore_tuangou_time_limit`, `$tuangou`）用于存储单次请求上下文。在并发请求或同一请求多次实例化时极易发生状态污染。 | 模型应保持无状态。将请求上下文封装为 DTO 对象或通过方法参数传递。复杂业务逻辑应剥离至 `Service` 层。 | `// 错误：$this->book_room_id = $id;<br>// 正确：public function calculate($params, $room_id) { ... }` |
| 🟠 警告 | `set_shop_config` & `set_room_info` | **逻辑重复**：两个方法中计算 `$shop_config_scene` 及加载配置的代码高度重复，违反 DRY 原则。 | 提取为私有方法 `private function resolveShopConfigScene($scene)`，统一调用。 | `private function resolveSceneConfig($scene) {<br> $map = ['2'=>'billiards_', '3'=>'card_', '4'=>'tavern_'];<br> return $map[$scene] ?? '';<br>}` |
| 🟠 警告 | `get_book_day_time_info` (约 L190-L450) | **方法过长 & 违反单一职责**：该方法超 250 行，混合了营业时间计算、套餐规则过滤、不可用时间合并、跨天逻辑、状态标记等。极难测试与维护。 | 拆分为独立私有方法：`_calculateBusinessHours()`, `_applyPackageRules()`, `_mergeUnavailableTimes()`, `_filterTimeSlots()`。主方法仅负责流程编排。 | `// 主方法仅保留流程控制<br>$time_info = $this->_buildBaseTimeSlots($date);<br>$time_info = $this->_applyPackageConstraints($time_info, $params);<br>$time_info = $this->_filterByAvailability($time_info, $un_book_time);` |
| 🟠 警告 | 多处 (`$CI = &get_instance()`) | **频繁获取 CI 实例**：在多个方法中重复调用 `&get_instance()`，且直接读取控制器属性（如 `$CI->merchant_id`）。破坏封装性且增加开销。 | 在构造函数中统一赋值 `$this->ci = &get_instance();`，后续使用 `$this->ci`。控制器上下文应通过参数或 Session/Config 传递。 | `public function __construct() {<br> parent::__construct();<br> $this->ci = &get_instance();<br>}` |
| 🟡 建议 | `get_book_day_time_info` (约 L195) | **输入校验不足**：仅判断 `$date` 是否为空，未校验格式（如 `Ymd`）。非法日期传入 `strtotime` 会导致静默失败或返回错误时间戳。 | 增加正则或 `DateTime::createFromFormat` 校验，失败时抛出明确异常。 | `if (!preg_match('/^\d{8}$/', $date)) {<br> throwError('日期格式错误，应为 YYYYMMDD');<br>}` |
| 🟡 建议 | 全局 (硬编码字符串) | **魔法值泛滥**：`'1'`, `'2'`, `'3'`, `'merchantApp'`, `'-1'` 等散落在业务逻辑中，语义不明确且易改漏。 | 在类顶部定义常量：`const SCENE_KTV = '1'; const SCENE_BILLIARDS = '2'; const SOURCE_MERCHANT_APP = 'merchantApp';` | `if ($scene === self::SCENE_BILLIARDS) { ... }` |
| 🟡 建议 | `_get_un_book_time` (末尾截断) | **代码片段不完整**：方法在 `if (empty($this->next_date_room_book_time))` 处中断，无法审查后续逻辑（如次日时间合并、边界处理）。 | 请补充完整代码以便进行闭环审查。当前可见部分已存在多次重复的 `get_one` 查询，建议合并为批量查询。 | *(待补充)* |
---
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **消除模型状态污染**：立即将 `$book_room_id`、`$ignore_tuangou_time_limit`、`$tuangou` 等请求级状态移出 Model 属性。建议创建 `BookingTimeCalculator` 服务类，通过构造函数或方法参数注入上下文。
2. **修复静态缓存键冲突**：`self::$book_days_info` 等静态缓存必须加入参数指纹（如 `md5($merchant_id . $shop_id . $date)`），否则在多门店/多日期并发查询时必现数据串扰。
3. **拆分巨型方法**：`get_book_day_time_info` 是典型“上帝方法”。请按“数据获取 → 规则计算 → 状态过滤 → 结果格式化”四个阶段拆分为独立方法，并补充单元测试。
### 🛠 后续重构与优化方向
- **架构分层**：遵循 `Controller → Service → Model` 分层。Model 仅负责数据库 CRUD 与基础数据映射；时间计算、套餐规则、营业逻辑等复杂业务下沉至 Service 层。
- **性能优化**：
- 将 `_get_un_book_time` 中对前一日、当日、后一日的多次 `get_one` 查询合并为单次 `get_where_in` 批量查询，减少 DB 往返。
- 时间区间计算可考虑引入 `Carbon` 或自定义 `TimeRange` 值对象，替代散落的 `strtotime`/`date`/字符串拼接，提升可读性与准确性。
- **规范与安全**：
- 全面替换魔法值为类常量。
- 对 `$params` 中的 `date`、`merchant_id`、`shop_id` 增加严格类型与格式校验，防御越权与异常输入。
- 若项目运行在 PHP 7.4+，建议为所有方法添加返回类型声明（如 `: array`, `: void`），提升静态分析能力。
> 💡 **提示**：由于提供的代码在 `_get_un_book_time` 方法末尾截断，当前审查主要基于可见逻辑。若需对次日时间合并、跨天清扫逻辑进行深度验证，请补充完整代码片段。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779871075
|
1779871075
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
385
|
21
|
119
|
1
|
|
0
|
🔍 代码审查报告：pay-260519 - 1
|
## 自动代码审查报告
**分支**: pay-260519
**提交**: `66797615c ## 自动代码审查报告
**分支**: pay-260519
**提交**: `66797615c137ce308920c0eec2bce907cd8a1491`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-05-27 16:48:12
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：业务逻辑覆盖全面，时间计算、订单流转、支付回调等核心链路已实现。但代码呈现典型的“上帝类/上帝方法”特征，缺乏分层设计。存在 **SQL注入隐患、弱加密算法、事务嵌套风险、循环性能瓶颈** 及大量硬编码。整体可维护性与安全性需重点提升。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_yc_order_model.php` / `get_bill_goods_info()` | **SQL注入风险**：使用字符串拼接构造查询条件并直接传入 `$this->select()`，未进行参数绑定或转义。若 `$unique_key` 含特殊字符将导致注入或语法错误。 | 使用框架查询构造器链式调用或 `$this->db->escape()` 进行安全转义。 | ```php<br>// 修改前<br>$sql = '_unique_key="' . $unique_key . '" AND ...';<br>$this->select($sql);<br><br>// 修改后<br>$this->db->where('_unique_key', $unique_key);<br>$this->db->where_in('_status', [1, 4]);<br>$this->db->or_where('_pay_platform', 10);<br>$this->db->where('_status', -1);<br>$this->db->where('_timestamp >', time() - 7*86400);<br>$order_data = $this->get();<br>``` |
| 🔴 严重 | `Ahead_yc_order_model.php` / `encode_group_buying_order()` | **弱加密算法**：使用 `md5()` 进行订单签名验证。MD5 已证实存在碰撞漏洞，不适用于安全校验。 | 改用 `hash_hmac('sha256', ...)` 或框架内置的加密组件。 | ```php<br>// 修改后<br>if ($type === "ENCODE") {<br> return hash_hmac('sha256', $order_id, $this->encrypt);<br>} else {<br> return hash_equals(hash_hmac('sha256', $order_id, $this->encrypt), $sign);<br>}<br>``` |
| 🔴 严重 | `Ahead_songs_order_model.php` / `add_songs_order()` & `notify()` | **事务嵌套风险**：外层方法开启事务后调用 `notify()`，而 `notify()` 内部再次调用 `$this->db->trans_start()`。CI3 默认事务计数器机制在复杂分支下易导致部分提交或死锁。 | 将事务边界统一上移至 Service/Controller 层，Model 层仅负责原子数据操作，不主动管理事务生命周期。 | 移除 `notify()` 中的 `trans_start/complete`，由调用方统一控制。若必须保留，需使用 `$this->db->trans_begin()` 配合显式 `trans_commit()`/`trans_rollback()` 并严格校验状态。 |
| 🟠 警告 | 所有文件头部 | **类外全局 `$CI` 引用**：文件顶部直接执行 `$CI = &get_instance();`。在 CLI、定时任务或异步环境下易触发 `Undefined variable`，且每次 `include` 都会执行，增加开销。 | 移除类外引用，改为在构造函数中按需获取，或封装为 `$this->ci` 属性。 | ```php<br>class Ahead_xxx_model extends Simple_model {<br> protected $ci;<br> public function __construct() {<br> parent::__construct();<br> $this->ci =& get_instance();<br> }<br>}<br>``` |
| 🟠 警告 | `Ahead_shop_book_time_info_model.php` / `get_book_day_time_info()` | **循环内高频时间计算**：`date()`, `strtotime()`, `array_intersect` 在 `foreach` 中重复调用，且未缓存中间结果，导致 CPU 占用高。 | 提前计算基准时间戳，将时间转换移至循环外；使用位运算或预计算数组替代重复 `strtotime`。 | 将 `$date_time = strtotime($date);` 提至循环前，循环内使用 `$date_time + $v['time']` 替代重复解析。 |
| 🟠 警告 | 多个文件 | **魔法数字/字符串泛滥**：支付类型 `'1','3','22'`、订单类型 `6,2,4,10`、状态 `-1,1` 等硬编码散落各处，极易引发逻辑遗漏。 | 提取为类常量或独立配置类，统一命名规范。 | ```php<br>class OrderConst {<br> const PAY_WECHAT = '1';<br> const PAY_VIP = '3';<br> const TYPE_SONG_PREBUY = 6;<br>}<br>``` |
| 🟡 建议 | `Ahead_yc_order_model.php` / `get_detail()`, `get_bill_goods_info()` | **方法过长/职责不清**：单个方法超 500 行，混合了数据查询、金额计算、格式化、关联加载。违反单一职责原则(SRP)，难以测试与维护。 | 拆分为 `OrderQueryService`、`BillCalculator`、`OrderFormatter` 等独立组件，Model 仅保留数据访问逻辑。 | 将金额计算逻辑抽离至 `BillCalculator::calculate($orderData)`，返回结构化数组。 |
| 🟡 建议 | 全局静态属性 | **静态缓存污染风险**：`self::$book_days_info` 等静态变量在 PHP-FPM 单次请求中有效，但若部署于 Swoole/Workerman 等常驻内存环境，会导致跨请求数据污染。 | 改为实例属性，或使用请求级缓存（如 `Registry`、`Request` 对象或 `APCu`）。 | `public $book_days_info = [];` 替代 `public static $book_days_info = [];` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复 SQL 注入漏洞**：立即替换 `get_bill_goods_info()` 中的字符串拼接查询，全面使用参数绑定或查询构造器。
2. **替换弱加密算法**：将 `md5` 签名验证升级为 `hash_hmac('sha256')`，并配合 `hash_equals` 防时序攻击。
3. **重构事务管理**：梳理 `add_songs_order` 与 `notify` 的事务边界，确保事务扁平化，避免嵌套导致的数据不一致。
4. **清理类外 `$CI` 引用**：统一改为构造函数注入或按需调用，提升环境兼容性。
### 🛠 后续重构与优化方向
- **架构分层**：当前 Model 承担了过多业务逻辑（时间窗计算、账单聚合、支付路由）。建议引入 **Service 层** 处理复杂业务编排，Model 仅负责 CRUD 与基础查询。
- **常量与配置集中化**：建立 `config/order_types.php` 或 `src/Constants/OrderConst.php`，消除魔法值，提升代码可读性与可维护性。
- **性能优化**：对 `get_book_day_time_info` 中的时间区间计算进行算法优化（如使用区间树或预计算映射表），减少 `array_intersect` 与循环内函数调用。
- **规范对齐**：严格遵循 PSR-12 规范（命名空间、缩进、方法长度、类型声明）。若 `phpci` 为 CodeIgniter 3 的定制分支，建议查阅官方文档确认 `DB_driver` 与事务管理的最佳实践，必要时引入 `PHPStan` 或 `Psalm` 进行静态分析。
- **测试覆盖**：针对时间计算边界（跨天、闰年、营业时段重叠）、支付回调幂等性、事务回滚场景补充单元测试，确保核心链路稳定。
> 💡 **注**：代码结构高度契合 CodeIgniter 3 规范。若 `phpci` 为内部定制框架，请核对 `$this->db->trans_*` 与 `get_instance()` 的生命周期是否与官方文档一致。提供的修复方案均兼容标准 CI3/PHP 7.4+ 环境，可直接参考落地。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1779871692
|
1779871692
|
0
|
0
|
0
|
0
|
Edit
Delete
|