|
562
|
21
|
248
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `a46b34e8e ## 自动代码审查报告
**分支**: pay-260616
**提交**: `a46b34e8e71fd98265df4820d875c94fa41cd9c6`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-05 14:22:37
---
## 1. 审查摘要
- **代码质量评分**：5.5/10 分
- **总体评价**：该 Model 承载了大量核心业务逻辑（套餐查询、VIP折扣计算、跨天时间判断、社区模式过滤、原生SQL拼接等），功能实现较为完整，但存在明显的**安全漏洞**、**逻辑缺陷**与**性能瓶颈**。代码结构臃肿，方法过长，硬编码与历史注释较多，且文件末尾被截断，无法完整评估最后一个方法。整体需进行安全加固与架构重构。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_package_list` / `get_hot_sale_top5` 等多处 | **SQL 注入风险**：多处使用字符串拼接构造原生 SQL，未对 `$shop_name`、`$param['special_merchant_id']` 等外部参数进行转义或参数绑定。 | 1. 优先使用 CI 查询构造器 (`$this->db->like()`, `$this->db->where()`)。<br>2. 若必须用原生 SQL，强制使用 `$this->db->escape()` 或预处理。 | `$sql .= " AND \`shop\`.\`_name\` LIKE '%" . $this->db->escape_like_str($shop_name) . "%'";` |
| 🔴 严重 | `get_package_price_list` / `get_screen_list` 循环内 | **`unset($row)` 无法过滤数组元素**：在 `foreach ($list as &$row)` 中使用 `unset($row)` 仅断开引用变量，**不会从原数组中移除元素**，导致无效套餐仍被返回。 | 改用 `array_filter` 或记录键值后 `unset($list[$key])`。 | `foreach ($list as $key => $row) { if ($book_arrival_time < $order_end_time) { unset($list[$key]); continue; } }` |
| 🟠 警告 | 文件顶部 (第4行) | **全局 `$CI = &get_instance();` 滥用**：在类外部直接调用 `get_instance()`，每次 `include` 该文件都会执行，浪费资源且可能在框架未初始化时报错。 | 移除全局调用。在类内部需要时通过 `$this->ci = &get_instance();` 或直接在方法内按需获取。 | `// 删除顶部 $CI = &get_instance();`<br>`// 在方法内使用：$CI =& get_instance();` |
| 🟠 警告 | `get_package_price_list` / `get_screen_list` | **`array_unshift` 在循环中调用导致 O(N²) 性能损耗**：每次插入推荐商品都会移动整个数组，数据量大时严重拖慢响应。 | 收集推荐与非推荐数据后，使用 `array_merge` 或 `array_reverse` 合并，避免循环内移位。 | `$recommended[] = $row; $normal[] = $row;`<br>`$result['drink'] = array_merge($recommended, $normal);` |
| 🟠 警告 | 全局多处 | **魔法数字与硬编码散落**：`4`, `2`, `10`, `100`, `86400`, `0.01` 等直接参与业务计算，可读性差且难以维护。 | 提取为类常量或配置文件。例如 `const MIN_PRICE_THRESHOLD = 0.01;` `const SECONDS_PER_DAY = 86400;` | `const DISCOUNT_DIVISOR = 100;`<br>`$rate = $db_rate / self::DISCOUNT_DIVISOR;` |
| 🟡 建议 | `get_package_price_list` 折扣计算段 | **折扣率计算逻辑冗余**：连续两次 `/10` (`$goods_discount_rate / 10 / 10`) 意图是转为小数，但易引发误解且精度可能丢失。 | 统一除以 100 转换为小数，或直接在数据库层存储为 `0.95` 格式。 | `$discount_rate = $vip_data['goods_discount_rate'] / 100;` |
| 🟡 建议 | 全局方法命名 | **命名规范不一致**：混用驼峰 (`getPackageInfoByIds`) 与下划线 (`get_package_price_list`)，违反 PSR-12。 | 统一采用下划线命名法（CI 传统）或驼峰法，保持项目级一致。 | `public function get_package_info_by_ids(...)` |
| 🟡 建议 | 全局 | **遗留注释与 TODO 未清理**：`//edit by nan 24.7.1...`、`//todo` 等提交记录残留在代码中，干扰阅读。 | 清理所有版本控制注释，TODO 应录入项目管理工具（如 Jira/Tapd）。 | 移除 `//edit by nan...` 及 `//todo` |
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **立即修复 SQL 注入漏洞**：所有涉及用户输入拼接 SQL 的地方必须替换为查询构造器或参数绑定。这是生产环境最高风险项。
2. **修正数组过滤逻辑**：将 `unset($row)` 替换为 `unset($list[$key])` 或 `array_filter`，否则业务筛选功能形同虚设。
3. **消除循环内 `array_unshift`**：重构推荐商品排序逻辑，避免 O(N²) 时间复杂度，提升高并发下的接口响应速度。
### 🛠 后续重构与优化方向
1. **框架适配说明**：当前代码结构、`$this->load->model()`、`$this->db->query()` 等特征高度符合 **CodeIgniter 3** 规范，而非 `phpci`。若项目确为 `phpci`，请核对框架文档确认模型加载与 DB 驱动调用方式；若为 CI3，建议全面启用 Query Builder 替代原生 SQL。
2. **方法拆分与单一职责**：`get_package_price_list` 与 `get_screen_list` 均超过 150 行，混合了数据查询、VIP计算、社区模式过滤、时间校验、数据格式化。建议拆分为：
- `buildPackageQueryConditions()`
- `calculateVipDiscount()`
- `filterCommunityAvailablePackages()`
- `formatPackageResponse()`
3. **静态缓存风险**：`static public $_shop_id_arr` 在 PHP-FPM 环境下虽随请求销毁，但在 Swoole/Workerman 等常驻内存环境中会导致数据污染。建议改用 CI Cache 驱动 (`$this->cache->save()`) 或 Redis。
4. **代码截断提示**：提供的代码在 `get_book_package_list_group_by_shop` 方法的 `$special_city_id = [2, 3, 4, 5, 34,` 处突然中断。请补充完整代码以便进行后续的分页逻辑、距离排序及边界条件审查。
> 💡 **专家建议**：该 Model 已演变为“上帝类”，承载了过多业务逻辑。建议在后续迭代中引入 **Service 层** 或 **Repository 模式**，将复杂计算、多表关联、第三方坐标转换等逻辑剥离，Model 仅保留数据映射与基础 CRUD，以提升可测试性与长期可维护性。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780640557
|
1780640557
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
563
|
21
|
249
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `8e1dccb85 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `8e1dccb858817ce5df42e311d5c00cefec60d15b`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-05 14:23:09
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该 Model 承载了复杂的套餐查询、价格计算、社区模式校验及微信预订等业务逻辑，功能覆盖较全。但代码存在**严重的 SQL 注入漏洞**、**框架生命周期误用**、**大量重复逻辑**及**数组操作陷阱**。整体架构偏向“过程式堆砌”，未充分利用现代 PHP 与框架的 ORM/Query Builder 特性，可维护性与安全性亟待提升。
- **风险等级**：🔴 高（存在可直接利用的 SQL 注入与逻辑缺陷）
> ⚠️ **局限性说明**：提供的代码在末尾 `$special_city_id = [2, 3, 4, 5, 34,` 处被截断，后续逻辑（如排序缓存、分页处理等）未完整展示。本次审查仅基于已提供部分，建议补充完整文件后复核。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_package_list` / `get_hot_sale_top5` | **SQL 注入漏洞**：直接使用字符串拼接将 `$shop_name`、`$param['special_merchant_id']`、`$city_id` 等外部参数拼入原生 SQL，未做任何转义或绑定。 | 全面替换为框架 Query Builder 或使用 `$this->db->query($sql, $bindings)` 绑定参数。禁止直接拼接用户输入。 | `$this->db->query("... WHERE shop._name LIKE ? AND shop._merchant_id = ?", [$shop_name.'%', (int)$param['special_merchant_id']])` |
| 🔴 严重 | 文件顶部 (第 4-5 行) | **框架生命周期误用**：在类外部直接调用 `$CI = &get_instance();` 并加载模型。此时框架尚未完成初始化，极易导致 `Fatal Error` 或返回空实例。 | 移除顶部全局代码。在类内部方法中按需使用 `$this->load->model()`，或统一在 `__construct()` 中加载。 | `// 删除顶部：<br>$CI = &get_instance();<br>$CI->load->model('Simple_model');` |
| 🟠 警告 | `get_package_price_list` (约第 115 行) | **`unset($row)` 无法移除数组元素**：在 `foreach ($list as &$row)` 中执行 `unset($row)` 仅断开引用，原数组 `$list` 仍保留该元素，导致脏数据返回。 | 改用键值遍历或 `array_filter` 安全过滤。 | `foreach ($list as $key => &$row) {<br> if ($book_arrival_time < $order_end_time) {<br> unset($list[$key]);<br> continue;<br> }<br>}` |
| 🟠 警告 | 多处方法 | **N+1 查询与重复加载模型**：在循环或高频调用方法中反复执行 `$this->load->model()`，且混合使用原生 SQL 与 Query Builder，增加数据库连接开销与内存占用。 | 将模型加载收敛至 `__construct()` 或使用框架的自动加载机制；统一使用 Query Builder 替代原生 SQL。 | `public function __construct() {<br> parent::__construct();<br> $this->load->model(['Ahead_vip_model', 'Ahead_yc_merchant_model']);<br>}` |
| 🟠 警告 | `get_package_price_list` / `get_screen_list` | **魔法数字与硬编码泛滥**：`4`、`2`、`86400`、`10`、`100` 等散落于业务逻辑中，可读性差且易引发计算错误（如折扣率 `/10` 逻辑）。 | 提取为类常量，明确业务语义。 | `const PACKAGE_TYPE_GROUP = 4;<br>const SCREEN_RENEW_TYPE = 4;<br>const SECONDS_PER_DAY = 86400;<br>const DISCOUNT_BASE = 100;` |
| 🟡 建议 | `get_package_price_list` & `get_screen_list` | **逻辑高度重复（DRY 原则违反）**：社区模式时间校验、营业日计算、套餐过滤逻辑在两个方法中几乎完全一致（超 80% 重复）。 | 抽取为私有方法 `filter_community_packages(array $list, array $baseParams)` 统一调用。 | `private function filter_community_packages($list, $params) {<br> // 提取公共校验逻辑<br> return $filtered_list;<br>}` |
| 🟡 建议 | 全局 | **不符合 PSR-12 规范**：类名 `Ahead_room_package_infos_model` 未使用大驼峰；方法参数缺乏类型声明；注释未遵循 PHPDoc 标准。 | 重命名类为 `AheadRoomPackageInfosModel`；补充 `@param`/`@return` 类型；统一使用 4 空格缩进。 | `class AheadRoomPackageInfosModel extends Simple_model {<br> /** @return array */<br> public function getPackagePriceList(array $baseParams, array $params, int $uid = 0): array { ... }<br>}` |
---
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **立即修复 SQL 注入**：所有涉及 `$this->db->query()` 且包含外部参数的语句必须改为参数绑定或 Query Builder 链式调用。这是最高优先级安全项。
2. **移除文件顶部 `$CI` 调用**：避免框架初始化冲突，将依赖加载移至构造函数或方法内部。
3. **修正 `unset($row)` 逻辑缺陷**：改用键值遍历 `unset($list[$key])` 或 `array_filter`，防止返回无效套餐数据导致前端展示异常。
### 🛠 后续重构与优化方向
1. **架构解耦与 DRY 重构**：
- 将 `get_package_price_list` 与 `get_screen_list` 中重复的“社区模式时间过滤”、“营业日计算”、“套餐分类”逻辑抽离为独立的私有方法或 Service 类。
- 建议引入 **Repository 模式** 或 **Query Object 模式**，将复杂的 SQL 拼接与条件组装从 Model 中剥离，提升可测试性。
2. **统一数据访问层**：
- 废弃原生 `$this->db->query()`，全面迁移至框架 Query Builder。利用 `$this->db->like()`, `$this->db->where()`, `$this->db->join()` 等内置方法，自动处理转义与缓存。
- 静态缓存变量 `$_shop_id_arr` 仅在当前请求有效，若需跨请求缓存，建议接入 Redis/Memcached 驱动。
3. **规范与可维护性提升**：
- 严格遵循 PSR-12 命名规范，补充 PHPDoc 类型声明，便于 IDE 静态分析与团队协作。
- 折扣计算逻辑（如 `/10`、`/10`）建议封装为独立的 `PriceCalculator` 工具类，避免浮点数精度丢失（可改用 `bcmath` 扩展或整数分单位计算）。
> 💡 **框架适配提示**：代码特征高度符合 **CodeIgniter 3** 架构。若 `phpci` 为内部定制框架，请确认 `$this->db->query()` 是否支持参数绑定、`$this->load->model()` 的加载机制是否与 CI 一致。建议查阅 `phpci` 官方文档中关于 **Query Builder 安全规范** 与 **模型生命周期** 的说明，以确保最佳实践对齐。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780640589
|
1780640589
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
564
|
21
|
250
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `6ffae9168 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `6ffae9168e5eaa3c60090647f0ecd44a54ca37a9`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-05 14:25:14
---
## 1. 审查摘要
- **代码质量评分**：4/10 分
- **总体评价**：该模型类承载了大量核心业务逻辑，但代码结构臃肿，存在严重的安全隐患（SQL注入）、多处逻辑缺陷（如 `unset` 误用）、性能瓶颈（重复加载模型、未使用查询构建器）以及不符合现代 PHP 规范的编码风格。需进行系统性安全加固与架构重构。
- **风险等级**：🔴 高
- **局限性说明**：提供的代码在 `get_book_package_list_group_by_shop` 方法末尾被截断，部分逻辑（如 `$special_city_id` 数组后续处理）无法完整评估。以下审查基于已提供代码片段。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_package_list` / `get_hot_sale_top5` 等多处 | **SQL 注入漏洞**：直接通过字符串拼接将 `$city_id`、`$shop_name`、`$param['special_merchant_id']` 等外部参数嵌入 SQL 语句，未做任何转义或参数绑定。 | 全面替换为 CI 查询构建器（Query Builder）或使用 `$this->db->query($sql, $bindings)` 进行预处理绑定。 | ```php<br>// 错误<br>$sql .= " AND `shop`.`_name` like '%" . $shop_name . "%'";<br><br>// 正确<br>$this->db->like('shop._name', $shop_name);<br>// 或<br>$this->db->query($sql, [$city_id, $shop_name]);<br>``` |
| 🔴 严重 | `get_package_price_list` / `get_screen_list` | **逻辑缺陷：`unset($row)` 无法移除数组元素**。在 `foreach ($list as &$row)` 中调用 `unset($row)` 仅销毁引用变量，原数组 `$list` 保持不变，导致过滤逻辑失效。 | 改用键值遍历并 `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>``` |
| 🔴 严重 | 文件顶部 (第 5 行) | **全局调用 `$CI = &get_instance();`**：在类外部直接获取 CI 实例破坏封装性，且在 CLI 模式或非标准生命周期下可能引发致命错误。 | 移除全局调用。若需在类内使用，应在方法内部按需获取，或注入为类属性。 | ```php<br>// 移除文件顶部的 $CI = &get_instance();<br>// 类内部按需使用：<br>$CI =& get_instance();<br>$CI->operational_scene = ...;<br>``` |
| 🟠 警告 | 多个方法内部 | **频繁在方法内调用 `$this->load->model()`**：每次请求重复执行模型加载逻辑，增加 I/O 开销，且不符合框架最佳实践。 | 将依赖模型统一移至 `__construct()` 中加载，或配置自动加载。 | ```php<br>public function __construct()<br>{<br> parent::__construct();<br> $this->load->model(['Ahead_vip_model', 'Ahead_yc_merchant_model', ...]);<br>}<br>``` |
| 🟠 警告 | `get_package_price_list` & `get_price_set_detail` | **DRY 原则违反**：会员折扣计算逻辑（`vip_level1_price`、`goods_discount_rate` 等）在多处重复编写，维护成本极高且易产生计算偏差。 | 抽取为私有方法 `_apply_vip_discount($row, $vip_level, $discount_rate)` 统一处理。 | ```php<br>private function _apply_vip_discount(&$item, $level, $rate)<br>{<br> $discount = $rate / 100;<br> if ($level > 0 && $item['discount_status'] == 1) {<br> $item['actual_price'] = $item['vip_price'] * $discount;<br> }<br> $item['actual_price'] = change_number_format($item['actual_price']);<br>}<br>``` |
| 🟠 警告 | `get_book_package_list` | **静态变量缓存失效**：`self::$_shop_id_arr` 在 PHP-FPM 环境下随请求结束销毁，无法实现跨请求缓存，且无并发安全控制。 | 改用框架 Cache 驱动（如 Redis/Memcached）或 CI 内置 `$this->cache->save()`。 | ```php<br>$cache_key = "shop_ids_by_dist_{$city_id}";<br>$shop_id_arr = $this->cache->get($cache_key);<br>if (!$shop_id_arr) {<br> $shop_id_arr = $this->ahead_shop_model->get_id_by_distance(...);<br> $this->cache->save($cache_key, $shop_id_arr, 300);<br>}<br>``` |
| 🟡 建议 | 全局 | **命名与规范不统一**：方法名混用蛇形 (`get_package_price_list`) 与驼峰 (`getPackageInfoByIds`)；缺乏 PHP 7+ 类型声明；魔法数字（如 `4`, `100`, `86400`）散落各处。 | 遵循 PSR-12，统一命名规范；添加参数/返回值类型提示；将业务常量提取为 `const`。 | ```php<br>const PACKAGE_TYPE_GROUP_BUY = 4;<br>const SECONDS_PER_DAY = 86400;<br><br>public function getPackageInfoByIds(array $ids, string $fields = '*', array $exceptWhere = []): array<br>``` |
| 🟡 建议 | `get_package_price_list` | **复杂时间窗口判断耦合**：跨天营业逻辑与 `FIND_IN_SET` 直接拼接在 `$where['where']` 数组中，可读性差且易因框架底层转义机制引发 SQL 语法错误。 | 将时间窗口计算抽离为独立方法，或使用数据库原生时间函数（如 `HOUR()`, `DAYOFWEEK()`）优化查询。 | *(建议重构为独立方法 `_build_time_window_where($params)`)* |
## 3. 总结与行动建议
### 🔑 优先修复项（P0）
1. **彻底修复 SQL 注入**：立即替换所有 `$sql .= "..." . $param . "..."` 的拼接写法，全面启用 CI 查询构建器或参数绑定。这是当前最高危的安全漏洞。
2. **修正 `unset` 逻辑**：将 `foreach` 中的 `unset($row)` 改为 `unset($list[$key])`，确保套餐过滤逻辑按预期执行。
3. **移除全局 `$CI` 实例**：清理文件顶部的 `&get_instance()` 调用，避免潜在的生命周期冲突。
### 🛠 重构与优化方向（P1/P2）
1. **模型依赖集中化**：将散落在各方法中的 `$this->load->model()` 统一收敛至构造函数，降低运行时开销。
2. **逻辑解耦与 DRY**：将会员折扣计算、时间窗口判断、跨天逻辑抽离为私有辅助方法。当前 `get_package_price_list` 方法过长（超 150 行），违反单一职责原则（SRP），建议拆分为 `查询构建`、`数据过滤`、`价格计算` 三个独立步骤。
3. **缓存策略升级**：废弃 PHP 静态变量缓存，接入 Redis 或 CI Cache 驱动，并设置合理的 TTL 与缓存键命名规范。
4. **规范与现代化**：
- 统一方法命名风格（推荐全小写蛇形或驼峰，保持项目一致）。
- 引入 PHP 7+ 类型声明（`int`, `array`, `string`, `bool` 等）提升静态分析能力。
- 清理 `//edit by nan` 等历史注释，改用 Git 提交记录追溯变更。
- 将硬编码的业务规则（如套餐类型 `4`、折扣基数 `100`）定义为类常量。
> 💡 **框架适配提示**：代码结构高度符合 **CodeIgniter 3** 规范。若 `phpci` 为内部定制框架，请重点核对 `$this->db->query()`、`$this->load->model()` 及 `$this->cache` 的底层实现是否与 CI3 一致。建议查阅 `phpci` 官方文档中关于 **查询构建器安全绑定** 与 **多数据库切换 (`set_select_db`)** 的最佳实践，以确保底层驱动兼容性。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780640714
|
1780640714
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
565
|
21
|
251
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `32e0218d7 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `32e0218d795d10c3148394c106ba7f9a3472685e`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-05 14:26:19
---
## 1. 审查摘要
- **代码质量评分**：4/10 分
- **总体评价**：该模型承载了复杂的业务逻辑（套餐查询、VIP折扣、社区模式时间过滤、跨天校验等），但存在大量重复代码与超长方法。核心缺陷在于**严重的 SQL 注入风险**、**数组过滤逻辑失效**以及**时间边界判断脆弱**。未遵循 PSR-12 规范，模型依赖加载方式陈旧，整体可维护性与安全性亟待重构。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_package_list` / `get_hot_sale_top5` | **SQL 注入漏洞**：`$shop_name`、`$special_merchant_id`、`$offset`、`$page_size` 等外部参数未经转义直接拼接入原生 SQL，攻击者可构造恶意输入破坏查询或窃取数据。 | 全面替换为查询构造器（Query Builder）或使用 `$this->db->escape()` / 预处理绑定。 | `$this->db->like('shop._name', $shop_name, 'both');`<br>`$this->db->limit($page_size, $offset);` |
| 🔴 严重 | `get_package_price_list` / `get_screen_list` | **数组过滤失效**：`foreach ($list as &$row) { unset($row); continue; }` 仅解绑了引用变量 `$row`，**并未从原数组 `$list` 中移除元素**，导致无效套餐仍会返回给前端。 | 使用键值遍历或 `array_filter` 正确移除元素。 | `foreach ($list as $key => $row) { if ($book_arrival_time < $order_end_time) { unset($list[$key]); } }` |
| 🟠 警告 | `check_use_package` | **跨天时间判断逻辑脆弱**：`$ltime = $data['_end_time'] - 86400;` 配合 `if ($now_time_str < $data['_start_time'] && $now_time_str > $ltime)` 在夏令时、跨多日或边界分钟时易产生误判，且硬编码 `86400` 缺乏语义。 | 提取为独立的时间区间校验方法，使用 `DateTime` 或标准化秒数比对逻辑，增加单元测试覆盖。 | 建议封装 `isTimeInRange($now, $start, $end, $weekCycle)` 方法，避免散落的 `if/else`。 |
| 🟠 警告 | 全局多处 | **模型频繁加载**：每个方法内部重复调用 `$this->load->model()`，增加文件 I/O 与内存开销，且破坏单一职责。 | 移至 `__construct()` 统一加载，或使用框架的依赖注入容器/懒加载机制。 | `public function __construct() { parent::__construct(); $this->load->model(['Ahead_vip_model', 'Ahead_yc_merchant_model', ...]); }` |
| 🟠 警告 | `get_package_by_fields` | **索引失效与全表扫描**：`FIND_IN_SET('{$businessDay}',_disabled_date) = ''` 会导致数据库无法使用索引，且字符串直接拼接存在隐患。 | 建议将 `_disabled_date` 拆分为独立关联表或使用 JSON 字段+虚拟列索引；若保留，需使用参数绑定。 | `$this->db->where("FIND_IN_SET(?, _disabled_date) = 0", $businessDay);` |
| 🟡 建议 | 文件头部/类定义 | **违反 PSR-12 规范**：类名 `Ahead_room_package_infos_model` 应为大驼峰 `AheadRoomPackageInfosModel`；文件顶部 `$CI = &get_instance();` 属于全局污染。 | 遵循 PSR-12 命名规范，移除文件级 `$CI` 引用，在方法内按需 `$CI = &get_instance();` 或使用框架 DI。 | `class AheadRoomPackageInfosModel extends Simple_model` |
| 🟡 建议 | 多处 | **魔法数字与硬编码**：`4`, `2`, `100`, `0.01`, `86400`, `3` 等散落各处，缺乏业务语义，后期维护成本极高。 | 提取为类常量或配置文件，提升可读性与可配置性。 | `const PACKAGE_TYPE_GROUP_BUY = 4; const DISCOUNT_DIVISOR = 10; const SECONDS_PER_DAY = 86400;` |
| 🟡 建议 | `get_book_package_detail` | **敏感数据未脱敏**：直接返回 `$shop_data['_manager_mobile']`，若接口未做权限控制，将导致商家手机号泄露。 | 在返回前进行掩码处理，或根据调用方权限动态过滤字段。 | `$mobile = $shop_data['_manager_mobile'] ?? '';`<br>`$room_package_infos_data['shop_info']['manager_mobile'] = substr($mobile, 0, 3) . '****' . substr($mobile, -4);` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即修复 SQL 注入**：所有原生 SQL 拼接处必须替换为框架提供的 Query Builder 或预处理语句。这是生产环境的高危漏洞。
2. **修正数组过滤逻辑**：将 `unset($row)` 改为 `unset($list[$key])` 或使用 `array_filter`，否则业务过滤形同虚设。
3. **统一依赖加载**：将分散在各方法中的 `$this->load->model()` 收敛至构造函数，或采用框架推荐的依赖注入方式，降低运行时开销。
### 🛠 后续重构与优化方向
1. **方法拆分与逻辑复用**：
- `get_package_price_list` 与 `get_screen_list` 存在大量重复代码（社区模式时间判断、VIP折扣计算、时间格式化）。建议提取为私有方法：`_applyCommunityTimeFilter()`, `_calculateVipPrice()`, `_formatPackageTime()`。
- 控制单个方法行数在 80 行以内，降低圈复杂度（Cyclomatic Complexity）。
2. **时间处理标准化**：
- 废弃 `date('Ymd')`、`strtotime()` 的散乱调用，统一使用 `DateTime` 或框架内置的时间工具类。
- 跨天套餐校验建议采用区间重叠算法：`(startA <= endB) && (endA >= startB)`，避免硬编码 `86400` 带来的边界错误。
3. **缓存机制升级**：
- `static public $_shop_id_arr` 仅为请求级内存缓存，无过期策略且易引发并发脏读。建议替换为框架的 `Cache` 组件（如 Redis/Memcached），并设置合理的 TTL。
4. **框架适配说明**：
- 代码结构高度类似 **CodeIgniter 3**。若 `phpci` 为 CI3 的定制分支，建议保留 `$this->load->model()` 但移至构造函数；若 `phpci` 已升级至支持 PSR 标准或依赖注入（如 CI4/Laravel 风格），请全面改用构造函数注入或 `model()` 辅助函数。
- 对于不确定的 `phpci` 生命周期钩子或配置加载方式，建议查阅官方文档中关于 `Model` 初始化与 `DB` 驱动绑定的章节。
> ⚠️ **局限性说明**：提供的代码在 `get_book_package_list_group_by_shop` 方法处截断，未能审查完整逻辑。若该方法包含类似的原生 SQL 拼接或复杂分页逻辑，请同步按上述安全与性能规范进行审查。建议补充完整代码或提供对应单元测试用例以便进行更精准的边界验证。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780640780
|
1780640780
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
570
|
21
|
252
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616 🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616' of https://gitea.g-hi.co...
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `3873e7e19 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `3873e7e1964c73f5c58691d2342b4ee078395223`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-05 16:20:09
---
## 📋 审查摘要
- **变更文件数**: 3
- **严重问题**: 2
- **高危问题**: 4
- **中危问题**: 2
- **建议优化**: 2
## 🐛 发现的问题
### <font color="red">[语法错误] 类外部非法调用 get_instance() 导致运行时崩溃风险</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: application/models/Ahead_tuangou_exchange_log_model.php
- **行号**: 2-3
- **问题描述**: 在类定义外部直接执行 `$CI = &get_instance();` 和 `$CI->load->model('Simple_model');`。CodeIgniter 框架在加载模型文件时，核心超级对象（Super Object）可能尚未完全初始化，此时调用 `get_instance()` 极易返回 `null` 或触发致命错误。此外，后续方法内部多次重复调用 `$CI = &get_instance();` 属于冗余代码。
- **修复建议**: 删除文件顶部的这两行代码。CI 模型继承自 `CI_Model`，可直接使用 `$this->load->model()` 或 `$this->db`。若需加载基类，应在 `__construct()` 中处理或依赖 CI 自动加载机制。
### <font color="red">[语法错误] 未定义的变量 $log_update 和 $tuangou_verify_update 直接使用</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: application/models/Ahead_tuangou_exchange_log_model.php
- **行号**: 约 158, 188
- **问题描述**: 在 `_tuangou_exchange` 方法中，直接对 `$log_update['_reward_id']` 和 `$tuangou_verify_update['_result']` 进行数组赋值，但从未初始化这两个变量。在 PHP 7.4+ 或开启严格模式时会抛出 `Warning: Undefined variable`，且不符合现代 PHP 编码规范。
- **修复建议**: 在首次赋值前显式初始化数组：
```php
$log_update = [];
$tuangou_verify_update = [];
```
### <font color="red">[跨文件调用] 调用了未定义的全局函数 throwError 和 get_aliyun_redis_conn</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: application/models/Ahead_tuangou_exchange_log_model.php
- **行号**: 约 10, 68, 120, 200
- **问题描述**: 代码中多次调用 `throwError()` 和 `get_aliyun_redis_conn()`。这两个函数并非 PHP 内置函数，也未在当前文件通过 `require`/`include` 引入，且未声明 `use`。若项目中未通过 Composer 或全局 Helper 注册，将直接导致 `Fatal error: Uncaught Error: Call to undefined function`。
- **修复建议**:
1. 确认函数所在文件路径，在文件头部引入：`require_once APPPATH . 'helpers/custom_helper.php';`（示例）
2. 若为业务异常，建议改用 CI 标准错误处理：`show_error('错误信息');` 或抛出标准异常 `throw new Exception('错误信息');`
### [逻辑 BUG] data 对象存在重复键 operational_scene 导致状态覆盖
- **严重程度**: 高危
- **文件**: web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js
- **行号**: 约 18, 24
- **问题描述**: `Page({ data: { ... } })` 中定义了两次 `operational_scene: ''`。JavaScript 对象字面量中重复的键，后者会静默覆盖前者。这会导致初始化数据混乱，且现代 IDE/ESLint 会报语法警告。
- **修复建议**: 删除重复的键值对，保留一处即可。
### [逻辑 BUG] 支付跳转未校验索引有效性，极易触发空指针崩溃
- **严重程度**: 高危
- **文件**: web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js
- **行号**: 约 108, 113
- **问题描述**: `toPayPage()` 方法中直接访问 `this.data.package_list[this.data.packageIndex].id` 和 `this.data.hour_list[this.data.hourIndex].hour`。初始值 `packageIndex` 和 `hourIndex` 均为 `-1`。若用户未进行任何点击直接触发“下一步”，将抛出 `TypeError: Cannot read properties of undefined`，导致小程序白屏崩溃。
- **修复建议**: 增加前置校验拦截：
```javascript
if (this.data.tabId === 'package' && this.data.packageIndex < 0) {
wx.showToast({ title: '请选择套餐', icon: 'none' });
return;
}
if (this.data.tabId === 'time' && this.data.hourIndex < 0) {
wx.showToast({ title: '请选择时长', icon: 'none' });
return;
}
```
### [安全隐患] URL 参数拼接未进行编码，存在路由解析错误风险
- **严重程度**: 高危
- **文件**: web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js & jump-page.js
- **行号**: 多处 `wx.navigateTo` / `wx.redirectTo`
- **问题描述**: 使用字符串拼接构造路由参数，如 `'&order_id=' + this.data.order_id`。若业务数据中包含 `&`, `=`, `?`, `#` 或中文字符，将导致小程序路由解析截断、参数丢失或注入异常。
- **修复建议**: 使用 `encodeURIComponent()` 包裹动态参数，或使用小程序官方推荐的参数传递规范：
```javascript
url: `/pages/community-reserve/pay/pay?order_id=${encodeURIComponent(this.data.order_id)}&order_type=${encodeURIComponent(this.data.order_type)}`
```
### [代码质量] 通过实例访问类常量不符合 PHP 最佳实践
- **严重程度**: 中危
- **文件**: application/models/Ahead_tuangou_exchange_log_model.php
- **行号**: 约 48, 51, 115, 175
- **问题描述**: 使用 `$tuangou::DOUYINTUANGOU` 和 `$tuangou::MEITUAN` 访问类常量。虽然 PHP 7.0+ 语法允许，但语义上类常量属于类本身而非实例。若 `$tuangou` 变量被意外赋值为非对象类型，将引发解析错误。
- **修复建议**: 统一改为类名直接访问：`Tuangou::DOUYINTUANGOU`、`Tuangou::MEITUAN`、`Tuangou::JUHAISHOP`。
### [代码质量] tuangou_exchange 方法过长且职责混杂
- **严重程度**: 中危
- **文件**: application/models/Ahead_tuangou_exchange_log_model.php
- **行号**: 约 80-230
- **问题描述**: `tuangou_exchange` 方法超过 150 行，混合了参数校验、Redis 读写、多模型动态加载、业务分支判断、数据库事务处理。违反单一职责原则（SRP），导致单元测试困难、后期维护成本极高。
- **修复建议**: 按逻辑拆分为私有方法：
- `_validateExchangeParams()`
- `_fetchAndCacheVoucherInfo()`
- `_processImmediateVerify()`
- `_processDeferredVerify()`
主方法仅负责流程编排。
### [代码质量] 手动构造事件对象调用方法属于脆弱写法
- **严重程度**: 低危
- **文件**: web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js
- **行号**: 约 85
- **问题描述**: `this.onHourTap({ currentTarget: { dataset: { index: 0, item: hourList[0] } } })` 属于 Hack 写法，强依赖小程序底层事件结构。一旦框架升级或事件对象结构变更，代码将失效。
- **修复建议**: 将核心计算逻辑抽离为独立方法 `calculateHourPrice(item)`，在 `onHourTap` 事件回调和初始化逻辑中分别调用。
## ✅ 代码亮点
1. **事务控制严谨**：PHP 模型中正确使用了 `$this->db->trans_start()` 和 `$this->db->trans_complete()`，并在关键失败节点手动 `trans_rollback()`，保证了团购兑换与日志记录的数据一致性。
2. **动态 Tab 渲染逻辑清晰**：JS 文件中根据 `package_list` 和 `hour_list` 的实际数据动态生成 `tab_list`，并自动选中默认项，用户体验设计合理。
3. **Redis 缓存策略合理**：使用独立 Key 前缀 `tuangou_exchange_` 结合用户 UID 存储临时兑换状态，并设置 `3600s` 过期时间，有效防止了并发重复兑换和脏数据堆积。
## 📝 总体建议
本次变更涉及微信小程序前端与 CodeIgniter 后端核心业务逻辑。整体架构符合框架规范，但存在几处**可能导致线上崩溃的严重隐患**（类外部调用 CI 实例、未定义变量、数组索引越界）。建议优先修复红色标记的语法与跨文件引用问题。此外，PHP 模型方法过长，建议后续迭代时采用“策略模式”或“服务类”拆分团购兑换的复杂分支逻辑，以提升代码可测试性与可维护性。前端路由参数务必统一使用 `encodeURIComponent` 进行安全编码。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780647609
|
1780647609
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
572
|
21
|
253
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - bug修复
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `0b4166bc0 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `0b4166bc01ee36582f44e5f6d70e01f503e173f0`
**提交人**: chenjunfeng (developer.jeff.c@gmail.com)
**时间**: 2026-06-05 17:07:17
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：业务链路完整，覆盖了订单创建、支付回调、状态流转及多端推送。但存在**数据库事务缺失、模型重复加载、同步阻塞调用**等架构隐患，部分写法违反 CI 框架生命周期与 PSR-12 规范，需优先修复数据一致性与性能瓶颈。
- **风险等级**：🔴 高（支付回调无事务保护、并发幂等控制薄弱、敏感日志泄露风险）
> 📌 **框架说明**：代码结构呈现典型的 **CodeIgniter 3** 特征（如 `get_instance()`、`$this->load->model()`、`system/` 目录）。若 `phpci` 为基于 CI 的定制框架，请确认其核心加载机制与事务 API 是否一致。以下建议基于 CI3 标准实践。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `pay_call_back` 方法 | 支付回调涉及多表写入（游戏总表、包场表、道具表、统计表）与外部推送，未使用数据库事务。若中途抛出异常或网络超时，将导致**订单状态已更新但关联业务数据丢失**，数据严重不一致。 | 使用 `$this->db->trans_start()` 包裹核心业务逻辑，失败时自动回滚。确保外部推送失败不影响核心账务，或采用补偿机制。 | `$this->db->trans_start();`<br>`// 核心更新与写入逻辑`<br>`if ($this->db->trans_status() === FALSE) { $this->db->trans_rollback(); } else { $this->db->trans_commit(); }` |
| 🔴 严重 | 文件顶部 (第 4-5 行) | `$CI = &get_instance();` 在类外部直接调用。CI 框架在加载模型文件时，超级对象可能尚未完全初始化，易引发 `Fatal Error` 或内存泄漏。 | 移除顶部代码。在 `__construct()` 中初始化依赖，或按需使用 `$this->load->model()`。 | `public function __construct() { parent::__construct(); $this->load->model('Simple_model'); }` |
| 🟠 警告 | `pay_call_back` / `add_data` | 支付回调仅通过 `if ($data['_status'] > 0)` 做幂等判断，但 `get_one` 与 `update` 非原子操作。高并发下可能触发**重复执行后续业务**（如重复推送、重复统计）。 | 依赖条件更新 `WHERE _status = -1` 已具备一定防护，建议补充 **Redis 分布式锁** 或数据库唯一索引，确保回调绝对幂等。 | `if (!$this->update(...)) { return; }`<br>`$lock = Redis::lock("pay_cb:{$order_id}", 5);`<br>`if (!$lock) return;` |
| 🟠 警告 | `push_room_user` / `send_screen` | 循环内同步调用 `send_wx_news_msg()` 与 `curlWebsocketApi()`。微信接口与 WebSocket 响应慢，易导致**请求超时、阻塞主线程、触发频率限制**。 | 改为异步消息队列（如 Redis List / RabbitMQ）处理推送；或使用 `curl_multi` 并发请求。 | `// 将推送任务写入队列`<br>`$this->load->library('queue');`<br>`$this->queue->push('wx_push', $task_data);` |
| 🟠 警告 | 多处方法内 | 频繁在业务方法中调用 `$this->load->model()`。CI 框架每次加载都会解析文件路径并实例化，增加不必要的 I/O 与内存开销。 | 将依赖模型统一移至 `__construct()` 中加载，或配置 `autoload.php` 自动加载。 | `public function __construct() {`<br>` parent::__construct();`<br>` $this->load->model(['ahead_open_room_log_model', 'ahead_family_servers_model', ...]);`<br>`}` |
| 🟡 建议 | `send_screen` (第 118 行) | `json_encode($json_arr, 256)` 使用魔法数字。降低可读性，且未来 PHP 版本可能调整常量值。 | 替换为语义化常量 `JSON_UNESCAPED_UNICODE`。 | `json_encode($json_arr, JSON_UNESCAPED_UNICODE)` |
| 🟡 建议 | `push_room_user` (第 89 行) | `var_export($res, 1)` 直接记录完整返回结构到日志。若 `$res` 包含敏感字段（如 token、用户信息），存在**数据泄露风险**，且日志体积膨胀。 | 仅记录关键状态码或脱敏后的摘要，使用结构化日志格式。 | `do_log("用户{$user['_openid']}推送状态: " . ($res ? 'SUCCESS' : 'FAIL'), 'jh_gift_push');` |
| 🟡 建议 | 类定义 (第 7 行) | 类名 `Ahead_jh_gift_order_model` 使用下划线分隔，不符合 PSR-12 `StudlyCaps` 命名规范。现代 IDE 与自动加载器依赖此规范。 | 重命名为 `AheadJhGiftOrderModel`，并全局同步更新引用路径。 | `class AheadJhGiftOrderModel extends Simple_model` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **支付回调事务化**：立即为 `pay_call_back` 核心逻辑包裹 `$this->db->trans_start()/trans_complete()`，防止账务与业务数据断裂。
2. **移除全局 `$CI` 实例化**：删除文件顶部的 `get_instance()`，改为构造函数或按需加载，避免框架生命周期冲突。
3. **强化幂等控制**：在支付回调入口处增加 Redis 锁或数据库行级锁，杜绝并发回调导致的重复业务执行。
### 🛠 后续重构与优化方向
- **异步化改造**：将微信模板消息推送、WebSocket 屏幕广播、第三方统计上报剥离主流程，接入消息队列（如 `php-resque` 或 `RabbitMQ`），提升接口响应速度与系统吞吐量。
- **模型依赖集中管理**：遵循“依赖注入”思想，在 `__construct` 中统一加载模型，或考虑使用 CI 的 `autoload` 配置，减少运行时开销。
- **安全加固**：支付回调接口需补充 **签名验证（如微信 `sign` 校验）** 与 IP 白名单限制，防止伪造回调请求篡改订单状态。
- **规范对齐**：逐步将类名、方法名迁移至 PSR-12 标准，替换魔法数字/字符串为常量，完善 PHPDoc 类型声明（如 `@param array $params`），提升代码可维护性与静态分析友好度。
> 💡 **提示**：若 `phpci` 框架对事务、队列或模型加载有特定封装（如 `$this->db->transaction()` 或内置异步组件），请优先查阅官方文档替换上述原生 CI 写法。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780650437
|
1780650437
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
574
|
21
|
254
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616 🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616' of https://gitea.g-hi.co...
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `8b1a8920d ## 自动代码审查报告
**分支**: pay-260616
**提交**: `8b1a8920dc3e30d0def3b552c286f0351232bfc7`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-05 17:18:30
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了较为复杂的订单支付、状态流转与多端消息推送逻辑，具备一定的幂等性设计（如状态判断）。但存在明显的架构反模式：严重依赖全局 `$CI` 超对象传递状态、核心资金/订单流程缺失数据库事务、模型层承载过多业务逻辑。整体可维护性、并发安全性及扩展性较弱。
- **风险等级**：🔴 高（支付状态更新与关联数据写入缺乏原子性保障，全局状态污染易引发并发数据错乱）
> 📌 **框架说明**：基于目录结构（`system/`、`application/models/`）、`get_instance()`、`$this->load->model()` 等特征，该项目高度符合 **CodeIgniter 3.x** 规范。若 `phpci` 为内部定制框架，请结合其官方文档对事务、模型加载等建议进行适配。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_jh_gift_order_model.php`<br>`pay_call_back` / `add_data` | 支付回调与订单创建涉及主订单状态更新及多张关联表写入，但**未使用数据库事务**。若中途模型调用失败或抛出异常，将导致订单状态已变更为成功，但业务数据未落库，引发严重资损或客诉。 | 使用 CI 数据库事务包裹核心业务逻辑，确保操作的原子性。失败时自动回滚。 | ```php<br>$this->db->trans_start();<br>// ... 执行 update 及后续 add_data 逻辑 ...<br>if ($this->db->trans_status() === FALSE) {<br> $this->db->trans_rollback();<br> $return_data['code'] = 'FAIL';<br> $return_data['msg'] = '数据写入异常';<br>} else {<br> $this->db->trans_commit();<br>}<br>return $return_data;<br>``` |
| 🔴 严重 | 两文件顶部及多处方法内 | 在文件顶部声明 `$CI = &get_instance();`，并在方法中直接修改 `$CI` 属性（如 `$CI->uid`, `$CI->room_id`, `$CI->operational_scene`）。CI 超对象为全局单例，此做法会导致**请求间状态污染**、并发安全隐患，且完全破坏单元测试可行性。 | 移除文件顶部 `$CI` 声明。业务上下文数据应通过方法参数传递，或封装为独立的 `Context/DTO` 对象。严禁直接读写 `$CI` 属性。 | ```php<br>// ❌ 移除文件顶部<br>$CI = &get_instance();<br><br>// ✅ 方法内使用参数或局部变量<br>public function check_room($merchant_id, $params) {<br> $room_data = $this->get_room_data($merchant_id, $params);<br> // 将上下文数据存入局部数组或返回给调用方<br> return $room_data;<br>}<br>``` |
| 🟠 警告 | `Ahead_jh_gift_order_model.php`<br>`push_room_user` | `explode(',', trim($open_log['_join_customer'], ','))` 当字段为空字符串或仅含逗号时，会生成包含空字符串的数组 `['']`。传入 `where_in` 可能导致 SQL 语法错误或查询全表。 | 使用 `array_filter` 过滤空值，或增加前置非空校验。 | ```php<br>$raw_ids = trim($open_log['_join_customer'], ',');<br>$user_id_arr = array_filter(explode(',', $raw_ids), 'strlen');<br>if (empty($user_id_arr)) return true;<br>``` |
| 🟠 警告 | `Ahead_billiards_model.php`<br>`get_room_page_info` | `$where_str` 数组直接拼接字符串构建 SQL 条件。虽然当前数据源自数据库查询，但若未来逻辑变更引入外部输入，存在 **SQL 注入风险**。且未利用 CI 查询构建器的安全转义机制。 | 优先使用 `$this->db->where()`。若必须使用 `FIND_IN_SET`，请强制类型转换或使用 CI 的 `where()` 闭包。 | ```php<br>$room_id = intval($this->room_data['_id']);<br>$this->db->where("FIND_IN_SET($room_id, _room_ids)");<br>$this->db->where("FIND_IN_SET($week, _week_cycle)");<br>``` |
| 🟠 警告 | 两文件多处 | 方法内部频繁调用 `$this->load->model()`。CI 虽会缓存已加载模型，但重复调用增加解析开销，且破坏依赖注入原则，降低代码可读性。 | 将强依赖模型移至 `__construct()` 统一加载，或配置 CI 自动加载。 | ```php<br>public function __construct() {<br> parent::__construct();<br> $this->load->model(['ahead_family_servers_model', 'ahead_open_room_log_model']);<br>}<br>``` |
| 🟡 建议 | 全局 | 代码风格不符合 PSR-12。大量使用下划线前缀（如 `_order_id`），注释包含个人标记（`add by nan`），部分逻辑分支注释被注释掉（`/*if...*/`），降低可维护性。 | 遵循 PSR-12 规范，统一命名约定（建议驼峰或全局一致），清理过时注释，使用标准 PHPDoc 声明参数与返回类型。 | ```php<br>/**<br> * 支付回调处理<br> * @param string $order_id<br> * @param string $transaction_id<br> * @return array<br> */<br>public function payCallBack(string $order_id, string $transaction_id): array<br>``` |
| 🟡 建议 | `Ahead_billiards_model.php`<br>`check_room_status` | 路由逻辑使用大量硬编码字符串/数字（`'1'`, `'2'`, `'3'` 等）表示页面跳转与业务状态，可读性差，后续新增场景极易出错。 | 使用类常量或枚举（PHP 8.1+）定义业务状态，提升代码自解释能力。 | ```php<br>class Ahead_billiards_model extends Simple_model {<br> const REDIRECT_ORDER_DETAIL = '1';<br> const REDIRECT_SCAN_OPEN = '3';<br> // ...<br>}<br>``` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **补充数据库事务**：所有涉及资金、订单状态变更、多表关联写入的流程（如 `pay_call_back`、`add_data`、`buy_room_package`）必须包裹在 `$this->db->trans_start()` 与 `$this->db->trans_commit()/rollback()` 中。
2. **彻底移除 `$CI` 状态污染**：立即停止在模型中读写 `$CI->xxx` 属性。将上下文数据（如 `merchant_id`, `room_id`, `uid`）通过方法参数显式传递，或封装为独立的 `RequestContext` 类。
3. **修复空值解析隐患**：对 `explode`、`trim` 处理用户/DB 拼接字符串的场景，统一增加 `array_filter` 或 `!empty()` 校验，防止脏数据传入查询构建器。
### 🛠 后续重构与优化方向
- **架构分层**：当前 Model 层过于臃肿（Fat Model），承担了参数校验、价格计算、第三方 API 调用、路由分发等职责。建议引入 **Service 层**，将业务编排逻辑从 Model 中剥离，Model 仅保留数据访问（CRUD）与基础查询。
- **统一异常处理**：当前使用全局 `throwError()` 中断流程。建议逐步过渡到 PHP 原生 `Exception` 或 CI 的 `show_error()`，配合全局异常处理器统一返回 JSON 格式错误码，便于前端对接与日志追踪。
- **性能优化**：
- `get_room_package_list` 中存在大量循环与数组重组，建议对高频调用的配置项（如门店配置、时段价格）引入 Redis 缓存。
- 避免在循环内调用数据库查询或模型方法，尽量使用 `where_in` 批量查询后在内存中映射。
- **规范与测试**：接入 `PHP_CodeSniffer` 强制 PSR-12 检查；为核心支付/订单流程补充 PHPUnit 单元测试，覆盖正常流、幂等重复回调、事务回滚等边界场景。
> ⚠️ **局限性说明**：`Ahead_billiards_model.php` 末尾代码被截断（`get_valid_room_package_coupon` 方法未完成），本次审查仅基于已提供代码片段。若截断部分包含关键支付或状态逻辑，请补充后重新评估。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780651110
|
1780651110
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
576
|
21
|
255
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `acf4d42d5 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `acf4d42d5ad729416889f928a924ceca988c6060`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-05 18:05:57
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该 Model 承载了订单查询、详情组装、账单计算、状态流转等大量核心业务逻辑，功能完整但代码结构臃肿。存在明显的 SQL 拼接隐患、循环内查库（N+1）性能瓶颈、MVC 分层越界（模型直接读 Session）以及多处逻辑断点。整体可维护性较低，需进行架构级重构。
- **风险等级**：🔴 高
> 📌 **框架说明**：根据目录结构（`system/`、`application/models/`、`get_instance()`、`$this->load->model()`）判断，该项目实际基于 **CodeIgniter 3** 架构。若 `phpci` 为内部定制框架，请结合其官方文档对生命周期与组件调用进行适配。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 文件顶部 (1-4行) | 在类外部执行 `$CI = &get_instance();` 并加载模型。CI 框架在文件 `include` 时核心容器尚未初始化，极易引发 `Fatal Error`，且违反框架生命周期。 | 移除顶部过程式代码。模型继承关系应在类定义时声明，依赖模型建议在 `__construct()` 中按需加载。 | `class Ahead_yc_order_model extends CI_Model { public function __construct() { parent::__construct(); } }` |
| 🔴 严重 | `get_detail` 方法 | `$order_data['before_payment'] = ...` 赋值后未合并至最终返回数组 `$data`，导致“转房前需支付金额”字段丢失，前端展示异常。 | 将计算结果直接赋值给 `$order_info` 或 `$data` 数组。 | `$order_info['before_payment'] = $before_order_info_data['_actual_pay'] ?? '';` |
| 🔴 严重 | `get_bill_goods_info` | 直接使用字符串拼接构造 SQL 条件：`$sql = '_unique_key="' . $unique_key . '" ...'`。若 `$unique_key` 来源不可控，将导致 SQL 注入。 | 严格使用 CI 查询构造器（Query Builder）或参数化查询，杜绝手动拼接。 | `$this->db->where('_unique_key', $unique_key)->where_in('_status', [1,4])->get()->result_array();` |
| 🟠 警告 | `get_list` 方法 | 在 `foreach` 循环内动态加载模型并执行 `get_one()` 查询。订单量稍大时将引发严重的 **N+1 查询问题**，拖垮数据库。 | 提前收集所有 `package_id`，使用 `where_in` 批量查询关联图片，再通过 PHP 数组映射回填。 | `$ids = array_column($order_info, 'package_id'); $imgs = $this->db->where_in('_id', $ids)->get('ahead_room_package')->result_array();` |
| 🟠 警告 | `encode_group_buying_order` | 使用 `md5()` 进行签名校验。MD5 已存在碰撞漏洞，且未加盐，易被伪造或重放攻击。 | 改用 `hash_hmac('sha256', ...)` 或 CI 内置的 `Encryption` 库。 | `return hash_equals(hash_hmac('sha256', $order_id, $this->encrypt), $sign);` |
| 🟠 警告 | `get_vip_order` | 模型层直接读取 Session：`$CI->session->{$CI->session_prefix . 'sp_month'}`。严重违反 MVC 分层原则，导致模型强耦合于 HTTP 上下文。 | 将时间过滤条件作为参数传入，或在 Controller 层组装 `$where` 后调用。 | `public function get_vip_order($merchant_id, $vipCardNo, $time_filter = null, ...)` |
| 🟠 警告 | `confirm_receipt` | `$star` 参数默认值为 5，但无任何范围或类型校验。恶意传入负数或超大值将污染评分数据。 | 增加参数过滤与边界校验。 | `$star = in_array($star, range(1, 5), true) ? $star : 5;` |
| 🟡 建议 | 全局/多处 | 存在大量魔术数字（如 `1, 2, 10, 14`）、拼写错误（`ORDRE_WARES_TPE`）、数组语法混用（`array()` 与 `[]`），且方法职责过重（`get_bill_goods_info` 超 300 行）。 | 统一定义为 `const`，修正拼写，遵循 PSR-12。将长方法拆分为 `calculateTotals()`、`mergeGoods()`、`formatBill()` 等私有方法。 | `const ORDER_WARES_TYPE = 2; // 修正拼写` |
| 🟡 建议 | `get_detail` / `get_process` | 使用非标准函数 `throwError('订单不存在')`。CI3 中应使用 `show_error()` 或抛出 `\Exception`。 | 替换为框架标准异常处理或错误响应。 | `if (empty($order_data)) { show_error('订单不存在', 404); }` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复数据丢失 Bug**：立即修正 `get_detail` 中 `$order_data['before_payment']` 未返回的问题。
2. **消除 SQL 注入风险**：将 `get_bill_goods_info` 中的字符串拼接 SQL 全面替换为 CI Query Builder 或预处理语句。
3. **移除类外过程代码**：删除文件顶部的 `$CI = &get_instance();`，确保模型在 CI 生命周期内正确实例化。
4. **解决 N+1 查询**：重构 `get_list` 的关联查询逻辑，采用批量查询（`where_in`）替代循环查库。
### 🛠 后续重构与优化方向
1. **MVC 边界清晰化**：
- 模型仅负责数据存取与基础业务计算，**禁止直接读取 `$_SESSION`、`$_GET`、`$_POST`**。
- 将 `get_bill_goods_info` 中的金额汇总、商品合并、格式化逻辑抽离至独立的 `OrderBillCalculator` 服务类中，遵循单一职责原则（SRP）。
2. **常量与配置集中管理**：
- 将散落的订单状态、支付平台、场景类型等映射关系统一提取至 `config/order_config.php` 或定义为类常量，避免硬编码。
- 修正 `ORDRE_WARES_TPE` 等拼写错误，统一使用 `UPPER_SNAKE_CASE` 命名常量。
3. **安全与加密升级**：
- 废弃 `md5` 签名，全面迁移至 `hash_hmac` 或 CI `Encryption` 库。
- 对金额计算引入 `bcmath` 扩展或严格使用 `number_format` 配合类型转换，避免浮点数精度丢失。
4. **代码规范与可测试性**：
- 严格遵循 PSR-12，统一数组短语法 `[]`，补充方法参数类型声明与返回值类型提示。
- 拆分超长方法后，为核心计算逻辑编写 PHPUnit 单元测试，确保重构不破坏现有业务。
> ⚠️ **局限性提示**：提供的代码在 `get_timing_order` 方法末尾被截断（`return ['success' => false, 'msg' => '订单`）。若该方法涉及关键事务或复杂关联查询，请补充完整代码以便进行二次深度审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780653957
|
1780653957
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
577
|
21
|
256
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 扫续费小程序码相关
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `bd79bc8a5 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `bd79bc8a57343bab78ae642f064c187e8fdb7927`
**提交人**: linyangrui (yangruilin888@gmail.com)
**时间**: 2026-06-05 18:10:41
---
## 📋 审查摘要
- **变更文件数**: 7
- **严重问题**: 3
- **高危问题**: 4
- **中危问题**: 1
- **建议优化**: 2
## 🐛 发现的问题
### <font color="red">[语法错误] JS对象参数闭合错误导致语法解析失败</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: `web/Hi-Zan/Hi-Zan/models/billiards.js`
- **行号**: 约 28-35, 43-50
- **问题描述**: 在 `getRoomPageInfo` 和 `getRoomPackageList` 方法中，`this.request({...})` 调用结束后直接跟了 `error: (err) => {...}`。这属于非法的语法结构，`error:` 会被解析为无意义的标签语句，导致回调函数未正确传入，且破坏了代码结构。
- **修复建议**: 将 `error` 回调移入 `this.request` 的参数对象内，并补充缺失的逗号与括号：
```javascript
this.request({
url: 'hz/Billiards/getRoomPageInfo',
data: { room_id },
success: success,
error: (err) => {
console.log('getRoomPageInfo', err)
}
})
```
### <font color="red">[语法错误] PHP文件内容截断导致语法不完整</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: `application/models/Ahead_yc_order_model.php`
- **行号**: 文件末尾
- **问题描述**: 文件末尾代码 `return array('status' => true, 'msg' => '已绑定了` 被意外截断，缺少闭合括号、分号、方法结束符及类结束符。直接部署将导致 `Parse error: syntax error`。
- **修复建议**: 补全缺失的代码结构：
```php
return array('status' => true, 'msg' => '已绑定成功');
}
}
```
### <font color="red">[语法错误] 未定义的变量导致支付参数缺失</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: `application/models/Ahead_jh_gift_order_model.php`
- **行号**: 约 225-235 (`add_data` 方法内)
- **问题描述**: 在 `else` 分支中定义了变量 `$open_id`，但在后续构造 `$pay_mach_order` 数组时使用了 `$openid`。PHP 会抛出 `Undefined variable $openid` 警告，且支付接口将因缺少 `openid` 参数而失败。
- **修复建议**: 统一变量命名，将 `$open_id` 改为 `$openid`，或在使用处保持一致。
### <font color="red">[跨文件调用] 调用了不存在的模型属性/方法</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `application/models/Ahead_yc_order_model.php`
- **行号**: 约 380 (`get_detail` 方法内)
- **问题描述**: 代码中使用了 `$this->ahead_yc_order_model->get_one(...)`。在当前模型类内部，`$this->ahead_yc_order_model` 并未被加载或定义，直接调用会导致 `Call to a member function get_one() on null` 致命错误。
- **修复建议**: 模型内部查询自身表数据应直接使用 `$this->get_one()`：
```php
$before_order_info_data = $this->get_one(['_id' => $order_info['before_order_id']]);
```
### <font color="red">[跨文件调用] 函数名拼写错误导致未定义函数调用</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `application/models/Ahead_billiards_model.php`
- **行号**: 约 330, 360
- **问题描述**: 代码中调用了 `mintoStr($aviable_minutes)`，但项目中其他位置（如第 310 行）使用的是 `minToStr`。拼写不一致将导致 `Call to undefined function mintoStr()` 致命错误。
- **修复建议**: 全局搜索替换，统一修正为 `minToStr`。
### [安全隐患] 硬编码加密密钥
- **严重程度**: 高危
- **文件**: `application/models/Ahead_yc_order_model.php`
- **行号**: 约 10
- **问题描述**: `public $encrypt = "Vs!Fs7VT";` 将加密/签名密钥硬编码在源码中。一旦代码仓库泄露或反编译，所有依赖该密钥加密的订单数据、团购验证码均可被轻易破解或伪造。
- **修复建议**: 将密钥迁移至配置文件（如 `application/config/config.php`）或环境变量中，通过 `$this->config->item('encrypt_key')` 读取。
### [逻辑BUG] 数据对象中存在重复键名
- **严重程度**: 中危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js`
- **行号**: 约 20, 28
- **问题描述**: `data` 对象中 `operational_scene: ''` 被重复定义了两次。虽然 JS 引擎会以后者覆盖前者，但属于冗余代码，极易在后续维护中引发状态覆盖或逻辑混淆。
- **修复建议**: 删除第 20 行的重复定义，仅保留一处即可。
### [代码质量] 文件作用域直接加载模型违反CI规范
- **严重程度**: 中危
- **文件**: `application/models/Ahead_billiards_model.php`, `Ahead_jh_gift_order_model.php`, `Ahead_tuangou_exchange_log_model.php`, `Ahead_yc_order_model.php`
- **行号**: 各文件第 1-3 行
- **问题描述**: 所有 PHP Model 文件开头均使用了 `$CI = &get_instance(); $CI->load->model('Simple_model');`。在 CodeIgniter 框架中，模型加载应在类构造函数 `__construct()` 中执行，或依赖自动加载。在文件全局作用域调用 `get_instance()` 在 CLI 模式、单元测试或某些异步请求中可能引发 `Undefined variable` 或上下文丢失。
- **修复建议**: 移除文件头部的全局加载代码，在类内部构造函数中规范加载：
```php
public function __construct() {
parent::__construct();
// 若父类未自动处理，可在此处加载依赖
}
```
## ✅ 代码亮点
1. **业务逻辑分层清晰**：前端 JS 将网络请求封装在 `BilliardsModel` 中，页面逻辑与数据请求解耦，符合微信小程序开发规范。
2. **防御性编程意识**：PHP 模型中大量使用了 `??` 空值合并运算符和 `empty()` 判断，有效降低了空指针/未定义索引引发的运行时错误。
3. **状态机设计合理**：`jump-page.js` 根据 `redirect_page` 值进行多分支路由跳转，配合后端 `check_room_status` 的状态计算，形成了完整的扫码开台状态流转闭环。
## 📝 总体建议
1. **严格规范跨文件调用**：本次审查发现多处因拼写错误（`mintoStr`/`minToStr`、`$open_id`/`$openid`）和错误引用自身模型导致的致命问题。建议在 IDE 中开启 `PHPStan` 或 `ESLint` 静态检查，并在提交前运行基础语法校验。
2. **统一框架加载规范**：CodeIgniter 模型文件头部直接调用 `get_instance()` 是历史遗留写法，存在上下文污染风险。建议逐步重构至 `__construct()` 中，提升代码在 CLI/单元测试环境下的兼容性。
3. **敏感信息配置化**：支付密钥、加密串、第三方 API 常量等必须从代码中剥离，统一纳入 `.env` 或 CI 配置文件中管理，避免安全审计不通过。
4. **补充缺失的单元测试**：核心支付与订单状态流转逻辑（如 `get_bill_goods_info`、`buy_room_package`）分支极多，建议针对 `redirect_page` 各状态及支付回调编写自动化测试用例，防止回归 BUG。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780654241
|
1780654241
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
578
|
21
|
257
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `e97c2183b ## 自动代码审查报告
**分支**: pay-260616
**提交**: `e97c2183bfec2c82593345ddcdd5bd506d24b5ac`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 09:50:55
---
## 📋 审查摘要
- **变更文件数**: 5
- **严重问题**: 2
- **高危问题**: 4
- **中危问题**: 2
- **建议优化**: 3
## 🐛 发现的问题
### <font color="red">[语法错误] JS对象属性错位导致语法解析失败</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: `web/Hi-Zan/Hi-Zan/models/billiards.js`
- **行号**: 约 19, 29
- **问题描述**: 在 `getRoomPageInfo` 和 `getRoomPackageList` 方法中，`error:` 回调函数被错误地放置在 `this.request()` 的闭合括号 `)` 之后。这会导致 JavaScript 语法解析错误，或使 `error` 属性被忽略，导致网络请求异常时无法捕获错误。
- **修复建议**: 将 `error` 回调移入 `this.request()` 的参数对象内部。
```javascript
// 错误写法
this.request({ url: '...', data: {...}, success: success, })
error: (err) => { console.log(err) }
// 正确写法
this.request({
url: 'hz/Billiards/getRoomPageInfo',
data: { room_id },
success: success,
error: (err) => {
console.log('getRoomPageInfo', err)
}
})
```
### <font color="red">[语法错误] PHP文件内容截断导致 Unexpected End of File</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: `application/libraries/Neworderservice.php`
- **行号**: 文件末尾
- **问题描述**: 提供的代码在 `$result['have_good` 处突然中断，缺少闭合的 `}`、`;` 以及类结束符。直接部署将导致 `Parse error: syntax error, unexpected end of file`，整个类无法加载。
- **修复建议**: 补全缺失的代码逻辑，并确保类结构完整闭合。检查版本控制或文件传输是否发生截断。
### <font color="red">[跨文件调用] 加载了项目结构中不存在的模型/类</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `application/models/Ahead_shop_config_second_model.php`, `application/libraries/Neworderservice.php`
- **行号**: 多处 (如 `load->model()`, `extends Simple_model`)
- **问题描述**: 根据提供的项目结构，`application/` 目录下未定义任何模型或辅助文件。代码中大量使用了 `$this->load->model()` 加载以下模型，但无法在提供的项目树中验证其存在性。若文件缺失或命名不符合 CI 规范（如 `xxx_model` 对应 `Xxx_model.php`），将直接导致 `Fatal error: Class not found`。
- `Simple_model` (父类)
- `ahead_currency_symbol_model`, `ahead_yc_shop_model`, `ahead_family_servers_model`, `ahead_open_room_log_model`, `ahead_bill_model`, `Ahead_ai_audio_player_content_model`, `ahead_shop_model`, `Ahead_merchant_config_model`, `ahead_shop_config_model`
- `Ahead_vip_level_model`, `Ahead_merchant_goods_model`, `Ahead_goods_price_rooms_model`, `Ahead_wares_package_model`, `Ahead_merchant_gift_rule_model`, `Ahead_wares_package_goods_model`, `ahead_room_package_infos_model`, `Ahead_room_package_model`
- **修复建议**:
1. 确认上述模型文件是否存在于 `application/models/` 目录。
2. 严格遵循 CI 命名规范：模型类名 `Xxx_model` 必须对应文件 `Xxx_model.php`。
3. 若使用自动加载，请确保 `config/autoload.php` 或 `composer.json` 配置正确。
### [逻辑BUG] 业务逻辑中混入调试输出破坏接口响应
- **严重程度**: 高危
- **文件**: `application/libraries/Neworderservice.php`
- **行号**: 约 580
- **问题描述**: 在 `getOrderTypeInfo` 方法的循环中使用了 `echo $vip_upgrade_data_actual_pay;`。该库通常用于构建订单数据并返回 JSON 或数组。`echo` 会直接输出到响应流，破坏 JSON 结构，导致前端解析失败或页面出现乱码。
- **修复建议**: 立即删除或注释掉该 `echo` 语句。如需调试，请使用 `log_message('debug', $vip_upgrade_data_actual_pay);` 或写入日志文件。
### [安全隐患] URL参数拼接未编码可能导致路由解析异常
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/table-tennis/jump-page/jump-page.js`
- **行号**: 约 45, 50, 55, 60, 65, 70, 75, 80
- **问题描述**: 使用 `wx.navigateTo` 跳转时，通过字符串拼接传递参数（如 `room_name`, `shop_name`, `book_room_name`）。若这些字段包含特殊字符（如 `&`, `?`, `=`, `#` 或中文），会截断或破坏 URL 参数结构，导致目标页面获取到错误数据，甚至引发路由劫持。
- **修复建议**: 使用 `encodeURIComponent()` 对动态参数进行编码。
```javascript
// 示例修复
url: `/pages/table-tennis/wrong-room/wrong-room?room_name=${encodeURIComponent(res.result.room_name)}&book_room_name=${encodeURIComponent(res.result.book_room_name)}&shop_name=${encodeURIComponent(res.result.shop_name)}&operational_scene=${result.operational_scene}`
```
### [代码质量] 巨型Switch语句违反单一职责原则
- **严重程度**: 中危
- **文件**: `application/models/Ahead_shop_config_second_model.php`
- **行号**: 约 75 ~ 350
- **问题描述**: `get_shop_setting` 方法包含超过 250 行的 `switch-case` 结构。该方法承担了数据查询、缓存读取、类型转换、业务规则计算（如时间取整、状态映射）等多重职责，可读性差，维护成本极高，且容易引发遗漏 `break` 或逻辑冲突。
- **修复建议**:
1. 将配置映射关系抽离为独立的配置数组或策略类。
2. 使用配置映射表替代 `switch`：`$configMap = ['currency_symbol' => 'handle_currency', ...];`
3. 将复杂计算逻辑（如 `book_time_limit_after_close_room` 的取整）拆分为独立的私有方法。
### [代码质量] 静态变量缓存机制在标准PHP-FPM环境下的局限性
- **严重程度**: 中危
- **文件**: `application/models/Ahead_shop_config_second_model.php`
- **行号**: 约 78, 395, 430
- **问题描述**: 使用 `public static $shop_config;` 进行请求内缓存。在标准的 PHP-FPM/CGI 模式下，每次 HTTP 请求都会重新初始化 PHP 进程，静态变量**无法跨请求共享**。若期望实现跨请求缓存，此写法无效；若仅为单次请求内复用，建议改用类实例属性 `$this->shop_config` 或引入 Redis/Memcached。
- **修复建议**: 明确缓存作用域。若为单次请求内复用，改为 `$this->shop_config[$shop_id]`；若需全局缓存，请接入 CI 的 Cache 驱动（如 `$this->cache->redis->get()`）。
## ✅ 代码亮点
1. **配置集中化管理**：`Ahead_shop_config_second_model.php` 将门店配置字段集中定义在 `$fields` 属性中，便于后续数据库字段变更时统一维护。
2. **场景化配置隔离**：代码通过 `operational_scene` 区分 KTV、台球、棋牌、酒馆等不同业务场景，并动态拼接配置前缀（如 `card_`, `tavern_`），架构设计具备良好的扩展性。
3. **前端模型封装规范**：`billiards.js` 采用 ES6 Class 继承 `HTTP` 基类，接口调用结构清晰，符合微信小程序 MVVM 开发规范。
## 📝 总体建议
1. **优先修复语法与截断问题**：JS 的 `error` 回调错位和 PHP 文件截断属于阻断性错误，必须第一时间修复，否则将直接导致页面白屏或服务崩溃。
2. **严格验证跨文件依赖**：当前提供的项目结构仅包含 `system/` 核心库，缺失 `application/` 业务代码。在合并代码前，务必使用 `grep` 或 IDE 全局搜索确认所有 `load->model()` 和 `extends` 的类文件真实存在且命名符合 CodeIgniter 规范。
3. **重构巨型方法**：`Neworderservice::getOrderTypeInfo` 和 `get_shop_setting` 方法过长，建议按业务边界拆分为 `OrderPriceCalculator`、`ShopConfigResolver` 等独立服务类，提升单元测试覆盖率。
4. **统一错误处理机制**：代码中大量使用 `throwError()` 和全局辅助函数（如 `hourToTime`）。建议统一接入 CI 的异常处理机制或自定义全局 Helper，避免隐式依赖导致运行时 `Call to undefined function` 错误。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780883455
|
1780883455
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
580
|
21
|
258
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `0c33306a5 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `0c33306a576443cf693eb51e81463c241db8896f`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 10:19:38
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该文件承载了核心订单计价与组装逻辑，业务覆盖较广（商品、套餐、会员折扣、服务费、优惠券等）。但代码存在明显的**调试残留、变量覆盖、SQL拼接隐患及浮点数精度风险**。整体结构偏向“过程式堆砌”，缺乏面向对象封装与财务计算规范，可维护性与扩展性较弱。
- **风险等级**：🔴 高（存在直接输出破坏接口结构、关键变量覆盖、潜在SQL注入及金额精度丢失风险）
> 📌 **框架说明**：根据目录结构、`BASEPATH`、`get_instance()` 及 `$this->CI->load->model()` 等特征，本项目实际使用的是 **CodeIgniter 3.x** 框架（非 `phpci`）。以下建议均基于 CI3 最佳实践与 PHP 8+ 兼容规范。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `getOrderTypeInfo()` 方法内 | **调试代码未清理**：循环中存在 `echo $vip_upgrade_data_actual_pay;`，会直接污染 HTTP 响应流，导致 JSON/XML 解析失败或前端白屏。 | 立即删除或替换为框架日志记录。 | `// 删除 echo<br>log_message('debug', 'VIP升级金额: ' . $vip_upgrade_data_actual_pay);` |
| 🔴 严重 | `getOrderTypeInfo()` 约 350 行处 | **关键变量重复赋值覆盖**：`$order['_prime_service_charge']` 被赋值两次，第二次 `$order['_prime_service_charge'] = $service_charge;` 覆盖了首次计算的 `$prime_after_paid_service_charge`，导致服务费逻辑错乱。 | 明确业务意图，若需保留原始值请重命名变量，或修正覆盖逻辑。 | `$order['_prime_service_charge'] = $prime_after_paid_service_charge; // 确认是否误写` |
| 🟠 警告 | `getOrderTypeInfo()` 约 260 行 | **潜在 SQL 注入**：`$pack_goods_where = "wares_package._package_id in (" . implode(",", $id_array['package_id']) . ")";` 直接拼接数组，若 `$id_array` 含用户输入将导致注入。 | 使用 CI 查询构建器或强制类型转换过滤。 | `$ids = array_map('intval', $id_array['package_id']);<br>$this->CI->db->where_in('wares_package._package_id', $ids);` |
| 🟠 警告 | 全局金额计算逻辑 | **浮点数精度丢失风险**：大量使用 `float` 进行金额乘除，配合 `sprintf("%.2f")` 和 `round()`，在复杂折扣叠加时易出现 `0.00999999` 等精度误差。 | 财务计算强制使用 `bcmath` 扩展或统一转为“分”整数计算。 | `$actual = bcmul($price, $quantity, 2);<br>$final = bcadd($actual, $discount, 2);` |
| 🟠 警告 | `_create_insert_infos_data()` 等多处 | **模型重复加载**：`$this->CI->load->model('Ahead_vip_level_model');` 在多个方法中重复调用，CI 虽支持幂等但仍有性能损耗。 | 统一在 `__construct()` 或方法入口处加载一次。 | `// __construct 中<br>$this->CI->load->model(['Ahead_vip_level_model', 'Ahead_merchant_goods_model']);` |
| 🟡 建议 | 类定义与属性 | **违反 PSR-12 与封装原则**：类名 `Neworderservice` 未遵循大驼峰；大量 `public` 属性直接暴露，易被外部意外篡改。 | 类名改为 `NewOrderService`；属性改为 `protected/private`，提供 Getter/Setter。 | `class NewOrderService {<br> protected $roomId = 0;<br> public function setRoomId(int $id): self { $this->roomId = $id; return $this; }<br>}` |
| 🟡 建议 | 全局硬编码 | **魔法数字泛滥**：`-1`, `1`, `100`, `13`, `9999999999999` 等散落在业务逻辑中，可读性与可维护性差。 | 提取为类常量或配置文件枚举。 | `const STATUS_DISABLED = -1;<br>const PAY_PLATFORM_WECHAT = 1;<br>const MAX_REWARD_AMOUNT = 9999999999999;` |
| 🟡 建议 | `getOrderTypeInfo()` switch | **缺少默认分支**：`switch ($type)` 未处理未知订单类型，可能静默返回空数组导致下游报错。 | 补充 `default` 分支并抛出明确异常。 | `default: throwError('不支持的订单类型: ' . $type);` |
| 🟡 建议 | 静态属性调用 | **PHP 8.1+ 废弃语法**：`$this->CI->Ahead_vip_level_model::VIP_LEVEL_DEFAULT_NAME` 通过实例访问静态属性，在 PHP 8.1+ 会触发 `Deprecated` 警告。 | 直接通过类名访问静态属性。 | `count(\Ahead_vip_level_model::VIP_LEVEL_DEFAULT_NAME);` |
---
## 3. 总结与行动建议
### 🔑 优先修复项（P0/P1）
1. **立即移除 `echo` 调试语句**，避免生产环境接口崩溃。
2. **修复 `$order['_prime_service_charge']` 覆盖问题**，核对财务对账逻辑，确保服务费计算链路准确。
3. **修复 SQL 拼接隐患**，对 `$id_array['package_id']` 进行 `intval` 过滤或改用 CI 的 `where_in()`。
4. **统一金额计算精度**，引入 `bcmath` 函数族替代原生浮点运算，防止资损。
### 🛠 后续重构与优化方向
1. **拆分巨型方法**：`getOrderTypeInfo()` 超过 400 行，混合了商品校验、价格计算、优惠券抵扣、服务费核算、订单组装等多个职责。建议按单一职责原则拆分为：
- `validateGoods()`
- `calculateVipPrice()`
- `applyRewards()`
- `assembleOrderData()`
2. **引入策略模式处理订单类型**：当前 `switch` 分支冗长且难以扩展。可定义 `OrderTypeStrategyInterface`，为 `1/13`、`2/4` 等类型创建独立策略类，通过工厂类动态实例化，彻底解耦。
3. **财务计算规范化**：
- 所有金额字段在数据库与内存中统一以 **“分”（整数）** 存储与计算，仅在最终展示时除以 100。
- 折扣率统一使用 `int`（如 `100` 代表 100%），避免 `float` 除法误差。
4. **框架适配优化**：
- 将 `$this->CI->load->model()` 移至构造函数或 CI 的 `autoload.php` 中。
- 全局 `throwError()` 建议替换为标准 PHP 异常 `throw new \InvalidArgumentException('...')` 或自定义业务异常类，便于全局异常处理器统一捕获与日志记录。
5. **代码规范对齐**：使用 `PHP_CodeSniffer` + `PSR-12` 规则集进行自动化格式化，补充 PHPDoc 类型声明（如 `@param array<int> $idArray`），提升 IDE 提示与静态分析能力。
> ⚠️ **局限性说明**：提供的代码在末尾 `$result['have_good` 处被截断，未能审查完整逻辑与返回结构。建议补充完整文件后，可进一步评估数据组装完整性、事务处理机制及异常回滚策略。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780885178
|
1780885178
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
581
|
21
|
259
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 测试
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `94146ff30 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `94146ff30ac29d3d2c0748f9489cf5b00103982d`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 10:44:00
---
## 1. 审查摘要
- **代码质量评分**：4.0 / 10 分
- **总体评价**：该服务类承载了复杂的订单计价、会员折扣、服务费及优惠券抵扣逻辑，业务覆盖较广。但代码存在明显的“面条式”特征，方法过长、职责过重。存在资金计算浮点精度隐患、SQL拼接注入风险、多处逻辑覆盖/复制粘贴错误，且遗留调试代码。整体可维护性与安全性亟待提升。
- **风险等级**：🔴 高（涉及资金计算、SQL安全及核心业务逻辑覆盖）
> 📌 **框架说明**：从目录结构（`system/`、`application/`）、`defined('BASEPATH')`、`get_instance()` 及 `$this->CI->load->model()` 等特征判断，该代码实际基于 **CodeIgniter 3 (CI3)** 架构。若 `phpci` 为内部定制框架，请确认其是否完全兼容 CI3 规范。以下建议以 CI3 最佳实践为准。
> ⚠️ **局限性说明**：提供的代码在末尾被截断（`$result['have_good`），部分完整逻辑（如支付路由、最终落库、事务控制）无法评估，审查仅基于已提供片段。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `getOrderTypeInfo` 方法内 | **SQL 注入风险**：使用 `implode` 直接拼接 `IN` 查询条件，若 `$id_array['package_id']` 含用户输入将导致注入。 | 使用 CI3 Query Builder 的 `where_in()` 或参数绑定，彻底杜绝拼接。 | `$this->CI->db->where_in('_package_id', $id_array['package_id']);`<br>`$query = $this->CI->db->get('wares_package');` |
| 🔴 严重 | 多处金额计算逻辑 | **资金计算精度丢失**：直接使用浮点数乘除（如 `$price * $quantity`）及 `sprintf("%.2f")` 舍入，易产生 `0.1+0.2=0.30000000000000004` 类精度问题，导致财务对账差异。 | 引入 `BCMath` 扩展或统一转为“分”进行整数运算。所有金额计算使用 `bcmul`/`bcadd`/`bcdiv`。 | `$actual_pay = bcmul($price, $quantity, 2);`<br>`$total = bcadd($total, $actual_pay, 2);` |
| 🔴 严重 | 订单组装区块 | **逻辑覆盖与赋值错误**：<br>1. `$order['_prime_service_charge']` 被连续赋值两次，后者覆盖前者。<br>2. `$un_goods_common_amount += $un_goods_vip_amount;` 疑似复制粘贴错误，累加了错误变量。 | 核对业务需求，修正覆盖逻辑；检查累加变量名是否应为 `$un_goods_common_amount` 自身或对应字段。 | `// 修正覆盖<br>$order['_prime_service_charge'] = $prime_after_paid_service_charge;`<br>`// 修正累加<br>$un_goods_common_amount += $un_goods_common_amount; // 或对应正确变量` |
| 🟠 警告 | `getOrderTypeInfo` 循环内 | **调试代码未清理**：循环体内存在 `echo $vip_upgrade_data_actual_pay;`，生产环境会破坏 JSON/HTML 输出或引发 Header 已发送错误。 | 移除 `echo`，替换为 CI3 日志记录或移除。 | `log_message('debug', 'VIP升级计算金额: ' . $vip_upgrade_data_actual_pay);` |
| 🟠 警告 | 多个私有方法内 | **重复加载模型与常量计算**：`$this->CI->load->model()` 及 `count($this->CI->Ahead_vip_level_model::VIP_LEVEL_DEFAULT_NAME)` 在循环/多次调用中重复执行，增加 I/O 与 CPU 开销。 | 将模型加载移至 `__construct()`；将常量计数提取为类属性或静态缓存。 | `// 构造函数中<br>$this->CI->load->model('Ahead_vip_level_model');<br>$this->vipMaxLevel = count($this->CI->Ahead_vip_level_model::VIP_LEVEL_DEFAULT_NAME);` |
| 🟠 警告 | 全局异常处理 | **非标准异常抛出**：使用未定义的 `throwError()` 全局函数，缺乏异常类型区分，且可能暴露敏感堆栈信息。 | 使用 PHP 标准异常或 CI3 `show_error()`，并在控制器层统一捕获处理。 | `throw new \InvalidArgumentException("商品{$val['_goods_name']}已被禁用");` |
| 🟡 建议 | 类定义与属性 | **违反 PSR-12 与封装原则**：类名 `Neworderservice` 未使用大驼峰；大量 `public` 属性暴露内部状态，易被外部意外篡改。 | 类名改为 `NewOrderService`；属性改为 `private/protected`，提供 `getter/setter`。 | `class NewOrderService { private int $roomId = 0; public function getRoomId(): int { return $this->roomId; } }` |
| 🟡 建议 | 全文件 | **魔法数字泛滥**：`100`、`-1`、`1`、`7`、`22` 等硬编码散落在逻辑中，可读性差且难以维护。 | 提取为类常量或枚举，明确业务语义。 | `const DISCOUNT_BASE = 100; const STATUS_DISABLED = -1; const PAY_PLATFORM_OFFLINE = [4, 5, 22];` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **资金安全**：立即将所有涉及金额乘除、累加的逻辑替换为 `BCMath` 函数或整数（分）计算，避免财务资损。
2. **SQL 注入防御**：替换所有 `implode` 拼接的 `IN` 条件，严格使用 CI3 的 `where_in()` 或预处理语句。
3. **逻辑覆盖修复**：重点核对 `$order['_prime_service_charge']` 的重复赋值，以及 `$un_goods_*_amount` 的累加逻辑，确保与财务对账规则一致。
4. **清理生产代码**：移除 `echo` 调试语句，规范异常抛出机制。
### 🛠 后续重构与优化方向
1. **单一职责拆分 (SRP)**：当前 `getOrderTypeInfo` 方法超过 300 行，混合了商品校验、价格策略、会员折扣、服务费计算、优惠券抵扣、订单组装等多个职责。建议拆分为：
- `PriceCalculator`（价格与折扣计算）
- `ServiceChargeCalculator`（服务费计算）
- `OrderAssembler`（订单数据结构组装）
- `GoodsValidator`（商品状态与库存校验）
2. **引入值对象/DTO**：使用 `OrderData`、`GoodsItem` 等 DTO 替代庞大的关联数组，利用类型声明提升 IDE 提示与静态分析能力。
3. **依赖注入替代 `get_instance()`**：若项目允许升级至 PHP 7.4+/8.x 或 CI4，建议通过构造函数注入所需 Model/Config，彻底解耦全局实例，便于单元测试。
4. **配置与魔法值管理**：将折扣基数、支付平台标识、状态码等提取至 `config/order.php` 或枚举类中，实现业务规则与代码逻辑分离。
5. **事务与一致性保障**：订单创建涉及多表写入，建议在最终落库层包裹数据库事务（`$this->CI->db->trans_start()` / `trans_complete()`），确保数据原子性。
> 💡 **备注**：若需对完整订单生命周期（含支付回调、库存扣减、事务回滚）进行深度审查，请提供完整文件及关联的 Model/Controller 代码。当前审查已覆盖核心计价逻辑的安全与性能瓶颈，建议按优先级排期修复。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780886640
|
1780886640
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
582
|
21
|
260
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 测试
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `9c1d7a672 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `9c1d7a67264e303e0f1169f6b169c75da16dfc50`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 10:49:27
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该文件承载了核心订单计价与会员折扣逻辑，业务覆盖全面，但方法过长（违反单一职责原则），存在遗留调试代码、浮点数精度丢失、SQL 拼接隐患及多处冗余赋值。整体可维护性与安全性亟待提升。
- **风险等级**：🔴 高
- **⚠️ 框架说明**：代码中 `BASEPATH`、`get_instance()`、`$this->CI->load->model()` 等特征明确指向 **CodeIgniter 3** 框架。`phpci` 通常为持续集成服务器而非 Web 框架，以下审查基于 CI3 架构规范与 PHP 最佳实践进行。
- **📝 局限性提示**：提供的代码片段在末尾 `$result['have_good` 处截断，未能完整评估方法返回值及后续逻辑，部分建议基于已提供代码推断。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Neworderservice.php` / `getOrderTypeInfo()` 方法内 | **遗留调试输出**：`echo $vip_upgrade_data_actual_pay;` 未删除。在服务类中直接输出会破坏 JSON/XML 响应结构，导致前端解析失败或接口崩溃。 | 立即删除 `echo`，如需记录请改用 CI 日志函数 `log_message('debug', $msg)`。 | `// echo $vip_upgrade_data_actual_pay;`<br>`log_message('debug', 'VIP升级计算: ' . $vip_upgrade_data_actual_pay);` |
| 🔴 严重 | `getOrderTypeInfo()` / 多处金额计算 | **浮点数精度丢失**：使用 `*`、`+` 直接计算金额（如 `$goods_actual_pay = $v[$price_key] * $v['_quantity']`），PHP 浮点数运算存在精度误差，易导致账目不平。 | 财务计算必须使用 `bcmath` 扩展或统一转为“分”进行整数运算。 | `$goods_actual_pay = bcmul($v[$price_key], $v['_quantity'], 2);`<br>`$total = bcadd($total, $goods_actual_pay, 2);` |
| 🟠 警告 | `getOrderTypeInfo()` / 约第 300 行 | **SQL 注入风险**：`$pack_goods_where = "wares_package._package_id in (" . implode(",", $id_array['package_id']) . ")";` 直接拼接数组，若 `$id_array` 含用户输入将引发注入。 | 使用 CI 查询构建器的安全方法 `where_in()`，或强制类型转换。 | `$this->CI->db->where_in('_package_id', array_map('intval', $id_array['package_id']));` |
| 🟠 警告 | `getOrderTypeInfo()` / 末尾区域 | **重复赋值与逻辑覆盖**：<br>1. `$order['_prime_service_charge']` 被赋值两次，第二次覆盖第一次。<br>2. `$result['service_charge'] = $service_charge;` 连续出现两次。<br>3. `$un_goods_vip_present_amount += $un_goods_vip_amount;` 与 `$un_goods_common_amount += $un_goods_vip_amount;` 逻辑存疑。 | 清理冗余代码，明确业务意图。若为笔误需修正；若为累加逻辑需添加注释说明。 | 删除重复行，保留最终计算结果。核对累加逻辑是否符合财务规则。 |
| 🟠 警告 | 全局 / 多处 | **模型频繁加载与重复计算**：在循环或方法内多次调用 `$this->CI->load->model()`；`count($this->CI->Ahead_vip_level_model::VIP_LEVEL_DEFAULT_NAME)` 被多次执行。 | 模型应在 `__construct` 中统一加载；VIP 等级数量应提取为配置常量或缓存。 | `public function __construct() { ... $this->CI->load->model('Ahead_vip_level_model'); }`<br>`const VIP_MAX_LEVEL = 5; // 或从配置读取` |
| 🟡 建议 | 类定义 / 属性声明 | **命名与规范不符 PSR-12**：类名 `Neworderservice` 应为大驼峰 `NewOrderService`；大量魔法数字（`100`, `-1`, `13`, `9999999999999`）散落代码中。 | 重命名类；将业务状态码、折扣基数、最大抵扣额定义为类常量。 | `class NewOrderService`<br>`const DISCOUNT_BASE = 100;`<br>`const MAX_DEDUCT_AMOUNT = 9999999999.99;` |
| 🟡 建议 | `throwError()` 调用处 | **非标准错误处理**：全局函数 `throwError()` 非 CI 原生方法，不利于统一异常捕获与 HTTP 状态码返回。 | 建议改用 `\Exception` 或 CI 的 `show_error()`，并在控制器层统一捕获。 | `throw new \InvalidArgumentException("商品{$name}已售完", 400);` |
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **立即移除 `echo` 调试语句**：这是导致线上接口直接崩溃的致命问题，需在合并前彻底清除。
2. **重构金额计算逻辑**：全面替换浮点数运算为 `bcmath` 函数（`bcmul`, `bcadd`, `bcsub`），确保财务数据绝对精确。
3. **修复 SQL 拼接漏洞**：将 `implode` 拼接的 `IN` 查询替换为 CI Query Builder 的 `where_in()`，并强制输入为整型数组。
4. **清理重复赋值与冗余代码**：核对 `$order['_prime_service_charge']` 与 `$un_goods_*` 累加逻辑，消除无意义覆盖。
### 🛠 后续重构与优化方向
1. **拆分巨型方法（SRP 原则）**：`getOrderTypeInfo()` 超过 400 行，混合了商品校验、价格策略、会员折扣、服务费计算、套餐处理等逻辑。建议拆分为：
- `calculateGoodsPrice()`
- `calculatePackagePrice()`
- `applyVipDiscount()`
- `calculateServiceCharge()`
通过策略模式或工厂模式处理不同订单类型（`1`, `2`, `4`, `13`）。
2. **统一错误处理机制**：废弃全局 `throwError()`，在 Service 层抛出标准异常，在 Controller 层通过 `try-catch` 捕获并返回统一格式的 JSON 响应。
3. **性能优化**：
- 将 `load->model()` 移至构造函数或启用 CI 自动加载。
- 对 VIP 等级配置、店铺配置等高频读取数据使用 CI Cache 驱动（如 Redis/Memcached）缓存，减少 DB 查询。
4. **代码规范化**：
- 严格遵循 PSR-12 命名规范（类名大驼峰、常量全大写）。
- 移除历史注释（如 `//add by nan 22.07.11`），改用 Git 提交记录追溯变更。
- 补充 PHPDoc 类型声明（PHP 7.4+ 支持属性类型，如 `public int $room_id = 0;`）。
> 💡 **提示**：由于代码在末尾截断，建议补充完整方法返回值及后续调用链，以便进一步评估数据流转与事务一致性。如需针对特定业务场景（如并发下单、库存扣减）进行深度审查，可提供完整上下文。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780886967
|
1780886967
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
583
|
21
|
261
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 测试
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `515fcdddd ## 自动代码审查报告
**分支**: pay-260616
**提交**: `515fcddddaf8748b72ba2946de6e4dd0f25be5fa`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 10:55:52
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该类承担了极其复杂的订单计价、会员折扣、优惠券抵扣、服务费计算等核心业务逻辑。整体实现偏向“过程式脚本”，方法过长（God Method），存在浮点数精度丢失、变量意外覆盖、库内直接输出、SQL 拼接隐患等严重问题。代码可维护性较低，缺乏防御性编程与财务计算规范，需进行结构化重构。
- **风险等级**：🔴 高
## 2. 问题详情
*(注：因提供代码片段未带精确行号，以下行号为基于上下文逻辑的相对定位，实际修复时请结合 IDE 搜索定位)*
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `getOrderTypeInfo()` 约第 430 行 | **库文件中直接使用 `echo` 输出变量**。在 API 或 AJAX 请求中会破坏 JSON/XML 响应结构，导致前端解析失败。 | 移除 `echo`，改为使用框架日志记录或写入返回数组中。 | `// 删除该行<br>echo $vip_upgrade_data_actual_pay;` |
| 🔴 严重 | `getOrderTypeInfo()` 约第 500~505 行 | **数组键值被意外覆盖**。`$order['_prime_service_charge']` 先被赋值为 `$prime_after_paid_service_charge`，几行后又被 `$service_charge` 覆盖，导致原始计算值丢失。 | 明确业务语义，删除冗余赋值或重命名键名区分“打折前”与“打折后”。 | `$order['_prime_service_charge'] = $prime_after_paid_service_charge;`<br>`// 删除下方重复赋值：<br>// $order['_prime_service_charge'] = $service_charge;` |
| 🔴 严重 | `getOrderTypeInfo()` 约第 320 行 | **SQL 注入风险**。使用 `implode` 拼接 `IN` 条件字符串并直接传入模型方法，若 `$id_array['package_id']` 未严格校验，将导致 SQL 注入。 | 使用框架 Query Builder 的 `where_in()` 或强制类型转换过滤。 | `$ids = array_map('intval', $id_array['package_id']);`<br>`$this->CI->db->where_in('_package_id', $ids);` |
| 🟠 警告 | 全局多处 | **浮点数直接运算导致金额精度丢失**。PHP 浮点数运算（如 `* 0.95 / 100`）会产生 `0.000000001` 误差，财务场景极易引发对账差异。 | 财务计算统一使用 `bcmath` 扩展或转为“分”整数计算，最终输出时再格式化。 | `$actual = bcmul($price, $qty, 2);`<br>`$discounted = bcdiv($actual, 100, 2);` |
| 🟠 警告 | `getOrderTypeInfo()` 多处 | **频繁在方法内部调用 `$this->CI->load->model()`**。CI/PHP框架中重复加载模型会增加 I/O 与内存开销，且破坏依赖注入原则。 | 将常用模型移至 `__construct()` 中加载，或配置自动加载。 | `public function __construct() {<br> $this->CI =& get_instance();<br> $this->CI->load->model(['Ahead_vip_level_model', 'Ahead_merchant_goods_model']);<br>}` |
| 🟡 建议 | `getOrderTypeInfo()` 约第 380 行 | **数组键未做防御性检查**。直接访问 `$goods_quantity['package'][$v['_id']]`，若键不存在将触发 `Undefined index` 警告并中断逻辑。 | 使用空合并运算符 `??` 或 `isset()` 提供默认值。 | `$qty = $goods_quantity['package'][$v['_id']] ?? 0;`<br>`if ($qty <= 0) continue;` |
| 🟡 建议 | 全局 | **魔法数字与硬编码配置泛滥**。如 `100`, `-1`, `1`, `7`, `13`, `[4, 5, 22]` 等散落在业务逻辑中，可读性与可维护性差。 | 提取为类常量或移至 `config/` 配置文件，使用语义化命名。 | `const VIP_DISCOUNT_BASE = 100;`<br>`const OFFLINE_PAYMENT_METHODS = [4, 5, 22];` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **移除 `echo` 输出**：立即删除 `getOrderTypeInfo()` 循环内的 `echo`，避免污染 HTTP 响应体。
2. **修复变量覆盖逻辑**：核对 `$order['_prime_service_charge']` 的业务定义，保留正确赋值，删除冗余覆盖。
3. **财务计算精度改造**：将所有涉及金额乘除的逻辑替换为 `bcmul()`/`bcdiv()`，或在入库前统一使用 `round($val, 2)` 兜底。
4. **SQL 注入防御**：将 `implode` 拼接的 `IN` 查询改为框架安全的 `where_in()` 或参数绑定。
### 🛠 后续重构与优化方向
1. **拆分巨型方法（SRP 原则）**：`getOrderTypeInfo()` 超过 400 行，混合了商品校验、价格计算、会员逻辑、优惠券抵扣、服务费计算、订单组装等职责。建议拆分为：
- `validateGoodsAndPackages()`
- `calculateBasePrice()`
- `applyVipAndCouponDiscounts()`
- `calculateServiceCharges()`
- `assembleOrderResult()`
2. **统一状态码与配置管理**：将 `_status == -1`、`_discount_status == 1` 等硬编码状态提取为枚举类或常量文件（如 `config/order_status.php`），提升代码自解释能力。
3. **框架适配说明**：代码语法高度符合 **CodeIgniter 3** 规范（`get_instance()`, `load->model()`, `BASEPATH`）。若 `phpci` 为内部定制框架，请确认其是否支持依赖注入容器（DI Container）或 PSR-4 自动加载。若支持，建议逐步将 `get_instance()` 替换为构造函数注入，以提升可测试性。
4. **补充单元测试**：当前计价逻辑分支极多（会员等级、是否跨天、是否免单、是否允许经理打折等）。强烈建议引入 PHPUnit，针对 `getOrderTypeInfo()` 编写覆盖核心分支的测试用例，防止后续迭代引发金额计算回退。
> ⚠️ **局限性提示**：您提供的代码在 `$result['have_good` 处被截断，未能看到方法结尾及后续逻辑。若截断部分包含事务控制（`$this->CI->db->trans_start()`）、异常回滚或最终返回结构，请补充完整代码以便进行事务一致性与数据完整性审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780887352
|
1780887352
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
584
|
21
|
262
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 测试
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `8f7fcdf3c ## 自动代码审查报告
**分支**: pay-260616
**提交**: `8f7fcdf3cba64cda8a8e47ddcc4ca66ab1515c83`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 11:08:34
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该类承担了极其复杂的订单计价、优惠券抵扣、会员等级计算及多业务线（酒水/套餐/开房）路由逻辑。核心业务意图明确，但存在严重的架构设计问题（状态污染、上帝类）、明显的安全隐患（SQL注入拼接）、调试代码残留以及大量硬编码。代码可读性与可维护性较低，且提供的代码片段在末尾被截断，无法进行完整闭环评估。
- **风险等级**：🔴 高
> 📌 **框架说明**：根据 `defined('BASEPATH')`、`get_instance()` 及 `system/` 目录结构判断，该项目实际使用的是 **CodeIgniter 3 (CI3)** 框架。以下审查建议均基于 CI3 架构规范。若确为其他定制框架，请结合官方文档调整。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | ~第 330 行 | **SQL 注入风险**：直接拼接 `IN` 子句 `$pack_goods_where = "wares_package._package_id in (" . implode(",", $id_array['package_id']) . ")";`，未对输入进行转义或参数绑定。若数组含恶意字符串将导致注入。 | 使用 CI3 Query Builder 的 `where_in()` 自动处理转义与类型安全。 | `$this->CI->db->where_in('wares_package._package_id', $id_array['package_id']);` |
| 🔴 严重 | ~第 285 行 | **调试代码未清理**：`echo $vip_upgrade_data_actual_pay;` 直接输出到响应流，会破坏 JSON/XML 结构或页面渲染，且可能泄露敏感金额数据。 | 立即删除，改用 CI 日志系统记录。 | `log_message('debug', 'VIP升级计算: ' . $vip_upgrade_data_actual_pay);` |
| 🟠 警告 | 全文多处 | **模型重复加载**：在 `_create_insert_infos_data`、`_create_insert_wares_data`、`rest_goods_price_by_un_vip` 等方法内部频繁调用 `$this->CI->load->model()`。虽 CI3 支持重复加载，但会产生不必要的 I/O 与内存开销。 | 将依赖模型统一在构造函数中加载，或配置自动加载。 | `public function __construct() { $this->CI =& get_instance(); $this->CI->load->model(['Ahead_vip_level_model', 'Ahead_merchant_goods_model']); }` |
| 🟠 警告 | ~第 1-50 行 | **状态污染与“上帝类”设计**：大量 `public` 属性作为全局状态，方法间隐式依赖，`getOrderTypeInfo` 方法超 300 行且混合多种订单类型逻辑，严重违反单一职责原则(SRP)，极难进行单元测试。 | 将状态封装为私有属性，通过方法参数或 DTO 传递上下文；按订单类型拆分策略类或独立私有方法。 | 使用 `OrderContext` DTO 替代 `$this->vip_data` 等全局状态传递。 |
| 🟠 警告 | ~第 315, 320 行 | **逻辑覆盖/冗余赋值**：`$order['_prime_service_charge']` 被赋值两次（值不同）；`$result['service_charge']` 重复赋值。易导致最终返回数据与预期不符。 | 清理冗余代码，明确业务意图，保留唯一有效赋值。 | 删除重复行，确保 `$order['_prime_service_charge']` 仅赋值一次。 |
| 🟡 建议 | ~第 45, 85 行 | **静态属性访问风险**：`$this->CI->Ahead_vip_level_model::VIP_LEVEL_DEFAULT_NAME` 假设模型存在该静态属性。若模型未定义或 CI 实例化方式不同，将触发 `Fatal Error`。 | 改为通过配置项、常量或模型实例方法获取层级数量。 | `count($this->CI->config->item('vip_levels'))` 或 `$this->CI->Ahead_vip_level_model->get_max_level();` |
| 🟡 建议 | 全文 | **魔法数字泛滥**：`100`, `-1`, `1`, `7`, `13`, `9999999999999` 等硬编码散落在业务逻辑中，可读性差且后期维护极易出错。 | 提取为类常量，增强语义化。 | `const PAY_PLATFORM_WECHAT = 7; const STATUS_DISABLED = -1; const MAX_DEDUCT_AMOUNT = 9999999999999;` |
| 🟡 建议 | ~第 210, 260 行 | **浮点数精度处理不规范**：使用 `sprintf("%.2f", ...)` 进行金额格式化。在 PHP 中处理货币推荐使用 `round()` 或 `bcmath` 扩展，避免精度丢失。 | 统一使用 `round($value, 2, PHP_ROUND_HALF_UP)`。 | `round($goods_price_data['vip_price'] * $discount_goods_reward, 2)` |
| 🟡 建议 | 末尾 | **代码截断**：代码在 `$result['have_good` 处中断，无法审查 `case '2'/'4'` 的完整逻辑、异常捕获机制及最终返回结构。 | 请提供完整文件内容以便进行闭环审查。 | N/A |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题（P0/P1）
1. **立即移除 `echo` 调试代码**：防止生产环境输出污染响应体。
2. **修复 SQL 注入漏洞**：将 `implode` 拼接的 `IN` 查询替换为 CI3 的 `where_in()` 或预处理语句。
3. **清理冗余赋值**：检查 `$order['_prime_service_charge']` 和 `$result['service_charge']` 的重复赋值逻辑，确保财务计算准确。
### 🛠 后续重构与优化方向
1. **架构解耦（核心）**：
- 当前 `Neworderservice` 承担了“数据组装、价格计算、策略路由、状态管理”多重职责。建议采用 **策略模式 (Strategy Pattern)** 将 `case '1'/'13'` 与 `case '2'/'4'` 拆分为独立的 `GoodsOrderCalculator` 和 `RoomPackageCalculator`。
- 移除所有 `public` 状态属性，改为通过构造函数或方法参数注入 `OrderContext`（包含 `vip_data`, `shop_config`, `pay_platform` 等），使类变为**无状态服务**，大幅提升可测试性。
2. **性能优化**：
- 将 `load->model()` 移至构造函数。
- 循环内避免重复调用 `get_instance()` 或加载配置。
- 若 `vip_max_level` 固定，可缓存该值，避免每次循环都 `count()` 静态数组。
3. **规范与安全**：
- 全面替换魔法数字为类常量。
- 使用 `round()` 替代 `sprintf` 处理金额。
- 补充输入校验：在 `getOrderTypeInfo` 入口处对 `$id_array`、`$goods_quantity` 进行类型与边界校验（如 `is_array()`, `array_filter()`）。
- 使用 PHP_CodeSniffer 配置 `PSR-12` 规则集进行自动化格式化，统一命名风格（如 `$vv` → `$packageData`，`$v` → `$item`）。
> 💡 **提示**：由于代码在末尾被截断，若 `case '2'/'4'` 分支中存在类似的 SQL 拼接、状态覆盖或 `echo` 输出，请一并参照上述方案修复。建议提交完整文件后再次进行深度审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780888114
|
1780888114
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
585
|
21
|
263
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 测试
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `289effb71 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `289effb71dd831974f34eac4b88feefa19f22f5d`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 11:11:35
---
## 1. 审查摘要
- **代码质量评分**：4 / 10 分
- **总体评价**：该 Model 承载了极其复杂的订单查询、账单聚合与状态流转逻辑，业务覆盖全面。但实现方式较为粗放，存在**高危 SQL 注入漏洞**、**循环内数据库查询（N+1）**、**缺乏事务控制**等核心缺陷。代码严重偏离 PSR-12 规范，硬编码与魔法数字泛滥，且 Model 层越权承担了视图层的数据格式化工作，可维护性与扩展性较差。
- **风险等级**：🔴 高
## 2. 问题详情
> 注：根据 `$CI = &get_instance()`、`system/` 目录结构及 `load->model()` 等特征，推断项目基于 **CodeIgniter 3** 架构。若 `phpci` 为内部定制框架，请结合其官方文档调整部分建议。
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_bill_goods_info`<br>约第 400 行 | **SQL 注入漏洞**：直接拼接 `$unique_key` 与时间戳到 SQL 字符串中，未使用参数绑定或查询构造器，攻击者可构造恶意参数破坏查询或拖库。 | 全面改用框架 Query Builder 或预处理语句，禁止手动拼接 SQL 条件。 | `$this->db->where('_unique_key', $unique_key)->where('_timestamp >', time()-7*86400)->get();` |
| 🔴 严重 | `confirm_receipt`<br>约第 330 行 | **缺乏数据库事务**：连续执行两次 `insert`（确认收货+订单完成），若第二次失败或进程中断，将导致订单状态不一致（已确认但未完成）。 | 使用数据库事务包裹连续写操作，失败时自动回滚。 | `$this->db->trans_start();`<br>`$this->ahead_yc_order_process_model->insert($data1);`<br>`$this->ahead_yc_order_process_model->insert($data2);`<br>`$this->db->trans_complete();` |
| 🔴 严重 | `get_detail`<br>约第 210 行 | **逻辑漏洞/死代码**：计算了 `$order_data['before_payment']`，但该变量从未合并至返回数组 `$data` 中，导致前端无法获取转房前支付金额。 | 将计算结果正确赋值给 `$order_info` 或 `$data` 数组。 | `$order_info['before_payment'] = $before_order_info_data['_actual_pay'] ?? '';` |
| 🟠 警告 | `get_list`<br>约第 115 行 | **N+1 查询与循环内加载模型**：在 `foreach` 中动态 `load->model()` 并执行 `get_one()`，导致订单列表每多一条就增加一次 DB 请求，性能随数据量线性衰减。 | 提前批量查询关联数据（使用 `where_in`），或使用 `JOIN` 一次性获取，移除循环内的模型加载与查询。 | `$ids = array_column($order_info, 'package_id');`<br>`$imgs = $this->db->where_in('_id', $ids)->get('ahead_room_package')->result_array();`<br>`// 内存中映射匹配` |
| 🟠 警告 | 文件顶部<br>第 3-4 行 | **全局实例化 CI 对象**：`$CI = &get_instance();` 放在类外部，违反框架生命周期，在 CLI 或并发请求下易引发上下文污染或内存泄漏。 | 移除全局 `$CI`，在类内部通过 `$this->load->model()` 按需加载，或在 `__construct()` 中初始化。 | `// 删除顶部两行，改为方法内调用或构造函数加载` |
| 🟠 警告 | `encode_group_buying_order`<br>约第 560 行 | **弱签名算法**：使用 `md5` 进行签名校验，MD5 已不推荐用于安全场景，且未防重放攻击。 | 改用 `hash_hmac('sha256', ...)`，并建议加入时间戳与 nonce 防重放。 | `return hash_hmac('sha256', $order_id, $this->encrypt);` |
| 🟡 建议 | 全局 | **严重违反 PSR-12 规范**：命名混乱（`$pay_id_arr` vs `ORDER_PAY_PLATFORM_ARR`）、无类型声明、方法超长（`get_bill_goods_info` 超 300 行）、魔法数字/硬编码泛滥。 | 统一使用类常量或独立配置类；添加 PHP 7+ 类型提示；拆分大方法；严格遵循 PSR-12。 | `public function get_list(array $where, int $page, int $pageSize): array` |
| 🟡 建议 | `get_bill_goods_info`<br>全方法 | **职责越界**：Model 层处理了大量视图层逻辑（如 `number_format`、折扣字符串拼接、前端展示字段组装）。 | 遵循单一职责原则，Model 仅返回原始数据，格式化逻辑移至 Service 层或 View 层。 | 提取 `formatBillDisplayData(array $rawData): array` 独立处理展示逻辑。 |
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **立即修复 SQL 注入**：将 `get_bill_goods_info` 中的字符串拼接 SQL 全部替换为框架查询构造器（Query Builder）或预处理语句。
2. **补充事务控制**：在 `confirm_receipt`、`close_room_after`、`bindingOrder` 等涉及多表写入或状态流转的方法中，强制使用 `$this->db->trans_start()` / `trans_complete()`。
3. **修复数据丢失 Bug**：修正 `get_detail` 中 `$order_data['before_payment']` 未返回的问题，确保接口契约完整。
### 🛠 后续重构与优化方向
1. **性能优化（消除 N+1）**：
- 将 `get_list` 中的循环查询改为 `JOIN` 或 `where_in` 批量查询。
- 对高频调用的关联模型（如 `ahead_yc_order_extension_model`、`ahead_yc_order_infos_model`）考虑引入缓存或预加载机制。
2. **架构解耦**：
- **拆分巨型方法**：`get_bill_goods_info` 逻辑过于臃肿，建议按业务拆分为 `fetchRawBillData()`、`calculateBillTotals()`、`mergeGoodsDetails()` 等独立方法。
- **配置集中化**：将 `$pay_id_arr`、`$type_arr` 等硬编码数组迁移至 `config/order.php` 或独立的 `OrderConfig` 类，避免 Model 类体积膨胀。
3. **规范与安全升级**：
- 全面启用 PHP 7.4+ 类型声明（参数类型、返回值类型、属性类型）。
- 移除 `$CI = &get_instance();` 全局调用，改用依赖注入或框架标准加载方式。
- 敏感配置（如 `$encrypt`）应移至环境变量或加密配置文件中，禁止硬编码在业务类中。
### ⚠️ 局限性说明
- 提供的代码在 `get_timing_order` 方法末尾被截断，无法评估该方法的完整逻辑与潜在缺陷。
- 未提供 `Simple_model` 基类实现，部分底层查询（如 `$this->select()`、`$this->get_one()`）的具体行为依赖基类封装，若基类未做安全过滤，上述 SQL 注入风险可能进一步放大。
- 若 `phpci` 框架对事务、查询构造器或模型加载有特定封装规范，请以官方文档为准进行适配。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780888295
|
1780888295
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
588
|
21
|
264
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 测试
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `dad66f9f1 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `dad66f9f1363ff3183644f193fc203c25afc4c7a`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 14:37:09
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：该 Model 承载了较复杂的套餐查询、VIP折扣计算、多端适配（触屏/微信预定）等业务逻辑。整体功能完整，但存在**严重的 SQL 注入风险**、**类外部执行代码破坏框架生命周期**、**多处逻辑隐患与性能瓶颈**。代码风格未遵循 PSR-12，魔法数字与硬编码较多，且存在明显的 DRY 原则违背。
- **风险等级**：🔴 高（主要源于未过滤的 SQL 拼接与框架生命周期冲突）
> 📌 **框架说明**：根据目录结构（`system/`、`application/models/`）及 `$this->load->model()`、`$this->db->query()` 等特征，推断项目基于 **CodeIgniter 3.x** 架构。若确为自研 `phpci` 框架，请结合其官方文档对生命周期与模型加载机制进行适配调整。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 顶部全局 / 第 4-5 行 | 在类外部直接调用 `get_instance()` 并加载模型。CI 框架在自动加载模型时会解析文件，顶部执行代码会导致重复实例化、全局变量污染或 Fatal Error。 | 移除顶部代码，将依赖加载移至构造函数或按需加载。 | ```php<br>public function __construct()<br>{<br> parent::__construct();<br> $this->load->model('Simple_model');<br>}<br>``` |
| 🔴 严重 | `get_book_package_list` / `get_hot_sale_top5` | 原生 SQL 直接拼接用户输入（`$shop_name`、`$param['special_merchant_id']`、`$shop_id`），未使用参数绑定或查询构造器，存在 **SQL 注入** 风险。 | 使用 CI 查询构造器（Query Builder）或 `$this->db->query($sql, $binds)` 进行预处理。 | ```php<br>$sql .= " AND `shop`.`_name` LIKE ?";<br>$binds[] = "%{$shop_name}%";<br>// 执行时：<br>$data = $this->db->query($sql, $binds)->result_array();<br>``` |
| 🟠 警告 | `get_package_price_list` / `foreach` 循环 | 使用 `unset($row)` 试图移除数组元素。在 `foreach ($list as &$row)` 中，`unset($row)` 仅销毁引用，**不会从原数组中删除元素**，导致无效数据仍被返回。 | 使用键值遍历或 `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>``` |
| 🟠 警告 | `get_package_price_list` / 折扣计算 | `$goods_discount_rate = $goods_discount_rate / 10; $goods_discount_rate_dis = $goods_discount_rate / 10;` 连续除以 10 逻辑晦涩，且与 `vip_level_1_discount_rate` 计算重复，易引发精度丢失或业务误解。 | 封装折扣转换方法，明确除以 100 的业务意图，避免魔法运算。 | ```php<br>protected function convertDiscountRate(int $rate): float<br>{<br> return $rate / 100.0; // 明确将 95 转为 0.95<br>}<br>``` |
| 🟠 警告 | `get_package_price_list` / 分类逻辑 | 循环内频繁调用 `array_unshift($result['drink'], $row)`。该操作时间复杂度为 `O(N)`，嵌套在循环中导致整体 `O(N²)`，数据量大时严重拖慢响应。 | 分离推荐与普通数组，循环结束后使用 `array_merge` 合并。 | ```php<br>$drink_rec = []; $drink_norm = [];<br>foreach ($list as $row) {<br> if ($row['package_type'] == 2) {<br> $row['recommend'] > 0 ? $drink_rec[] = $row : $drink_norm[] = $row;<br> }<br>}<br>$result['drink'] = array_merge($drink_rec, $drink_norm);<br>``` |
| 🟠 警告 | 全局静态变量 | `static public $_shop_id_arr = [];` 等静态缓存。在 PHP-FPM 环境下虽会随请求重置，但若未来迁移至 Swoole/Workerman 等常驻内存环境，将导致**数据跨请求污染**。 | 改用 CI Cache 驱动或请求级上下文存储，避免静态变量。 | ```php<br>$this->load->driver('cache');<br>$cache_key = "shop_ids_{$city_id}_{$lat}_{$lon}";<br>$shop_id_arr = $this->cache->get($cache_key) ?: $this->ahead_shop_model->get_id_by_distance(...);<br>``` |
| 🟡 建议 | 多处方法内部 | 频繁在业务方法中调用 `$this->load->model()`。CI 模型加载有开销，重复调用降低性能且破坏单一职责。 | 统一在 `__construct()` 中加载，或配置 `config/autoload.php` 自动加载。 | ```php<br>public function __construct()<br>{<br> parent::__construct();<br> $this->load->model(['Ahead_vip_model', 'Ahead_vip_level_model', 'ahead_room_package_model']);<br>}<br>``` |
| 🟡 建议 | 全局 | 未遵循 PSR-12 规范：缺乏严格类型声明、参数/返回值类型缺失、命名风格不统一（如 `$baseParams` 与 `$params` 混用）、注释含个人署名与日期。 | 添加 `declare(strict_types=1);`，补充类型提示，清理冗余注释，统一命名规范。 | ```php<br>declare(strict_types=1);<br>class Ahead_room_package_infos_model extends Simple_model<br>{<br> public function get_package_price_list(array $baseParams, array $params, int $uid = 0): array<br> { ... }<br>}<br>``` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即修复 SQL 注入漏洞**：`get_book_package_list` 与 `get_hot_sale_top5` 中的原生 SQL 拼接必须替换为参数绑定或 Query Builder。这是生产环境的高危红线。
2. **移除类外部执行代码**：删除文件顶部的 `$CI = &get_instance();` 及模型加载语句，严格遵循 CI 模型生命周期规范，避免框架初始化异常。
3. **修正数组移除逻辑**：将 `unset($row)` 替换为 `unset($list[$key])`，否则过滤逻辑形同虚设，可能导致前端展示异常套餐。
### 🛠 后续重构与优化方向
1. **折扣与价格计算抽离**：当前 `get_package_price_list` 与 `get_price_set_detail` 中存在大量重复的 VIP 等级价格计算、折扣率转换逻辑。建议提取为独立的 `PriceCalculator` 服务类或 Trait，实现单一职责与高内聚。
2. **消除 N+1 查询与循环加载**：多处使用 `foreach` 循环内 `load->model()` 或 `get_one()`。可考虑使用 `WHERE IN` 批量查询后在 PHP 层映射，或引入 CI 的 `db->query()` 预加载关联数据。
3. **规范化配置与常量管理**：将 `SCREEN_RENEW_TYPE`、`SCREEN_NEW_TYPE`、折扣除数、业务场景标识（`'3' => 'card_'`）等魔法值统一收敛至配置文件或类常量，提升可维护性。
4. **类型安全与静态分析**：逐步补充 `declare(strict_types=1)`、参数类型声明及 PHPDoc 规范。可引入 `PHPStan` 或 `Psalm` 进行静态扫描，提前拦截类型错误与未定义变量访问（如 `$flavors_data[$fvv[0]]` 未判空）。
> ⚠️ **局限性说明**：提供的代码在 `get_book_package_list_group_by_shop` 方法处被截断，该方法的完整逻辑、分页处理及排序分支未能纳入本次审查。建议补充完整代码后再次进行针对性评估。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780900629
|
1780900629
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
589
|
21
|
265
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 卡券续费可用时间为0的bug
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `e7d1ca4a8 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `e7d1ca4a8958a09bd6437965fbb58da98fdab24f`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 14:39:09
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：业务逻辑覆盖较全面，数据关联与分页处理基本合理。但存在**高危 SQL 注入漏洞**、**引用遍历删除元素失效**等严重逻辑缺陷，且多处价格计算逻辑高度重复，未遵循 DRY 原则。代码风格偏向传统 CI3 写法，缺乏类型约束与异常保护机制。
- **风险等级**：🔴 高
> 📌 **框架说明**：代码结构（`get_instance()`、`$this->load->model()`、`system/` 目录等）高度符合 **CodeIgniter 3** 规范。若实际运行环境确为 `phpci`，请确认底层是否完全兼容 CI3 的 Loader 与 DB 组件。以下审查基于 CI3/PHP 通用最佳实践。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_book_package_list` / `get_hot_sale_top5` | **SQL 注入漏洞**：直接拼接 `$shop_name`、`$param['special_merchant_id']` 等外部参数到原生 SQL 中，未做转义或参数绑定。 | 使用 CI Query Builder 或 `$this->db->escape()` / `$this->db->escape_like_str()` 处理动态参数。 | `$shop_name = $this->db->escape_like_str($shop_name);`<br>`$sql .= " AND shop._name LIKE '%{$shop_name}%'";` |
| 🔴 严重 | `get_package_price_list` / `get_screen_list` | **引用遍历删除失效**：`foreach ($list as &$row) { unset($row); continue; }` 仅断开引用，**不会从原数组中移除元素**，导致脏数据返回。 | 改用键值遍历并直接操作原数组，或使用 `array_filter`。 | `foreach ($list as $key => &$row) {`<br>` if ($book_arrival_time < $order_end_time) {`<br>` unset($list[$key]);`<br>` continue;`<br>` }`<br>`}` |
| 🔴 严重 | `get_package_price_list` / `get_screen_list` | **原始 SQL 条件拼接**：`$where['where'] = ["((info._start_time <= $time ..."]` 直接插值，若 `$businessDay` 等来源不可控，易引发注入或语法错误。 | 使用框架提供的 `where()` 方法配合转义，或至少使用 `$this->db->escape()`。 | `$escaped_day = $this->db->escape($businessDay);`<br>`$where['where'] = ["FIND_IN_SET({$escaped_day}, _disabled_date) = ''"];` |
| 🟠 警告 | `get_package_by_fields` / `get_book_package_detail` | **模型状态未安全恢复**：`$this->set_table_name()` 修改了内部表名，若中间抛出异常，后续查询将使用错误的表名。 | 使用 `try-finally` 确保状态回滚，或避免在方法内修改全局状态。 | `try {`<br>` $this->set_table_name($table_name . ' info');`<br>` $result = $this->select(...);`<br>`} finally {`<br>` $this->set_table_name($table_name);`<br>`}` |
| 🟠 警告 | 全局多处 | **重复的价格/折扣计算逻辑**：`get_package_price_list`、`get_price_set_detail` 中会员折扣、VIP 价格计算代码几乎完全一致，维护成本高。 | 抽取为私有方法 `calculate_vip_price($row, $vip_level, $discount_rate)` 统一调用。 | `private function apply_discount($price, $rate, $status) {`<br>` return $status == 1 && $rate < 10 ? $price * ($rate / 100) : $price;`<br>`}` |
| 🟠 警告 | `get_package_price_list` / `get_screen_list` | **直接修改 CI 实例属性**：`$CI->operational_scene = ...` 破坏了框架封装性，易引发全局状态污染或并发冲突。 | 改用 `$this->config->set_item()`、Session 或通过方法参数显式传递上下文。 | `$this->config->set_item('operational_scene', $book_order['_operational_scene']);` |
| 🟡 建议 | `get_package_price_list` | **浮点数直接比较**：`$row['vip_level1_price']<0.01` 在货币计算中可能因精度丢失导致误判。 | 使用 `bccomp()` 或先 `round($val, 2)` 再比较。 | `if (bccomp((string)$row['vip_level1_price'], '0.01', 2) < 0) { ... }` |
| 🟡 建议 | `get_screen_list` | **数组越界风险**：`$res[($v['package_type'] - 1)]['data'][] = $v;` 假设 `package_type` 仅为 1/2/3，若数据异常将触发 Warning 或覆盖数据。 | 增加边界校验或使用 `switch` 映射，避免硬编码索引。 | `$idx = $v['package_type'] - 1;`<br>`if (isset($res[$idx])) $res[$idx]['data'][] = $v;` |
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **彻底修复 SQL 注入**：所有原生 SQL 拼接处必须替换为 Query Builder 或严格转义。特别是 `get_book_package_list` 和 `get_hot_sale_top5` 中的 `$shop_name` 和 `$param['special_merchant_id']`。
2. **修正 `unset` 逻辑缺陷**：立即将 `foreach ($list as &$row) { unset($row); }` 改为基于键的删除 `unset($list[$key])`，否则过滤逻辑完全失效。
3. **安全恢复模型状态**：为所有调用 `set_table_name()` 或 `set_select_db()` 的方法包裹 `try-finally`，防止异常导致后续请求串表或串库。
### 🛠 后续重构与优化方向
- **逻辑抽象与 DRY 原则**：将会员折扣计算、价格格式化、节假日价格重置等重复代码提取为 `private` 辅助方法或 Trait，降低维护成本。
- **统一数据访问层**：逐步淘汰原生 `$this->db->query($sql)`，全面转向 CI Query Builder。不仅提升安全性，还能自动处理表前缀、字段转义与驱动兼容。
- **类型声明与 PSR-12 规范**：为方法参数与返回值添加 PHP 7+ 类型提示（如 `array $ids`, `int $type`），统一缩进、空格与命名规范，提升 IDE 静态分析能力。
- **上下文传递规范化**：停止通过 `$CI->xxx` 动态挂载属性传递业务状态。建议采用依赖注入、配置项或显式参数传递，确保代码可测试、可追踪。
> ⚠️ **局限性说明**：提供的代码在 `get_book_package_list_group_by_shop` 方法末尾被截断（`$special_city_id = [2, 3, 4, 5, 34,`）。若后续逻辑包含更多原生 SQL 或状态切换，请同步补充审查。建议结合单元测试覆盖核心价格计算与过滤分支，确保重构后业务一致性。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780900749
|
1780900749
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
591
|
21
|
266
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 开房订单的_pay_scene
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `2a1f2efae ## 自动代码审查报告
**分支**: pay-260616
**提交**: `2a1f2efae31851de48454495f62b34c05820be12`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 15:17:46
---
## 1. 审查摘要
- **代码质量评分**：6.0 / 10 分
- **总体评价**：业务链路完整，覆盖了订单校验、支付路由、套餐计算等核心场景。但存在明显的**框架反模式**（如动态修改 CI 超对象属性、文件级 `get_instance()`）、**支付逻辑高度重复**、**魔法值泛滥**及**方法过长**等问题。整体可维护性与扩展性较弱，存在并发状态污染与潜在的安全隐患。
- **风险等级**：🔴 高
> 📌 **框架说明**：根据代码特征（`BASEPATH`、`FCPATH`、`$this->load->model()`、`system/` 目录结构等），当前项目实际基于 **CodeIgniter 3** 架构。若确为内部定制版 `phpci`，请结合官方文档核对生命周期与组件加载机制。以下审查基于 CI3 最佳实践给出。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_billiards_model.php` 顶部 | 在类外部直接执行 `$CI = &get_instance();`。文件被 `include` 时会立即触发，若 CI 核心未完全初始化将导致 `Fatal Error`，且破坏单例生命周期。 | 移除文件顶部代码，改为在类方法内部按需获取，或通过构造函数注入。 | `// 删除顶部代码<br>public function __construct() { parent::__construct(); $this->ci =& get_instance(); }` |
| 🔴 严重 | `Order.php` 多处 | 通过 `$CI->room_id = ...`、`$CI->pay_scene = ...` 动态修改 CI 超全局对象属性。在并发请求或异步回调中极易引发**状态污染**，且破坏封装性。 | 改为通过方法参数显式传递上下文，或使用 `Session`/`Config` 存储临时状态。 | `$params['context'] = ['room_id'=>$this->room_id, 'pay_scene'=>10];<br>$this->neworderservice->createOrderWeb($params);` |
| 🔴 严重 | `Order.php` `buyRenewalPackage` & `createOrder` | 支付渠道路由、金额校验、微信/国通支付参数组装逻辑**完全重复**。硬编码判断易导致支付状态不一致，且遗漏金额篡改防护。 | 抽取独立 `PaymentService` 类，统一处理渠道路由、签名、金额校验与日志脱敏。 | `// 见下方重构建议` |
| 🟠 警告 | `Order.php` `check_params` | 使用松散比较 `==` 与字符串 `'1'`/`'2'`。PHP 类型转换可能导致 `0 == '0'` 或 `'1' == 1` 绕过校验。 | 统一使用严格比较 `===`，并对输入进行类型强转或定义常量。 | `if ($from === '1') { ... }`<br>`$from = (int)($param['from'] ?? 1);` |
| 🟠 警告 | `Ahead_billiards_model.php` `get_room_page_info` | 直接拼接 `FIND_IN_SET(...)` 字符串传入 `where`。若 `_id` 来源未严格过滤，可能引发 **SQL 注入**。 | 使用 CI3 Query Builder 或强制类型转换，避免原始字符串拼接。 | `$this->db->where("FIND_IN_SET(" . (int)$this->room_data['_id'] . ", _room_ids)");` |
| 🟠 警告 | `Order.php` 多处 | 频繁调用 `$this->load->model()` 与 `get_instance()`。虽 CI3 会缓存加载，但重复调用增加 I/O 开销与代码冗余。 | 在 `__construct()` 中预加载高频模型，或缓存 `get_instance()` 引用。 | `private $ci; public function __construct() { parent::__construct(); $this->ci =& get_instance(); }` |
| 🟡 建议 | 全局 | 大量魔法数字/字符串（如 `'1'`, `'-1'`, `14`, `10`, `11`）。业务含义不透明，后期维护成本极高。 | 定义类常量或配置文件，如 `const STATUS_CLOSED = 1; const PAY_WECHAT = 1;`。 | `const ORDER_TYPE_RENEWAL = 4;`<br>`const PAY_PLATFORM_WECHAT = 1;` |
| 🟡 建议 | `Order.php` 顶部 | `include FCPATH . 'application' . DIRECTORY_SEPARATOR...` 路径拼接冗余且非 CI3 标准。 | 使用 CI3 内置常量 `APPPATH` 与 `require_once`。 | `require_once APPPATH . 'controllers/mini/hz/Index.php';` |
| 🟡 建议 | `Order.php` `do_log` | `do_log(var_export($chinaums_set, 1)...)` 直接打印完整配置数组，可能泄露商户密钥、AppID 等敏感信息。 | 日志记录前进行脱敏处理，或使用 CI3 的 `log_message()` 配合日志级别。 | `log_message('debug', 'Chinaums pay config: ' . json_encode(['shop_id'=>$shop_id, 'pay_type'=>$type]));` |
---
## 3. 总结与行动建议
### 🚨 优先修复项（P0）
1. **移除模型文件顶部的 `get_instance()`**：防止框架初始化阶段崩溃。
2. **重构支付逻辑重复代码**：将 `buyRenewalPackage` 与 `createOrder` 中的支付路由、金额校验、渠道参数组装提取至 `PaymentService`。确保金额校验使用 `bccomp` 或严格类型比较，防止浮点精度丢失。
3. **消除动态属性注入**：停止使用 `$CI->xxx = value` 传递上下文。改为通过方法参数数组传递，或使用 `CI_Session` 存储跨方法状态。
### 🛠 后续优化方向
1. **单一职责拆分**：`buyRenewalPackage` 与 `createOrder` 均超过 150 行，建议拆分为：
- `validateOrderParams()`
- `calculatePrice()`
- `processPayment()`
- `buildResponse()`
2. **魔法值治理**：建立 `config/constants.php` 或类常量文件，统一管理订单状态、支付渠道、业务场景标识。
3. **数据库查询优化**：
- 将 `FIND_IN_SET` 等原始 SQL 替换为 CI3 Query Builder 链式调用，利用框架内置的 `escape()` 机制防注入。
- 对高频查询的 `get_one()` 考虑引入 Redis 缓存（如包厢状态、套餐配置）。
4. **安全加固**：
- 补充输入过滤：使用 `filter_var()` 或 CI3 的 `xss_clean()` 处理外部输入。
- 支付回调必须校验签名、金额、订单状态幂等性，当前代码仅在前端下单侧校验，需确认回调层逻辑。
### 📝 支付逻辑重构示例（参考）
```php
// 建议抽取独立服务类 application/libraries/PaymentService.php
class PaymentService {
public function routePayment($orderData, $payPlatform) {
$amount = $orderData['wx_actual_pay'] ?? 0;
if ($payPlatform === 1 && $amount <= 0) {
throw new Exception('微信支付金额异常');
}
// 统一渠道路由
if ($this->isChinaums($orderData['shop_id'])) {
return $this->payChinaums($orderData);
}
return $this->payWechat($orderData);
}
private function payWechat($data) {
// 封装 wxJsApiPayMiniByMerchant 调用，统一日志与异常处理
}
}
```
> ⚠️ **局限性说明**：`Ahead_billiards_model.php` 文件末尾被截断，部分计费与预订逻辑未完全展示。若涉及核心资金结算或库存扣减，建议补充完整代码后二次审查。同时，请确保 `Neworderservice` 库内部已实现事务回滚与防重放机制。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780903066
|
1780903066
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
592
|
21
|
267
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 扫码续费碎片时段
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `f2dd4f25f ## 自动代码审查报告
**分支**: pay-260616
**提交**: `f2dd4f25f345eebf6a7957d47f30649c75c43dd5`
**提交人**: linyangrui (yangruilin888@gmail.com)
**时间**: 2026-06-08 15:18:50
---
## 📋 审查摘要
- **变更文件数**: 1
- **严重问题**: 1
- **高危问题**: 2
- **中危问题**: 3
- **建议优化**: 1
## 🐛 发现的问题
### <font color="red">[语法错误] data对象中存在重复键名 operational_scene</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js
- **行号**: 约 20 & 26 行
- **问题描述**: 在 `data` 对象中，`operational_scene: ''` 被定义了两次。虽然 JavaScript 引擎允许重复键名（后者覆盖前者），但这属于明显的语法/结构错误，极易导致状态初始化混乱或后续维护时产生误解。
- **修复建议**: 删除重复的键名定义，保留一处即可。
```javascript
data: {
// ... 其他字段
operational_scene: '', // 仅保留一处
// ...
}
```
### <font color="red">[跨文件调用] 引用的模型文件及方法未在项目结构中定义</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js
- **行号**: 3-4 行
- **问题描述**: 代码顶部通过 `import` 引入了 `../../../models/package` 和 `../../../models/billiards`，并调用了 `packageModel.getTimePackageList()` 和 `billiardsModel.getHourPriceInfo()`。但提供的「项目结构」中仅包含 PHP (CodeIgniter) 后端文件，**未包含任何前端 JS 模型文件**。若对应路径下不存在 `package.js` 和 `billiards.js`，或导出的方法签名与调用不匹配，页面加载时将直接抛出 `Module not found` 或 `TypeError` 导致白屏。
- **修复建议**:
1. 确认 `web/Hi-Zan/Hi-Zan/models/package.js` 和 `billiards.js` 文件真实存在且路径正确。
2. 确认模型导出的方法签名与调用一致（例如是否支持回调函数 `(res) => {}`，或应改为 `Promise` 链式调用）。
3. 若使用 TypeScript 或现代构建工具，建议添加类型声明或路径别名校验。
### [逻辑 BUG] toPayPage 中未校验索引导致空指针异常
- **严重程度**: 高危
- **文件**: web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js
- **行号**: 约 118 & 123 行
- **问题描述**: `toPayPage` 方法中直接访问 `this.data.package_list[this.data.packageIndex].id` 和 `this.data.hour_list[this.data.hourIndex].hour`。初始状态下 `packageIndex` 和 `hourIndex` 均为 `-1`，若用户未点击选择直接触发下一步，或接口返回空数组，将抛出 `TypeError: Cannot read properties of undefined (reading 'id')` 导致页面崩溃。
- **修复建议**: 在跳转前增加边界校验与用户提示。
```javascript
toPayPage() {
if (this.data.tabId === 'package') {
if (this.data.packageIndex < 0 || !this.data.package_list[this.data.packageIndex]) {
return wx.showToast({ title: '请选择套餐', icon: 'none' });
}
wx.navigateTo({ url: `...&package_id=${this.data.package_list[this.data.packageIndex].id}...` });
} else {
if (this.data.hourIndex < 0 || !this.data.hour_list[this.data.hourIndex]) {
return wx.showToast({ title: '请选择时长', icon: 'none' });
}
wx.navigateTo({ url: `...&hour=${this.data.hour_list[this.data.hourIndex].hour}...` });
}
}
```
### [逻辑 BUG] 微信小程序 dataset 无法直接传递复杂对象
- **严重程度**: 高危
- **文件**: web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js
- **行号**: 约 95 行 (`onHourTap`)
- **问题描述**: `onHourTap(e)` 中通过 `e.currentTarget.dataset.item` 获取数据。在微信小程序底层机制中，`dataset` **仅支持传递字符串、数字、布尔值**。若 WXML 中绑定为 `data-item="{{item}}"`（item 为对象），实际获取到的将是 `"[object Object]"` 字符串或 `undefined`，导致 `item.status` 判断失效或后续逻辑报错。
- **修复建议**: 仅传递索引或唯一标识，再从 `this.data` 中获取完整对象。
```javascript
// WXML 中改为: data-index="{{index}}"
onHourTap(e) {
const index = e.currentTarget.dataset.index;
const item = this.data.hour_list[index];
if (!item || String(item.status) === '-1') return;
// 后续逻辑...
}
```
### [代码质量] API 回调缺少空值与异常处理
- **严重程度**: 中危
- **文件**: web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js
- **行号**: 约 55 & 99 行
- **问题描述**: `getPackageList` 和 `onHourTap` 的回调函数中直接解构 `res.result`。若网络请求失败、后端返回非标准格式或 `res` 为 `null`，代码将直接崩溃。且未处理 `loading` 状态在异常时的重置。
- **修复建议**: 增加防御性编程与 `finally` 逻辑（若模型支持 Promise 则更佳）。
```javascript
packageModel.getTimePackageList(..., (res) => {
this.setData({ loading: false });
if (!res || !res.result) {
wx.showToast({ title: '数据加载失败', icon: 'none' });
return;
}
// 正常处理逻辑...
})
```
### [代码质量] 弱类型比较与魔法值硬编码
- **严重程度**: 中危
- **文件**: web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js
- **行号**: 约 96 行
- **问题描述**: `if(item.status == '-1')` 使用了弱等于 `==`，且状态值 `'-1'` 为硬编码字符串。若后端返回数字 `-1` 或字符串 `'1'`，可能引发隐式类型转换陷阱。
- **修复建议**: 使用严格相等 `===`，并将状态值提取为常量。
```javascript
const STATUS_DISABLED = '-1';
if (String(item.status) === STATUS_DISABLED) { return; }
```
### [安全隐患] URL 参数拼接未进行编码处理
- **严重程度**: 中危
- **文件**: web/Hi-Zan/Hi-Zan/pages/community-reserve/continue-packages/continue-packages.js
- **行号**: 约 118-124 行
- **问题描述**: 使用字符串拼接构造 `wx.navigateTo` 的 `url` 参数。若 `order_id`、`package_id` 等字段包含特殊字符（如 `&`, `=`, `?`, 空格或中文），将破坏 URL 结构，导致路由解析失败或参数丢失。
- **修复建议**: 使用 `encodeURIComponent` 或微信小程序推荐的参数传递方式。
```javascript
const query = `order_id=${encodeURIComponent(this.data.order_id)}&order_type=${encodeURIComponent(this.data.order_type)}&package_id=${encodeURIComponent(this.data.package_list[this.data.packageIndex].id)}&from=renew`;
wx.navigateTo({ url: `/pages/community-reserve/pay/pay?${query}` });
```
## ✅ 代码亮点
1. **状态管理清晰**：使用 `loading` 控制加载态，`tabId` 与 `tab_list` 联动逻辑完整，用户体验较好。
2. **动态 Tab 渲染**：根据接口返回的 `package_list` 和 `hour_list` 动态生成 `tab_list`，兼容了多种业务场景，逻辑考虑较周全。
3. **代码结构规范**：遵循微信小程序 `Page` 规范，生命周期与事件处理函数分离，注释清晰。
## 📝 总体建议
1. **跨文件依赖需优先确认**：当前提供的上下文为 PHP 后端结构，但变更文件为前端 JS。请务必确认 `models/package.js` 与 `models/billiards.js` 的真实存在性及方法签名，否则页面将无法运行。
2. **强化防御性编程**：小程序端网络请求极易受弱网环境影响，所有回调必须增加 `res` 判空、`loading` 重置及错误提示，避免白屏或卡死。
3. **遵循小程序最佳实践**：避免通过 `dataset` 传递对象；URL 参数务必编码；索引访问前必须做边界校验。建议将魔法值提取为常量，提升可维护性。
4. **架构建议**：若项目规模持续扩大，建议将 `packageModel` 等网络请求封装为 `Promise` 形式，配合 `async/await` 使用，可大幅减少回调地狱，提升代码可读性与错误捕获能力。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780903130
|
1780903130
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
594
|
21
|
268
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616 🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616' of https://gitea.g-hi.co...
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `40bd6fe91 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `40bd6fe91deb9630803e63a5b01dbf8e797b67d8`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 15:25:31
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了较为复杂的预订、支付、退款及门店配置业务，但存在明显的架构与规范问题。核心模型文件过于臃肿，违反单一职责原则；存在多处 SQL 拼接隐患、事务管理不规范、边界条件未处理等问题。前端 JS 存在重复键与空指针风险。整体可维护性与安全性有待大幅提升。
- **风险等级**：🔴 高（存在 SQL 注入风险、事务状态不一致、空指针崩溃隐患）
> 📌 **框架说明**：代码实际使用的是 **CodeIgniter 3/4** 架构模式（如 `$CI = &get_instance()`、`$this->load->model()`），而非 `phpci`。以下审查将基于 CI 框架最佳实践与通用 PHP 规范进行。若为内部定制版 `phpci`，底层逻辑仍适用。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_yc_order_model.php`<br>`get_bill_goods_info()` | **SQL 注入风险**：直接使用字符串拼接构造查询条件 `$sql = '_unique_key="' . $unique_key . '" AND ...'`，若 `$unique_key` 未严格过滤，将导致注入。 | 使用 CI 查询构建器或参数绑定，杜绝字符串拼接。 | `$this->db->where('_unique_key', $unique_key)->where_in('_status', [1,4])->...` |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`refund_by_notify()` | **SQL 注入风险**：`$log_where = '_relation_id="' . $order_data['_id'] . '" and ...'` 同样存在拼接隐患。 | 同上，改用查询构建器或 `where()` 链式调用。 | `$this->db->where('_relation_id', $order_data['_id'])->where('_status', 1)->where_in('_type', [5,13])` |
| 🔴 严重 | `continue-packages.js`<br>`toPayPage()` | **空指针/越界崩溃**：`packageIndex` 初始为 `-1`，若用户未选择套餐直接点击下一步，`this.data.package_list[-1]` 将返回 `undefined`，导致小程序白屏。 | 增加前置校验，确保索引有效且数组非空。 | `if (this.data.packageIndex < 0 || !this.data.package_list[this.data.packageIndex]) { wx.showToast({title:'请选择套餐', icon:'none'}); return; }` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`check_notify()` | **事务管理混乱**：混用 `trans_start()/trans_complete()` 与手动 `trans_rollback()`。CI 的 `trans_complete()` 会自动回滚失败事务，手动调用可能导致状态冲突或重复回滚。 | 统一使用 `trans_begin()/trans_commit()/trans_rollback()` 显式控制，或完全依赖 `trans_start()/trans_complete()` 自动机制。 | `try { $this->db->trans_begin(); ... $this->db->trans_commit(); } catch(\Exception $e) { $this->db->trans_rollback(); throw $e; }` |
| 🟠 警告 | `Ahead_shop_config_second_model.php`<br>`get_shop_setting()` | **巨型 Switch 与重复逻辑**：超 100 行的 `switch` 维护成本极高，且多处时间跨天判断逻辑重复。 | 提取配置映射表，将重复的跨天时间计算封装为独立私有方法。 | `private function isTimeInRange($now, $start, $end) { ... }` 配合配置数组动态读取。 |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`send_success_msg()` | **模型频繁加载**：在方法内部多次调用 `$this->load->model()`，每次请求重复实例化，影响性能。 | 在类构造函数中统一加载，或使用 CI 的自动加载配置。 | `public function __construct() { parent::__construct(); $this->load->model(['ahead_merchant_room_type_model', ...]); }` |
| 🟡 建议 | `continue-packages.js`<br>`data` 定义 | **对象键重复**：`operational_scene` 在 `data` 中声明了两次，后者会覆盖前者，易引发维护困惑。 | 删除重复键，保持数据结构清晰。 | `data: { ..., operational_scene: '', ... }` |
| 🟡 建议 | `continue-packages.js`<br>`onHourTap()` | **手动构造事件对象**：`this.onHourTap({ currentTarget: { dataset: { index: 0, item: hourList[0] } } })` 属于 Hack 写法，破坏框架事件流。 | 提取公共逻辑为独立方法 `calculateHourPrice(index, item)`，供点击与初始化共用。 | `calculateHourPrice(index, item) { ... }` |
| 🟡 建议 | 全局 PHP 文件 | **文件级 `$CI` 引用**：`$CI = &get_instance();` 放在类外部，违反 CI 规范且可能在非请求上下文报错。 | 移除文件级引用，在类方法内通过 `$this->ci = &get_instance()` 或直接使用 `$this->load`。 | `class Ahead_book_order_model extends Simple_model { protected $ci; public function __construct() { parent::__construct(); $this->ci =& get_instance(); } }` |
| 🟡 建议 | 全局 PHP 文件 | **日志函数不一致**：混用 `doLog()` 与 `do_log()`，且硬编码日志分类字符串。 | 统一日志函数，建议使用 PSR-3 标准或框架内置日志组件。 | `$this->ci->logger->error('支付失败', ['trace' => $e->getTrace()]);` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **立即修复 SQL 注入漏洞**：所有涉及 `$sql = '...' . $var . '...'` 或 `$log_where = '...'` 的查询必须替换为 CI 查询构建器（`$this->db->where()`）或预处理语句。
2. **防御性编程补全**：前端 `toPayPage` 必须增加索引有效性校验；后端 `refund_by_notify` 等核心资金操作需增加参数类型校验与空值拦截。
3. **规范事务生命周期**：统一使用 `trans_begin()` → 业务逻辑 → `trans_commit()`，失败时 `catch` 中 `trans_rollback()`。避免与 `trans_complete()` 混用。
### 🛠 后续重构与优化方向
1. **拆分巨型模型（SRP 原则）**：`Ahead_book_order_model` 与 `Ahead_yc_order_model` 承担了订单创建、支付回调、退款、消息推送、账单合并等数十项职责。建议拆分为：
- `OrderService`（业务编排）
- `PaymentGateway`（支付/退款路由）
- `NotificationService`（短信/微信模板）
- `BillCalculator`（账单合并逻辑）
2. **配置与魔法数字治理**：代码中大量出现 `1, 2, 3, 10, 14` 等状态码。建议统一提取为 `const` 或枚举类（如 `OrderStatus::PAID = 1`），提升可读性。
3. **静态缓存策略优化**：`self::$shop_config` 在 PHP-FPM 下是进程级缓存，需注意多门店数据污染问题。建议结合 Redis 或 CI Cache 驱动实现分布式缓存，并设置合理的 TTL。
4. **代码规范对齐**：全面启用 PSR-12 规范（命名空间、类型声明、数组短语法 `[]`、统一缩进）。建议接入 `PHP_CodeSniffer` 或 `PHP-CS-Fixer` 进行 CI/CD 自动化检查。
5. **补全截断代码**：`Ahead_book_order_model.php` 与 `Ahead_yc_order_model.php` 末尾代码被截断，请确保提交完整逻辑，避免线上语法解析错误。
> 💡 **提示**：若项目确为 `phpci` 定制框架，请确认其是否兼容 CI3 的 `load->model()` 语法。若为自研框架，建议逐步迁移至现代 PHP 特性（PHP 8.1+、依赖注入容器、严格类型声明），以降低长期维护成本。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780903531
|
1780903531
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
595
|
21
|
269
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `e7036e47a ## 自动代码审查报告
**分支**: pay-260616
**提交**: `e7036e47a975a9fafeca15b07d363af7119760e8`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 15:31:23
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：代码实现了完整的预订、支付回调、退款及消息通知业务流程，具备基础的事务控制与状态校验。但存在**敏感信息明文入日志**、**全局实例提前加载**、**事务与异常处理耦合不严谨**、**魔法数字泛滥**及**重复加载模型**等问题。整体偏向传统 CI3 风格，可维护性与安全性有较大提升空间。
- **风险等级**：🔴 高（主要源于支付敏感数据日志泄露风险、事务边界不清晰及潜在 SQL 注入隐患）
> 📌 **注**：代码末尾 `create_community_shop_book_order` 方法被截断，本次审查基于已提供内容。若 `phpci` 为内部定制框架，部分底层实现（如 `up()`、`doLog()`）可能与标准 CI3 存在差异，建议结合官方文档核对。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | 文件顶部 (第 8 行) | 在类外部直接调用 `$CI = &get_instance();`。该代码会在文件被 `include/require` 时立即执行，此时框架可能尚未完成初始化，极易引发 `Fatal Error`。 | 移除全局调用。在类内部按需使用 `$CI =& get_instance();`，或优先使用 `$this->load->config()` 等框架内置方法。 | `// 删除顶部：<br>$CI = &get_instance();<br>$CI->load->model('Simple_model');<br><br>class Ahead_book_order_model extends Simple_model { ... }` |
| 🔴 严重 | `refund_by_notify` / `send_success_msg` | 使用 `var_export($input, true)` 记录支付请求对象。该对象通常包含商户密钥、证书路径、签名串等敏感信息，直接写入日志存在严重数据泄露风险。 | 记录日志前过滤敏感字段，或仅记录脱敏后的关键业务字段（如订单号、金额、状态码）。 | `doLog('RefundReq: order_id=' . $order_data['_id'] . ', fee=' . $total_fee . ', res_code=' . ($res['result_code'] ?? 'N/A'), 'BookOrderWxRefund');` |
| 🟠 警告 | `check_notify` / `refund_by_notify` | 混用 CI 自动事务与手动 `trans_rollback()`。在 `try-catch` 中手动回滚后直接 `return`，未调用 `trans_complete()`，可能导致数据库连接的事务状态残留或后续查询异常。 | 统一使用显式事务控制：`trans_begin()` → 业务逻辑 → `trans_commit()` / `trans_rollback()`，或依赖 `trans_status()` 自动处理。 | `try {<br> $this->db->trans_begin();<br> // 业务逻辑...<br> if ($this->db->trans_status() === FALSE) throw new Exception('DB Error');<br> $this->db->trans_commit();<br>} catch (Exception $e) {<br> $this->db->trans_rollback();<br> // 记录日志并返回<br>}` |
| 🟠 警告 | `refund_by_notify` (日志更新段) | `$log_up = '_status=4,_refund_amount=_actual_pay';` 拼接原始 SQL 片段传入自定义 `up()` 方法。若底层未使用参数绑定，存在 SQL 注入风险，且破坏查询构建器规范。 | 改用框架查询构建器或确保底层严格转义。避免手动拼接 SET 子句。 | `$this->ahead_pay_log_model->where($log_where)->update(['_status' => 4, '_refund_amount' => '_actual_pay', '_vip_account_refund' => '_vip_account', '_present_refund_amount' => '_present_amount']);` |
| 🟠 警告 | `get_list` | 循环内通过 `$this->ahead_merchant_model->get_one()` 查询商户信息。虽使用 `$merchant_business_model` 数组做了内存缓存，但仍属 N+1 查询模式，数据量大时性能下降明显。 | 提取所有 `merchant_id` 后使用 `WHERE IN` 批量查询，或在主查询中使用 `JOIN`。 | `$ids = array_column($order_info, 'merchant_id');<br>$merchants = $this->ahead_merchant_model->get_many(['_id' => $ids], '_id,_business_model');<br>$map = array_column($merchants, '_business_model', '_id');` |
| 🟡 建议 | 全局多处 | 魔法数字泛滥（如 `-1, 1, 2, 3, 4, 5, 14, 22, 56, 58, 99`）。状态、平台、场景等硬编码严重降低可读性，且易引发维护错误。 | 提取为类常量或独立配置文件，配合语义化命名。 | `const STATUS_UNPAID = -1;<br>const STATUS_PAID = 1;<br>const PAY_SCENE_WECHAT = '5';<br>const PLATFORM_WX = 1;` |
| 🟡 建议 | `send_success_msg` / `refund_by_notify` | 方法内部频繁调用 `$this->load->model()`。每次调用都会触发文件加载与实例化，增加运行时开销。 | 将高频依赖的模型移至构造函数加载，或配置 CI 自动加载 (`autoload.php`)。 | `public function __construct() {<br> parent::__construct();<br> $this->load->model(['ahead_book_model', 'ahead_room_package_infos_model', 'ahead_vip_model']);<br>}` |
| 🟡 建议 | 全局 | 数组语法混用 `array()` 与 `[]`，注释风格不统一，部分注释含历史提交人信息（如 `//add by nan 18.1.22`），不符合 PSR-12 规范。 | 统一使用短数组语法 `[]`；清理过期注释；使用 PHPDoc 标准块注释。 | `public $status_arr = [<br> -1 => '待支付',<br> 1 => '已付款',<br>];` |
## 3. 总结与行动建议
### 🔑 优先修复项（P0/P1）
1. **移除文件顶部的全局 `$CI =& get_instance();`**：这是导致潜在致命错误的根源，必须立即改为类内按需加载。
2. **支付日志脱敏**：所有涉及 `WxPayRefund`、`ChinaUMS` 等第三方 SDK 对象的日志记录，必须剥离密钥、证书、签名等敏感字段，仅保留业务流水号、金额、状态码。
3. **规范事务边界**：将 `check_notify` 与 `refund_by_notify` 中的事务控制改为显式的 `trans_begin()` / `trans_commit()` / `trans_rollback()`，避免与 CI 自动状态机冲突。
### 🛠 后续重构方向
1. **常量与配置抽离**：建立 `config/book_order.php` 或类常量文件，集中管理订单状态、支付场景、平台标识、短信模板 ID 等魔法值。
2. **模型加载优化**：采用构造函数预加载或 CI 自动加载机制，减少运行时 `load->model()` 调用。对于跨模块依赖，可考虑引入轻量级服务容器或依赖注入。
3. **查询性能提升**：将 `get_list` 中的循环查询改为批量 `WHERE IN` 或 `JOIN`；对高频读取的套餐/商户信息引入 Redis 缓存层（结合 `Cache_redis.php`）。
4. **代码规范对齐**：使用 `PHP_CodeSniffer` 配置 `PSR-12` 规则进行自动化格式化；统一数组语法、清理冗余注释、规范 PHPDoc 类型声明。
> 💡 **框架适配提示**：代码结构高度契合 CodeIgniter 3.x。若 `phpci` 为定制分支，请重点核对 `DB_driver.php` 中 `trans_*` 系列方法的具体实现，以及 `doLog()` / `do_log()` 的底层日志轮转策略。建议补充单元测试覆盖 `check_notify` 的并发支付场景与 `refund_by_notify` 的第三方 API 超时/失败回滚逻辑。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780903883
|
1780903883
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
596
|
21
|
270
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 自助预订开房事务优化
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `ba7ff670d ## 自动代码审查报告
**分支**: pay-260616
**提交**: `ba7ff670d071bb91dc34709f4838c23d68da4a18`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 15:45:38
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了较为复杂的订单计价、预订、退款及消息推送逻辑，业务覆盖度较高。但存在明显的调试代码残留、SQL 拼接隐患、N+1 查询问题以及大量不符合现代 PHP 规范的写法。类与方法的命名、可见性控制、异常处理机制较为混乱，且代码片段在末尾被截断，部分核心逻辑无法完整评估。
- **风险等级**：🔴 高（存在 SQL 注入隐患、调试输出破坏响应、事务回滚逻辑不严谨等问题）
> 📌 **框架说明**：代码结构高度符合 **CodeIgniter 3** 规范（如 `BASEPATH`、`get_instance()`、`$this->load->model()` 等）。若 `phpci` 为内部定制框架，请结合其官方文档对生命周期与组件调用方式进行微调。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Neworderservice.php`<br>`getOrderTypeInfo` 方法内 | 循环中遗留 `echo $vip_upgrade_data_actual_pay;` 调试语句。在 API 或 JSON 响应场景下会直接破坏输出格式，导致前端解析失败。 | 立即删除 `echo`，如需记录请改用框架日志函数。 | `// 删除该行<br>doLog("VIP升级金额计算: {$vip_upgrade_data_actual_pay}", 'vip_upgrade');` |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`refund_by_notify` 方法 | 使用字符串拼接构造 SQL 条件：`$log_where = '_relation_id="' . $order_data['_id'] . '"...'`。若 `_id` 未严格过滤，将导致 SQL 注入。 | 使用 CI 查询构建器或参数绑定，杜绝手动拼接。 | `$this->db->where('_relation_id', $order_data['_id'])<br> ->where('_status', 1)<br> ->where_in('_type', [5, 13])<br> ->update('pay_log_table', $log_up_data);` |
| 🔴 严重 | `Ahead_book_order_model.php`<br>文件顶部 | 在类外部直接执行 `$CI = &get_instance();`。文件被 `include` 时 CI 可能尚未完全初始化，易引发 Fatal Error 或内存泄漏。 | 移除全局调用，改为在类方法内部按需获取实例。 | `// 删除顶部代码<br>class Ahead_book_order_model extends Simple_model {<br> public function check_notify() {<br> $CI =& get_instance(); // 按需调用<br> }<br>}` |
| 🟠 警告 | `Neworderservice.php`<br>`getOrderTypeInfo` 方法 | 变量 `$order['_prime_service_charge']` 与 `$result['service_charge']` 被重复赋值，且 `$order['_prime_service_charge']` 先后被赋值为 `$prime_after_paid_service_charge` 和 `$service_charge`，逻辑覆盖易引发计费偏差。 | 梳理变量命名与赋值时机，删除冗余行，确保金额计算链路清晰。 | `// 清理重复赋值<br>$order['_prime_service_charge'] = $prime_after_paid_service_charge;<br>$result['service_charge'] = $service_charge;` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`check_notify` 方法 | `try-catch` 捕获 `Exception` 后仅记录日志并返回 `false`，未中断事务或向上抛出。若底层发生致命异常，可能导致数据处于不一致状态。 | 捕获后应调用 `$this->db->trans_rollback()` 并抛出业务异常，或统一返回错误码。 | `} catch (\Exception $e) {<br> $this->db->trans_rollback();<br> log_message('error', '支付回调异常: ' . $e->getMessage());<br> return ['status' => false, 'msg' => '系统异常，请稍后重试', 'return' => 500];<br>}` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`get_list` 方法 | 在 `foreach` 循环中执行 `$this->ahead_merchant_model->get_one(...)`，产生典型的 **N+1 查询问题**，数据量大时严重拖慢接口响应。 | 提取所有 `merchant_id`，使用 `WHERE IN` 批量查询，再通过数组映射回填。 | `$ids = array_column($order_info, 'merchant_id');<br>$merchants = $this->ahead_merchant_model->where_in('_id', $ids)->get()->result_array();<br>$merchantMap = array_column($merchants, '_business_model', '_id');<br>foreach ($order_info as &$v) {<br> $v['business_model'] = $merchantMap[$v['merchant_id']] ?? '1';<br>}` |
| 🟡 建议 | `Neworderservice.php`<br>类定义与属性 | 类名 `Neworderservice` 及大量方法名（如 `_create_insert_infos_data`）不符合 PSR-12 驼峰规范；核心业务属性全为 `public`，破坏封装性。 | 类名改为 `NewOrderService`，方法名改为 `createInsertInfosData`，属性改为 `private/protected` 并提供访问器。 | `class NewOrderService {<br> private $supermarketRoomName = '自助扫码厅';<br> public function getRoomName(): string { return $this->supermarketRoomName; }<br>}` |
| 🟡 建议 | 全局文件 | 混用 `throwError()`、`doLog()`、`do_log()` 等全局函数，缺乏统一的异常与日志处理规范，不利于后期维护与链路追踪。 | 统一使用 PHP 原生 `Exception` 或 CI 的 `log_message()`，业务层通过 `try-catch` 或拦截器处理。 | `throw new \InvalidArgumentException('参数校验失败');<br>log_message('debug', '订单计算完成', $context);` |
| 🟡 建议 | `Neworderservice.php`<br>多处方法 | 频繁在方法内部调用 `$this->CI->load->model()`。CI 虽会缓存已加载模型，但重复调用仍增加解析开销且降低可读性。 | 在 `__construct()` 或方法入口处集中加载依赖模型。 | `public function __construct() {<br> $this->CI =& get_instance();<br> $this->CI->load->model(['Ahead_vip_level_model', 'Ahead_merchant_goods_model']);<br>}` |
---
## 3. 总结与行动建议
### 🔑 优先修复项（P0/P1）
1. **清除调试输出**：立即移除 `Neworderservice.php` 中的 `echo` 语句，避免生产环境接口响应损坏。
2. **修复 SQL 注入隐患**：将 `refund_by_notify` 中的字符串拼接条件替换为 CI Query Builder 或参数绑定。
3. **修正全局实例调用**：删除 `Ahead_book_order_model.php` 顶部的 `$CI = &get_instance();`，改为方法内按需调用。
4. **统一事务与异常处理**：确保所有 `try-catch` 块在捕获异常后正确执行 `trans_rollback()`，并返回标准化错误结构。
### 🛠 后续重构与优化方向
1. **架构与规范升级**：
- 严格遵循 **PSR-12** 命名规范，将 `public` 属性降级为 `private/protected`，通过 Getter/Setter 暴露必要数据。
- 引入类型声明（PHP 7.4+ 支持 `array`, `int`, `string` 等），提升代码自文档化能力。
2. **性能优化**：
- 消除 `get_list` 等场景的 N+1 查询，改用批量查询+内存映射。
- 将重复的模型加载、配置读取逻辑提取至构造函数或依赖注入容器中。
3. **业务逻辑解耦**：
- `getOrderTypeInfo` 方法过长（超 500 行），建议按“商品计价”、“套餐计价”、“优惠券抵扣”、“服务费计算”拆分为独立策略类或私有方法。
- 统一错误抛出机制，废弃全局 `throwError()`，改用 `throw new \RuntimeException()` 配合全局异常处理器。
4. **安全加固**：
- 所有外部输入（如 `$param`、`$order_data`）在入库或参与计算前进行严格类型转换与白名单校验。
- 若数据最终输出至前端，务必使用 `htmlspecialchars()` 或框架内置的 XSS 过滤函数。
> ⚠️ **局限性说明**：本次审查基于您提供的代码片段。由于 `Neworderservice.php` 与 `Ahead_book_order_model.php` 均在末尾被截断，部分核心逻辑（如订单最终落库、支付回调完整流程、团购核销逻辑）无法进行全链路验证。建议补充完整代码后再次进行深度审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780904738
|
1780904738
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
598
|
21
|
271
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616 🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616' of https://gitea.g-hi.co...
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `5ff542a6b ## 自动代码审查报告
**分支**: pay-260616
**提交**: `5ff542a6bc55215e93856d51c13640688e03939b`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 18:31:12
---
## 📋 审查摘要
- **变更文件数**: 3
- **严重问题**: 1
- **高危问题**: 4
- **中危问题**: 3
- **建议优化**: 2
## 🐛 发现的问题
### <font color="red">[语法错误] PHP 文件截断导致致命解析失败</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: `application/models/Ahead_book_order_model.php`
- **行号**: 末尾（约第 660 行）
- **问题描述**: 代码在 `if ($this->tuangou->verify_token) {` 处突然中断，缺失后续逻辑及所有闭合的大括号 `}`。这将直接导致 PHP 引擎抛出 `Parse error: syntax error, unexpected end of file`，模型无法加载，相关接口全部 500 报错。
- **修复建议**: 立即补全缺失的业务逻辑，并严格检查 `if`、`try`、`function` 及类定义的括号配对。建议使用 IDE 的自动格式化功能快速定位未闭合代码块。
### <font color="red">[跨文件调用] 未加载的微信支付 SDK 类直接实例化</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `application/models/Ahead_book_order_model.php`
- **行号**: 约 260, 290, 305
- **问题描述**: 代码中直接使用 `new WxPayRefund()`、`WxPayApi::refund()` 及常量 `WxPayConfig::MCHID`。在 CodeIgniter 环境中，这些类通常位于第三方目录，必须通过 `require` 引入或 `$this->load->library()` 加载。直接 `new` 会触发 `Class 'WxPayRefund' not found` 致命错误。
- **修复建议**: 在文件顶部或方法入口处添加引入语句，例如：`require_once APPPATH.'libraries/WxPay/lib/WxPay.Api.php';`，或确保该类已在 CI 的 `autoload.php` 中配置自动加载。
### <font color="red">[跨文件调用] 小程序页面依赖的外部模型方法未验证</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/pay/pay.js`
- **行号**: 多处（如 105, 135, 165, 205, 235, 265, 305, 335, 365）
- **问题描述**: 页面实例化并调用了 `PackageModel`, `BilliardsModel`, `RoomModel`, `UserModel` 的数十个方法（如 `getRenewPayInfo`, `checkNotCleanNotice`, `getUserMobile` 等）。由于未提供这些模型源码，无法确认方法签名、参数顺序及返回值结构是否匹配。若存在拼写错误或参数遗漏，将导致运行时 `TypeError` 或静默失败。
- **修复建议**: 请严格对照 `models/package.js`, `models/billiards.js`, `models/room.js`, `models/user.js` 的导出定义，逐一核对方法名与参数列表。建议为外部模型调用添加 `try...catch` 或空值防御。
### <font color="red">[跨文件调用] 全局函数与常量命名不一致且未声明</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `application/models/Ahead_book_order_model.php`
- **行号**: 全文多处
- **问题描述**: 代码混用 `doLog()` 与 `do_log()` 日志函数；依赖大量未在当前文件定义的全局函数（`get_business_date`, `sendRoomStatusToApp`, `createOutTradeNo`, `throwError`, `isDateDayTime` 等）和常量（`PAY_BASE_URL`, `DEFAULWARESTIMG`）。若未通过 CI Helper 或 Config 正确加载，将引发 `Call to undefined function/constant` 错误。
- **修复建议**: 全局搜索统一日志函数命名（建议统一为 `do_log`）；在文件头部或 CI `autoload.php` 中显式加载对应 helper 文件；确保所有业务常量已在 `config/constants.php` 中定义。
### [逻辑 BUG] 数据库事务与异常处理混用可能导致状态不一致
- **严重程度**: 高危
- **文件**: `application/models/Ahead_book_order_model.php`
- **行号**: 约 50-110 (`check_notify` 方法)
- **问题描述**: 使用 `$this->db->trans_start()` 开启事务，但在 `try...catch` 中手动调用 `$this->db->trans_rollback()`。CodeIgniter 的 `trans_complete()` 本身会根据查询结果自动提交或回滚。手动回滚后再执行 `trans_complete()` 可能导致事务状态机混乱。此外，CI 默认不抛出数据库异常，`catch (Exception $e)` 通常无法捕获 SQL 执行失败。
- **修复建议**: 移除 `try...catch` 中的手动 `trans_rollback()`，完全依赖 `$this->db->trans_complete()` 的自动机制；或改用 `$this->db->trans_begin()` 配合显式的 `trans_commit()`/`trans_rollback()` 控制流。
### [逻辑 BUG] 直接修改小程序上一页 `options` 对象违反框架规范
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/pay/pay.js`
- **行号**: 约 430 (`onUnload` 方法)
- **问题描述**: `prevPage.options.needReRecommend = 'true';` 直接赋值修改了页面栈中上一页的 `options`。微信小程序的 `options` 是框架注入的只读配置对象，直接修改可能无效、被覆盖或引发不可预知的渲染异常。
- **修复建议**: 改用全局状态管理（如 `app.globalData`）或发布/订阅事件总线进行跨页面通信；或让上一页在 `onShow` 生命周期中主动查询最新状态。
### [安全隐患] 支付核心参数本地存储且缺乏服务端二次校验风险
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/pay/pay.js`
- **行号**: 约 395 (`onConfirmTap` 方法)
- **问题描述**: `wx.setStorageSync('order_params', order_params)` 将包含金额、支付方式、商品明细的敏感数据存入本地 Storage。恶意用户可通过开发者工具篡改 Storage 数据，若服务端下单接口未根据 `order_id` 重新计算价格并校验参数，将导致越权支付、金额篡改或商品替换漏洞。
- **修复建议**: 本地仅存储临时业务标识（如 `order_id` 或 `session_key`）。所有金额、优惠、商品明细必须在服务端根据标识重新拉取并计算，**绝不信任客户端传递的支付参数**。
### [代码质量] 魔法数字硬编码支付平台类型
- **严重程度**: 中危
- **文件**: `application/models/Ahead_book_order_model.php` & `pay.js`
- **行号**: 多处
- **问题描述**: 代码中大量使用 `1`, `3`, `8`, `9`, `14` 等数字表示支付渠道（微信、会员卡、团购、兑换、组合支付）。例如 `if ($params['pay_platform'] == '14')`，可读性差，后期维护极易出错。
- **修复建议**: 定义语义化常量或枚举。例如：`const PAY_PLATFORM_WECHAT = 1; const PAY_PLATFORM_VIP = 3; const PAY_PLATFORM_COMBINE = 14;`，前后端统一引用。
### [代码质量] 模型重复加载与命名规范不统一
- **严重程度**: 中危
- **文件**: `application/models/Ahead_book_order_model.php`
- **行号**: 约 180, 210, 240
- **问题描述**: `ahead_room_type_book_log_model` 在 `_check_param` 中被 `$this->load->model()` 重复加载两次；模型加载命名大小写混用（如 `Ahead_sms_config_model` vs `ahead_shop_config_model`）。CI 在 Linux 环境下对文件名大小写敏感，混用可能导致部署后加载失败。
- **修复建议**: 移除重复的 `load->model` 调用；统一遵循 CI 规范：模型文件名首字母大写（如 `Ahead_sms_config_model.php`），加载时使用 `$this->load->model('ahead_sms_config_model');`（CI 会自动处理大小写映射）。
## ✅ 代码亮点
- `reserve.js` 采用 ES6 Class 封装，请求参数与成功/失败回调分离清晰，符合现代小程序架构规范，易于维护和扩展。
- `pay.js` 对多业务场景（续费、开台套餐、卡券兑换、AI预订、组合支付）做了明确的路由分发与状态隔离，业务边界划分合理。
- `Ahead_book_order_model.php` 在支付回调中完整实现了库存扣减、事务控制、退款逻辑、消息推送及流水记录，业务闭环设计严谨，具备较强的生产可用性。
## 📝 总体建议
1. **紧急修复**：立即补全 `Ahead_book_order_model.php` 截断的代码，否则线上环境将直接崩溃。
2. **依赖治理**：严格审查 CI 框架的自动加载配置，确保所有第三方 SDK（微信支付）、全局 Helper 函数、业务常量在运行时可用。建议引入 Composer 或统一依赖管理目录。
3. **架构解耦**：小程序端 `pay.js` 已超 600 行，建议将支付计算、弹窗控制、授权逻辑抽离为独立的 `services/` 或 `utils/` 模块，降低页面耦合度。PHP 端建议逐步引入类型声明（Type Hinting）和依赖注入，减少动态属性赋值（如 `$CI->request_source`）。
4. **安全加固**：所有涉及资金流转的接口必须实现**幂等性控制**与**参数签名验证**。客户端仅负责展示与交互，核心金额、库存、状态变更必须由服务端基于可信数据源重新计算。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780914672
|
1780914672
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
599
|
21
|
272
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 预订退款后是否关房
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `a43870d55 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `a43870d55562d5a4c204a97c0b0fbc9421fc6b87`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 18:39:13
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：代码实现了较为复杂的预订、支付回调、退款及门店配置逻辑，业务闭环完整。但存在明显的**事务控制不规范**、**SQL 拼接隐患**、**巨型 Switch 结构**以及**硬编码泛滥**等问题。部分方法职责过重，模型加载分散，不利于后期维护与性能扩展。
- **风险等级**：🟠 中高风险（主要源于事务状态混乱、潜在 SQL 注入及敏感日志泄露）
> 📌 **框架说明**：基于 `$CI = &get_instance()`、`$this->load->model()`、`$this->db->trans_start()` 等特征，代码高度符合 **CodeIgniter 3** 架构规范。若 `phpci` 为内部定制框架，请结合其官方文档对事务与模型加载机制进行微调。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`refund_by_notify` 约第 380 行 | **原始 SQL 拼接存在注入风险**。<br>`$log_where = '_relation_id="' . $order_data['_id'] . '" and ...'` 直接拼接字符串，若 `_id` 来源不可控将导致 SQL 注入。 | 使用 CI 查询构建器或参数绑定，彻底杜绝拼接。 | `$this->db->where('_relation_id', $order_data['_id'])<br> ->where('_status', 1)<br> ->where_in('_type', [5, 13]);` |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`check_notify` 约第 60-110 行 | **事务控制逻辑混乱**。<br>`trans_start()` 开启自动事务模式，但内部手动调用 `trans_rollback()` 后又未正确配对 `trans_complete()`，极易导致数据库连接状态异常或死锁。 | 统一使用 `trans_begin()` / `trans_commit()` / `trans_rollback()` 手动控制，或完全依赖 `trans_start()` + `trans_complete()` 自动提交/回滚。 | `// 推荐手动控制模式<br>$this->db->trans_begin();<br>try {<br> // 业务逻辑...<br> $this->db->trans_commit();<br>} catch (Exception $e) {<br> $this->db->trans_rollback();<br> throw $e;<br>}` |
| 🟠 警告 | `Ahead_shop_config_second_model.php`<br>`get_shop_setting` 全方法 | **巨型 Switch 违反开闭原则**。<br>近 300 行 Switch 导致方法臃肿，新增配置需修改核心逻辑，且每次调用都会遍历匹配，性能与可维护性差。 | 采用**配置数组映射**或**策略模式**。将字段名与默认值/处理逻辑解耦。 | `private $config_map = [<br> 'book_refund_time_limit' => ['default' => 2, 'status_field' => 'book_refund_time_limit_status'],<br> // ...<br>];<br>public function get_shop_setting($mid, $sid, $field) {<br> $cfg = $this->load_config($mid, $sid);<br> return $cfg[$field] ?? ($this->config_map[$field]['default'] ?? '');<br>}` |
| 🟠 警告 | `Ahead_shop_config_second_model.php`<br>`deal_audio_content_params` 约第 410 行 | **变量未初始化直接使用**。<br>`$total_time` 仅在 `if` 内部赋值，若条件不满足，PHP 8+ 会抛出 `Undefined variable` 警告。 | 在循环前显式初始化变量。 | `$total_time = ''; // 提前初始化<br>if (!empty($room_data['_open_id'])) { ... }` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`send_success_msg` 全方法 | **模型重复加载 & 硬编码索引**。<br>方法内多次 `load->model()`；`$wx_template[14]['color']` 等硬编码索引脆弱且难以追踪。 | 模型应在构造函数或类属性中预加载；模板配置应提取为常量或独立配置数组。 | `// 类顶部定义<br>const WX_TMPL_BOOK_ORDER = 14;<br>// 使用时<br>$color = $wx_template[self::WX_TMPL_BOOK_ORDER]['color'] ?? '#333';` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`renewal_audio_broadcast` | **循环内执行数据库查询 (N+1)**。<br>`foreach` 嵌套中调用 `get_end_time_room()`，门店/账单量大时将产生严重性能瓶颈。 | 改为批量查询：先收集所有 `end_time`，使用 `WHERE IN` 一次性拉取，再在内存中分组匹配。 | `$end_times = array_map(fn($t) => $time + $t*60, $billiards_renewal_audio_time);<br>$bill_list = $this->ahead_bill_model->get_end_time_rooms_batch($shop, $business_date, $end_times);` |
| 🟡 建议 | 全局多处 | **魔法数字/字符串泛滥**。<br>`1`, `-1`, `5`, `13`, `58`, `56`, `2333` 等状态码/类型码散落各处，语义不明。 | 在类顶部定义 `const` 常量，或统一收口至配置类/枚举类。 | `const STATUS_UNPAID = -1;<br>const STATUS_PAID = 1;<br>const PAY_SCENE_WECHAT = '5';` |
| 🟡 建议 | `Ahead_book_order_model.php`<br>`get_list` 约第 530 行 | **循环内查询商户信息（虽有缓存但仍可优化）**。<br>虽使用 `$merchant_business_model` 缓存，但首次请求仍会逐条查询。 | 提取所有 `merchant_id` 去重后，使用 `WHERE IN` 批量查询，再映射回数组。 | `$mids = array_unique(array_column($order_info, 'merchant_id'));<br>$merchants = $this->ahead_merchant_model->get_where_in('_id', $mids, '_id,_business_model');` |
| 🟡 建议 | `Ahead_book_order_model.php`<br>`refund_by_notify` 日志记录 | **日志可能包含敏感支付信息**。<br>`doLog(var_export($input, true)...)` 会明文记录交易流水号、金额、商户号等。 | 记录前对敏感字段进行脱敏（如掩码处理）。 | `function mask_sensitive($data) {<br> $data['_trade_no'] = substr($data['_trade_no'], 0, 4) . '****';<br> return $data;<br>}` |
---
## 3. 总结与行动建议
### 🚨 优先修复项（P0/P1）
1. **修复 SQL 注入隐患**：立即将 `refund_by_notify` 中的 `$log_where` 字符串拼接替换为 CI Query Builder 或参数绑定。
2. **规范事务生命周期**：统一 `check_notify` 及 `create_book_order` 中的事务写法。建议采用 `trans_begin()` -> 业务逻辑 -> `trans_commit()` / `trans_rollback()` 显式控制，避免与 `trans_start()` 混用导致状态机错乱。
3. **变量初始化与 PHP 8 兼容**：修复 `deal_audio_content_params` 中未初始化变量问题，避免生产环境日志报错或逻辑中断。
### 🛠 后续重构与优化方向
1. **配置模型解耦**：`Ahead_shop_config_second_model::get_shop_setting` 建议重构为**配置映射表 + 缓存策略**。可引入 CI Cache 库（如 Redis/Memcached）替代 `self::$shop_config` 静态缓存，解决 PHP-FPM 进程驻留导致的配置脏读问题。
2. **提取业务常量与枚举**：将支付场景、订单状态、短信模板 ID 等魔法值抽离为独立配置类或 PHP 8.1+ `enum`，提升代码自解释能力。
3. **模型加载集中化**：将 `send_success_msg`、`refund_by_notify` 中频繁 `load->model()` 的操作移至类构造函数或 `__get()` 魔术方法中，减少运行时开销。
4. **批量查询优化**：针对 `renewal_audio_broadcast`、`get_list` 等循环查库场景，全面改为 `WHERE IN` 或 `JOIN` 批量拉取，降低数据库连接压力。
> ⚠️ **局限性说明**：`Ahead_book_order_model.php` 末尾的 `create_community_shop_book_order` 方法代码被截断（结束于 `if ($this->tuangou->verify_token) {`），未能对该方法的完整逻辑、团购券核销及组合支付分支进行审查。建议补充完整代码后再次进行专项评审。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780915153
|
1780915153
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
600
|
21
|
273
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 预订单申请退款
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `257b35c23 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `257b35c23379828a17d2b0e62f7ff94750fae210`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 19:21:31
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：业务逻辑覆盖较全，实现了预订、支付、退款、变更及门店配置等核心流程。但代码带有较重的历史包袱，存在 MVC 分层不严谨、事务处理不规范、巨型方法难以维护等问题。部分代码存在语法瑕疵、死代码及敏感信息泄露风险。整体可维护性与健壮性有较大提升空间。
- **风险等级**：🟠 中（存在事务状态混乱、模型层越权抛出错误、日志明文记录敏感数据等隐患）
> 📌 **框架说明**：提供的代码结构、核心函数（如 `get_instance()`、`$this->load->model()`）及常量（`BASEPATH`）均高度符合 **CodeIgniter 3** 框架特征。若项目实际基于 `phpci`，请确认其是否完全兼容 CI3 核心。以下审查基于 CI3 最佳实践进行。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_book_order_model.php` 顶部<br>`Ahead_shop_config_second_model.php` 顶部 | **文件级实例化破坏生命周期**：在类定义外部直接执行 `$CI = &get_instance(); $CI->load->model('Simple_model');`。文件被 `include` 时立即执行，在 CLI、单元测试或异步环境中极易报错，且违反 OOP 封装原则。 | 将实例化与模型加载移至类的 `__construct()` 方法中。 | ```php<br>public function __construct()<br>{<br> parent::__construct();<br> $CI = &get_instance();<br> $CI->load->model('Simple_model');<br>}<br>``` |
| 🔴 严重 | `Book.php`<br>`communityNotCleanChangeBook()` | **事务处理逻辑混乱**：混用 `$this->db->trans_start()`、手动 `$this->db->trans_rollback()` 与末尾的 `$this->db->trans_complete()`。CI3 中 `trans_complete()` 会根据 `trans_status()` 自动提交或回滚，混用可能导致状态覆盖或重复操作。 | 采用显式事务控制模式，确保状态清晰。 | ```php<br>$this->db->trans_begin();<br>// ... 业务逻辑 ...<br>if ($this->db->trans_status() === FALSE) {<br> $this->db->trans_rollback();<br> $this->error_response('操作失败');<br>} else {<br> $this->db->trans_commit();<br> $this->success_response($result);<br>}<br>``` |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`create_community_shop_book_order()` | **模型层越权抛出全局错误**：模型中直接调用 `throwError()`。模型应仅负责数据操作并返回状态数组，错误提示应由控制器统一处理。直接抛出全局错误破坏 MVC 分层，且可能暴露敏感堆栈。 | 改为返回标准状态数组，由控制器拦截并调用 `$this->error_response()`。 | ```php<br>// 模型内<br>if (empty($theme)) {<br> return ['status' => false, 'msg' => '请选择聚会类型'];<br>}<br>// 控制器内<br>$res = $this->model->create(...);<br>if (!$res['status']) $this->error_response($res['msg']);<br>``` |
| 🟠 警告 | `Ahead_shop_config_second_model.php`<br>`get_shop_setting()` | **巨型 Switch 语句违反单一职责**：超过 100 个 `case`，维护成本极高，每次调用均需线性匹配，且硬编码默认值分散。 | 使用配置映射数组或动态属性解析，集中管理默认值与转换逻辑。 | ```php<br>private $config_map = [<br> 'book_trial_time' => ['default' => 0, 'transform' => 'intval'],<br> 'turn_on_the_ac_early' => ['default' => 10],<br> // ...<br>];<br>public function get_shop_setting(..., $field) {<br> $map = $this->config_map[$field] ?? ['default' => ''];<br> $val = $data[$field] ?? $map['default'];<br> return isset($map['transform']) ? $map['transform']($val) : $val;<br>}<br>``` |
| 🟠 警告 | `Ahead_shop_config_second_model.php`<br>`self::$shop_config` | **静态缓存无清理机制**：使用静态数组缓存门店配置。在 PHP-FPM 中虽安全，但在长驻内存环境（Swoole/Workerman）或 CLI 脚本中会导致内存泄漏与数据陈旧。 | 建议改用 CI 的 Cache 驱动（Redis/Memcached）或增加 TTL 与 `clearCache()` 方法。 | ```php<br>public function clear_config_cache($shop_id = null) {<br> if ($shop_id) unset(self::$shop_config[$shop_id]);<br> else self::$shop_config = [];<br>}<br>``` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`send_success_msg()` / `refund_by_notify()` | **敏感数据明文记录日志**：`doLog(var_export($order_data, true), ...)` 可能将用户手机号、支付金额、交易流水号等敏感信息写入服务器日志，违反数据安全规范。 | 日志脱敏，仅记录关键 ID、状态码或掩码后的数据。 | ```php<br>$safe_log = [<br> 'order_id' => $order_data['_id'],<br> 'status' => $order_data['_status'],<br> 'mobile_mask' => substr($order_data['_book_mobile'], 0, 3) . '****' . substr($order_data['_book_mobile'], -4)<br>];<br>doLog(json_encode($safe_log), 'BookOrder');<br>``` |
| 🟠 警告 | `Book.php`<br>`checkBookReceipt()` | **死代码阻断业务逻辑**：`if (false && $order_id)` 导致后续邀请函判断逻辑永远不执行，属于无效代码。 | 移除 `false &&`，或根据产品需求恢复该分支逻辑。 | `if ($order_id) { ... }` |
| 🟡 建议 | `Ahead_shop_config_second_model.php`<br>`deal_audio_content_params()` | **语法瑕疵与命名不一致**：`$params_map = [...] ;;` 存在多余分号。模型加载大小写混用（如 `load->model('Ahead_...')`），在 Linux 文件系统下可能因大小写敏感导致 `Class not found`。 | 修复语法错误，统一使用小写模型名（CI 规范）。 | `$params_map = [...];`<br>`$this->load->model('ahead_user_party_video_model');` |
| 🟡 建议 | `Book.php` 全文件 | **重复加载模型/库**：多个方法中重复调用 `$this->load->model()` 与 `$this->load->library()`。CI 虽会缓存已加载实例，但频繁调用仍增加解析开销。 | 将高频使用的模型/库移至 `__construct()` 中统一加载。 | ```php<br>public function __construct() {<br> parent::__construct();<br> $this->load->model(['ahead_shop_book_time_info_model', 'ahead_book_order_model']);<br> $this->load->library('Tuangou');<br>}<br>``` |
> ⚠️ **局限性说明**：`Ahead_book_order_model.php` 末尾代码被截断（`if ($this->tuangou->verify_token) {` 后无内容），无法评估该分支的完整逻辑与潜在风险。请补充完整代码以便深度审查。
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修正事务控制逻辑**：将 `communityNotCleanChangeBook` 及其他涉及资金/状态变更的方法改为显式 `trans_begin()` / `trans_commit()` / `trans_rollback()` 模式，避免状态覆盖导致的数据不一致。
2. **剥离模型层全局错误抛出**：全面排查模型中的 `throwError()`、`exit()`、`die()` 调用，统一改为返回 `['status' => bool, 'msg' => string, 'data' => mixed]` 结构，由控制器层统一响应。
3. **清理文件级实例化代码**：将所有模型文件顶部的 `$CI = &get_instance();` 迁移至 `__construct()`，确保符合框架生命周期。
4. **日志脱敏处理**：对 `doLog` / `do_log` 中记录的订单、支付、用户信息进行掩码或字段过滤，防止敏感数据泄露。
### 🛠 后续重构与优化方向
- **配置获取逻辑重构**：将 `Ahead_shop_config_second_model::get_shop_setting()` 的巨型 `switch` 替换为 **策略模式** 或 **配置映射表**。可考虑将门店配置抽象为独立的 `ConfigService`，结合 Redis 缓存提升读取性能。
- **统一输入校验层**：当前 `$this->param` 直接透传至模型，缺乏边界校验。建议在控制器基类或中间件中引入 `Form_validation` 或自定义 DTO 校验，拦截非法参数（如越权 `shop_id`、非法时间格式、越权支付平台等）。
- **代码规范与现代化**：
- 遵循 PSR-12 规范，统一命名风格（如 `doLog` vs `do_log`）。
- 为公共方法添加 PHPDoc 类型声明（`@param`, `@return`），并在 PHP 7.4+ 环境下逐步引入类型提示（`string`, `int`, `array`）。
- 移除注释掉的废弃代码与 `if (false && ...)` 死逻辑，保持代码库整洁。
- **框架适配确认**：若项目确为 `phpci`，请核对官方文档中关于事务驱动、模型自动加载及错误处理的最佳实践。当前代码高度依赖 CI3 特性，若 `phpci` 有底层差异，需针对性调整。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780917691
|
1780917691
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
601
|
21
|
274
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `83c89ed41 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `83c89ed414e6697b8666f2aa438a02c8c575bdc3`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 19:29:15
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：代码实现了完整的预订、支付回调、退款及门店配置读取流程，业务逻辑覆盖较全面。但存在明显的 SQL 拼接隐患、事务管理不规范、魔法数字泛滥、方法职责过重等问题。整体偏向传统 CodeIgniter 3 风格，部分写法未充分利用现代 PHP 特性与框架最佳实践。末尾 `create_community_shop_book_order` 代码截断，无法评估完整逻辑。
- **风险等级**：🔴 高（主要源于 SQL 注入隐患、支付状态误判及退款单号并发冲突风险）
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`refund_by_notify` 方法内 | `$log_where` 使用字符串直接拼接订单 ID 构造查询条件，若 `_id` 未严格过滤或包含特殊字符，将导致 **SQL 注入** 或语法错误。 | 废弃字符串拼接，全面改用 CI 查询构建器（Query Builder）或参数绑定。 | `$this->db->where('_relation_id', $order_data['_id'])<br>->where('_status', 1)<br>->where_in('_type', [5, 13]);` |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`check_notify` 方法内 | 状态判断逻辑缺陷：当订单状态为 `3`（退款申请中）时，直接返回 `'支付成功'`。支付网关回调可能误认为交易完成，导致重复发货或资金对账混乱。 | 明确状态机流转。退款中应拦截回调或返回特定业务码，交由退款流程处理。 | `if (in_array($order_data['_status'], [1, 4])) { return ['status' => true, 'msg' => '支付成功']; }<br>if ($order_data['_status'] == 3) { return ['status' => false, 'msg' => '订单退款处理中', 'return' => 500]; }` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`refund_by_notify` 方法内 | 微信退款单号 `Out_refund_no` 仅使用 `date('YmdHis')` 生成。在高并发退款场景下极易重复，触发微信 `OUT_TRADE_NO_USED` 错误导致退款失败。 | 结合订单号、时间戳与随机数/微秒保证全局唯一性。 | `$input->SetOut_refund_no('RF' . $order_data['_id'] . '_' . time() . '_' . mt_rand(1000, 9999));` |
| 🟠 警告 | `Ahead_shop_config_second_model.php`<br>`get_shop_setting` 方法内 | 使用 `self::$shop_config[$shop_id]` 静态缓存配置，未区分 `merchant_id`，且无缓存失效机制。多租户或后台修改配置后，PHP-FPM 进程内将读取到脏数据。 | 缓存键需包含商户 ID，或提供 `clearCache()` 方法；建议接入框架 Cache 驱动（如 Redis/Memcached）替代静态变量。 | `$cache_key = "{$merchant_id}_{$shop_id}";<br>if (empty(self::$shop_config[$cache_key])) { ... }` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`check_notify` 方法内 | 事务管理混用：`$this->db->trans_start()` 配合 `try-catch` 手动 `trans_rollback()`。CI 框架在严格模式下会自动回滚，手动干预易引发事务状态不一致或死锁。 | 统一使用 `$this->db->trans_begin()` 与 `$this->db->trans_complete()`，移除 `catch` 中的手动回滚，依赖框架自动处理。 | `// 移除 try-catch 中的 $this->db->trans_rollback();<br>// 确保开启 $this->db->trans_strict(TRUE);` |
| 🟡 建议 | `Ahead_book_order_model.php` 全文 | 大量硬编码“魔法数字”（如状态 `-1,1,2,3,4,5`，支付平台 `1,3,8,9,14`，模板索引 `14`）。可读性差，后期维护极易出错。 | 提取为类常量或独立配置文件，使用语义化命名。 | `const STATUS_PENDING = -1; const STATUS_PAID = 1; const PAY_SCENE_WECHAT = '5';` |
| 🟡 建议 | `Ahead_book_order_model.php`<br>`refund_by_notify` 方法 | 方法体超过 250 行，混合了支付网关调用、状态更新、日志记录、消息推送、财务流水等逻辑，严重违反单一职责原则（SRP）。 | 拆分为独立 Service 类或私有方法，如 `processGatewayRefund()`, `updateOrderStatus()`, `notifyUserAfterRefund()`。 | 将支付网关逻辑抽离至 `PaymentRefundService::refund()`，模型仅负责数据持久化。 |
| 🟡 建议 | `Ahead_book_order_model.php`<br>文件顶部 | 全局作用域调用 `$CI = &get_instance();` 违反 CI 模型规范，易导致上下文污染、内存泄漏及单元测试困难。 | 删除文件顶部全局调用。在方法内部按需获取，或在模型构造函数中初始化。 | `// 删除顶部 $CI = &get_instance();<br>public function __construct() { parent::__construct(); $this->ci =& get_instance(); }` |
| 🟡 建议 | `Ahead_book_order_model.php`<br>`get_detail` 方法内 | 变量拼写错误 `$rooom_data`；日志函数命名不统一（`doLog` 与 `do_log` 混用）；数组语法混用 `array()` 与 `[]`。 | 修正拼写，统一日志函数命名；全面采用短数组语法 `[]` 以符合 PSR-12。 | `$room_data = ...; do_log(...);` |
| 🟡 建议 | `Ahead_shop_config_second_model.php`<br>`get_shop_setting` 方法 | 庞大的 `switch` 语句中直接加载模型并查询数据库，导致模型层职责越界，且每次调用都会触发重复查询。 | 将字段映射与业务逻辑解耦。模型仅返回原始数据，字段转换逻辑移至 Helper 或 Service 层。 | `$raw = $this->get_one(...);<br>return ConfigTransformer::transform($raw, $field);` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **修复 SQL 注入隐患**：立即将 `refund_by_notify` 中的 `$log_where` 和 `$log_up` 字符串拼接替换为 CI Query Builder 链式调用或预处理语句。
2. **修正支付回调状态机**：重新梳理 `check_notify` 的状态拦截逻辑，确保 `退款申请中(3)` 不会误报为支付成功，避免资金与订单状态不一致。
3. **保证退款单号唯一性**：修改 `Out_refund_no` 生成规则，引入订单 ID 或唯一标识符，防止高并发下微信/银联退款接口报错。
### 🛠 后续重构与优化方向
1. **架构分层与职责拆分**：当前 Model 承担了过多业务逻辑（支付网关、消息推送、财务流水）。建议引入 `Service` 层处理复杂业务流程，Model 仅负责数据读写与基础校验。
2. **统一配置与常量管理**：将散落在各处的状态码、支付平台标识、微信模板 ID 提取至 `config/constants.php` 或独立配置类，提升代码可维护性。
3. **缓存策略升级**：`self::$shop_config` 静态缓存在 PHP-FPM 环境下存在生命周期与脏读问题。建议迁移至 Redis/Memcached，并设置合理的 TTL 与主动失效机制。
4. **规范事务与异常处理**：全面采用 `$this->db->trans_begin()` / `$this->db->trans_complete()` 标准范式。移除冗余的 `try-catch` 手动回滚，利用框架的 `trans_strict` 特性保证数据一致性。
5. **补充缺失代码审查**：`create_community_shop_book_order` 方法末尾被截断，请补充完整代码以便进行闭环逻辑与事务安全性的二次审查。
> 💡 **框架适配说明**：代码呈现典型的 CodeIgniter 3 架构特征。若 `phpci` 为基于 CI 二次开发的内部框架，上述建议完全兼容。若为独立框架，请确保 `$this->db` 事务驱动与模型加载机制与 CI 保持一致，或查阅官方文档替换为对应框架的 ORM/Query Builder 语法。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780918155
|
1780918155
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
602
|
21
|
275
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 退款相关
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `9e330f661 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `9e330f6615f1fce5d8b7d337f49e1b4b012fd4d3`
**提交人**: linyangrui (yangruilin888@gmail.com)
**时间**: 2026-06-08 19:35:23
---
## 📋 审查摘要
- **变更文件数**: 4
- **严重问题**: 0
- **高危问题**: 4
- **中危问题**: 2
- **建议优化**: 3
> 💡 **注**：提供的代码为微信小程序前端 JavaScript 代码，非 PHP CodeIgniter 框架代码。已按前端模块化规范进行跨文件引用与逻辑审查。
## 🐛 发现的问题
### <font color="red">[跨文件调用] 调用了未定义的 OrderModel 和 CabinetModel 类</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 第 4-5 行
- **问题描述**: 代码中通过 `import {OrderModel} from '../../../models/order.js'` 和 `import {CabinetModel} from '../../../models/cabinet.js'` 引入了两个模型类，但在提供的项目结构与变更文件中均未找到对应文件。若实际项目中不存在这两个文件，将直接导致模块加载失败或 `ReferenceError`。
- **修复建议**: 确认 `models/order.js` 与 `models/cabinet.js` 是否已创建并正确导出。若尚未实现，需补充对应模型文件，或暂时注释相关调用逻辑。
### <font color="red">[跨文件调用] 依赖模块路径不一致可能导致加载失败</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/apply-result/apply-result.js` 与 `order-detail.js`
- **行号**: 第 2 行 (apply-result.js) / 第 2 行 (order-detail.js)
- **问题描述**: `apply-result.js` 使用 `import {config} from '../../../config'`（无后缀），而 `order-detail.js` 使用 `import {config} from '../../../config.js'`（带 `.js` 后缀）。在部分小程序构建工具或严格模式下，路径解析规则不一致可能导致模块解析失败或缓存冲突。
- **修复建议**: 统一引入路径规范，建议全部显式添加 `.js` 后缀：`import {config} from '../../../config.js'`。
### [逻辑 BUG] 未判空直接访问对象属性导致运行时崩溃
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 第 108 行
- **问题描述**: `const uid = wx.getStorageSync('userInfo').uid || ''` 直接链式调用。若本地缓存中不存在 `userInfo` 键，`wx.getStorageSync` 返回 `undefined`，访问 `.uid` 将抛出 `TypeError: Cannot read properties of undefined`，导致页面白屏。
- **修复建议**: 增加安全判空逻辑：
```javascript
const userInfo = wx.getStorageSync('userInfo');
const uid = userInfo && userInfo.uid ? userInfo.uid : '';
```
### [逻辑 BUG] API 响应结果未做防御性判空
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 第 128, 145, 168 等多处
- **问题描述**: 在 `getOrderDetail`、`getMyRoomOrderDetail`、`handleOpenMachineResult` 等方法中，频繁直接访问 `res.result.xxx`。若网络异常、后端返回格式变更或拦截器未正确包装，`res` 或 `res.result` 为 `undefined` 时将引发连续崩溃。
- **修复建议**: 在回调入口处增加防御性检查，或使用可选链操作符：
```javascript
// 示例修复
const result = res && res.result ? res.result : {};
// 后续使用 result.xxx
```
### [安全隐患] URL 参数拼接未使用 encodeURIComponent 导致路由解析异常
- **严重程度**: 中危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 第 195, 218, 230 等多处 `wx.navigateTo` 调用
- **问题描述**: 页面跳转时直接使用字符串拼接 `?order_id=' + this.data.order_id + '&...'`。若参数值中包含 `&`、`=`、`?` 或特殊字符（如中文、空格），将破坏 URL 结构，导致目标页面 `options` 解析错乱或丢失参数。
- **修复建议**: 对所有动态参数使用 `encodeURIComponent()` 包裹：
```javascript
url: `/pages/community-reserve/apply-refund/apply-refund?order_id=${encodeURIComponent(this.data.order_id)}&actual_pay=${encodeURIComponent(this.data.order_detail.actual_pay)}`
```
### [代码质量] 确认弹窗按钮状态冗余赋值
- **严重程度**: 低危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 第 288-290 行
- **问题描述**: 在 `handleOpenMachineResult` 的 `type == 2` 分支中，`showCancelBtn: false` 被连续赋值了两次，属于无效冗余代码。
- **修复建议**: 删除重复的 `showCancelBtn: false,` 赋值语句。
### [代码质量] 魔法值硬编码与重复逻辑未抽离
- **严重程度**: 低危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js` & `reserve.js`
- **行号**: 多处
- **问题描述**:
1. `order_type` 转换逻辑 `this.data.bigType == 'book' ? '2' : '1'` 在文件中重复出现 4 次。
2. `operational_scene` 的文案映射使用多个 `if/else if` 硬编码判断，可维护性差。
3. `reserve.js` 中每个请求都重复编写 `error: (err) => { console.log(err) }`。
- **修复建议**:
1. 抽离为计算属性或工具函数：`getOrderType() { return this.data.bigType === 'book' ? '2' : '1'; }`
2. 使用配置对象映射场景文案：`const SCENE_MAP = { 1: '包厢', 2: '桌台', 3: '包厢', 4: '卡台' };`
3. 在 `HTTP` 基类中统一设置默认 `error` 回调，子类无需重复声明。
## ✅ 代码亮点
1. **模型层封装规范**：`reserve.js` 将业务 API 请求集中管理，采用 ES6 Class 继承 `HTTP` 基类，结构清晰，便于后期统一拦截、加签或 Mock。
2. **状态机处理清晰**：`handleOpenMachineResult` 对开机结果的不同 `type`（成功、提前开机、包厢错误、未清扫等）进行了明确分支处理，业务逻辑覆盖较全。
3. **用户体验细节**：在关键操作（退款、变更、结束订单）前增加了二次确认弹窗，并对不可退款/不可变更场景给出了明确的 Toast 提示，符合 C 端产品交互规范。
## 📝 总体建议
1. **防御性编程**：小程序前端极易受网络波动或后端数据结构变更影响。建议在所有 API 回调入口处统一增加 `if (!res || !res.result) return;` 或采用可选链 `?.`，避免单点崩溃导致整个页面不可用。
2. **跨文件依赖治理**：当前审查发现 `OrderModel`、`CabinetModel` 及 `HTTP` 工具类未在提供上下文中定义。建议在项目根目录维护一份 `依赖清单` 或使用 TypeScript 进行类型约束，提前暴露引用断裂问题。
3. **路由参数标准化**：强烈建议封装一个统一的 `navigateTo` 工具函数，自动处理 `encodeURIComponent` 和参数序列化，避免全量手动拼接带来的隐患。
4. **常量集中管理**：将 `operational_scene`、`order_type`、`status` 等业务枚举值抽离至独立的 `constants.js` 文件中，提升代码可读性与后期维护效率。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780918523
|
1780918523
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
604
|
21
|
276
|
1
|
|
0
|
需求 订单回执
|
|
0
|
0
|
1
|
1
|
0
|
|
0
|
1780970563
|
1780970680
|
1780970571
|
0
|
0
|
0
|
Edit
Delete
|
|
605
|
21
|
277
|
1
|
|
0
|
需求 订单回执
|
|
0
|
0
|
1
|
1
|
0
|
|
0
|
1780970586
|
1780970601
|
1780970601
|
0
|
0
|
0
|
Edit
Delete
|
|
607
|
21
|
278
|
1
|
|
0
|
🔍 代码审查报告：pay - Merge pull request '需求 订单回执' 🔍 代码审查报告：pay - Merge pull request '需求 订单回执' (#276) from pay-26051...
|
## 自动代码审查报告
**分支**: pay
**提交**: `4d40b955cab3e5be ## 自动代码审查报告
**分支**: pay
**提交**: `4d40b955cab3e5bede94a249da333a532ffec85e`
**提交人**: zhangjunnan (121158035@qq.com)
**时间**: 2026-06-09 10:04:40
---
## 1. 审查摘要
- **代码质量评分**：4.5 / 10 分
- **总体评价**：代码已实现核心业务链路，但存在大量历史技术债。测试接口与生产逻辑混杂，硬编码敏感数据严重；输入输出未遵循框架规范，直接使用超全局变量与 `exit/die` 破坏生命周期；部分逻辑使用 `goto` 与 JS 服务端跳转，可维护性与安全性较低。JS 端存在明显重复代码。
- **风险等级**：🔴 高
> 📌 **框架说明**：经分析，代码结构特征（`BASEPATH`、`get_instance()`、`$this->load->model()` 等）高度符合 **CodeIgniter 3** 规范。若 `phpci` 为内部定制框架，以下审查仍基于 CI3 核心机制与通用 PHP 最佳实践，请结合内部文档微调。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `TestHlj.php` / `getCommunityShopBookHours` | 硬编码包含验签 Token、订单号、加密串的完整 JSON 字符串。极易导致敏感凭证泄露，且测试数据污染生产环境。 | 移除硬编码，改用配置文件/环境变量。测试接口应通过路由中间件或环境标识隔离，禁止直接暴露在生产路由中。 | `// 移除硬编码，改为：<br>$voucher_info = $this->config->item('test_voucher_info');` |
| 🔴 严重 | `ScreenApi.php` / 顶部 Header | `header("Access-Control-Allow-Origin:*");` 允许任意域名跨域请求，结合未做签名校验的 API，极易遭受 CSRF 或恶意刷单攻击。 | 限制可信域名白名单，或使用 CI 的 CORS 配置动态输出。API 接口必须增加签名/Token 校验机制。 | `header("Access-Control-Allow-Origin: " . $this->config->item('allowed_origins'));` |
| 🔴 严重 | `TestHlj.php` & `ScreenApi.php` / `__construct` | 直接使用 `$_REQUEST['json']` 和 `php://input` 解析 JSON，未做异常捕获与格式校验。非法请求会导致 `json_decode` 返回 `null`，引发后续数组越界或类型错误。 | 封装安全的 JSON 解析方法，增加 `json_last_error()` 校验，并统一使用 CI 的输入流处理。 | `见下方【安全解析示例】` |
| 🟠 警告 | `ScreenApi.php` / `case "2001"` | 使用 `goto famail_close;` 控制业务流程。严重破坏代码可读性，易导致变量作用域混乱与状态不一致，违反现代 PHP 编码规范。 | 将关房后逻辑提取为独立私有方法，使用 `return` 或 `break` 控制流程，彻底移除 `goto`。 | `// 提取为：<br>private function handleCloseRoomAfter($family_data, $open_room_data) { ... }` |
| 🟠 警告 | `TestHlj.php` / `updateShopShiftTurnoverCount` | 使用 `<script>window.location.href=...` 在服务端实现循环/分页跳转。强依赖客户端执行，易被拦截、导致死循环，且长时间占用 PHP-FPM 进程。 | 改用服务端异步任务（Redis 队列 + Cron）或前端 AJAX 轮询。避免在控制器中输出 HTML/JS 控制流。 | `// 推荐：将任务推入队列，前端通过轮询接口获取进度` |
| 🟠 警告 | `Neworderservice.php` / `getOrderTypeInfo` | 循环内重复加载模型、频繁浮点运算，且遗留 `echo $vip_upgrade_data_actual_pay;` 调试代码。破坏接口纯净度，影响性能与日志输出。 | 模型移至构造函数；金额计算统一使用 `bcmath` 或 `number_format`；彻底清理 `echo/var_dump`。 | `// 删除 echo 语句<br>// 金额计算改用：bcmul($price, $qty, 2)` |
| 🟡 建议 | `apply.js` & `new-room.js` | 两个页面重复实现 `onLoad`、`onReady` 及导航栏高度计算逻辑，违反 DRY 原则，后期维护成本高。 | 提取为公共 Mixin 或工具函数（如 `utils/nav.js`），通过 `require` 或全局混入复用。 | `// utils/nav.js<br>export const initNavHeight = (page) => { ... }` |
| 🟡 建议 | 全局 PHP 文件 | 命名规范不统一（驼峰/下划线混用），大量 `//add by nan` 行内注释，缺乏类型声明与 PHPDoc，不符合 PSR-12。 | 统一遵循 PSR-12，使用 Git 追踪变更，移除行内作者标记，补充方法级 PHPDoc 与参数类型提示。 | `/** @param array $params @return array */<br>public function getShopList(array $params): array` |
### 🔧 关键代码修改示例（安全解析与输出规范）
```php
// ✅ 推荐：安全的 JSON 解析方法（可放入 Base Controller）
protected function parseJsonInput()
{
$raw = $this->input->raw_input_stream ?: ($_REQUEST['json'] ?? '');
$data = json_decode($raw, true);
if (json_last_error() !== JSON_ERROR_NONE) {
$this->jsonEcho([], 'JSON格式解析失败', 400);
}
return $data ?: [];
}
// ✅ 推荐：遵循 CI3 生命周期的 JSON 响应
public function jsonEcho($response = [], $msg = '成功', $code = 0)
{
$result = [
'code' => $code,
'msg' => $msg,
'result' => $response,
'time' => time(),
];
if ($code > 0 && $code != 999) {
unset($result['result']);
}
// 使用 CI 输出类，避免手动 ob_* 和 die()
$this->output
->set_content_type('application/json; charset=utf-8')
->set_output(json_encode($result, JSON_UNESCAPED_UNICODE));
}
```
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **隔离测试与生产代码**：立即将 `TestHlj.php` 中的硬编码凭证、测试 Token、`var_dump` 及 `exit` 逻辑移除或迁移至独立的测试环境控制器。生产路由严禁暴露调试接口。
2. **统一输入输出处理**：废弃 `$_REQUEST`、`$_GET` 直接取值，全面改用 CI 的 `$this->input->get()` / `$this->input->post()` 或封装的 `parseJsonInput()`。替换所有 `echo + die()` 为 `$this->output->set_output()`。
3. **修复高危安全配置**：移除 `Access-Control-Allow-Origin: *`，配置可信域名白名单；为 `ScreenApi` 等外部接口增加签名验证（Timestamp + Nonce + Sign）防重放攻击。
### 🛠 后续重构与优化方向
1. **架构分层与 DRY 原则**：
- 将 `ScreenApi.php` 中庞大的 `switch-case` 拆分为独立的 Service 类（如 `TouchScreenService`），控制器仅负责路由分发与参数校验。
- 提取 `TestHlj.php` 与 `ScreenApi.php` 中重复的模型加载逻辑至基类控制器或构造函数。
2. **性能与计算优化**：
- `Neworderservice.php` 中的价格计算逻辑极其复杂，建议引入策略模式处理不同订单类型。金额运算全面切换至 `bcmath` 扩展，避免浮点精度丢失。
- 循环内禁止数据库查询，使用 `WHERE IN` 批量获取数据后在 PHP 层映射。
3. **规范化与工程化**：
- 引入 PHP-CS-Fixer 或 PHP_CodeSniffer 强制 PSR-12 规范。
- 清理所有 `//add by xxx` 注释，依赖 Git Blame 追溯变更。
- 为小程序 JS 端建立公共工具库（如导航栏计算、路由跳转封装），减少页面级冗余代码。
> 💡 **提示**：若当前系统处于快速迭代期，建议优先完成 **安全隔离** 与 **输入输出规范化**，再逐步推进 Service 层拆分与计算逻辑重构。对于不确定的 `phpci` 框架特定生命周期钩子，请查阅内部文档确认是否支持 CI3 的 `$this->output` 机制，必要时可适配框架原生响应类。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780970680
|
1780970680
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
608
|
21
|
279
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - Merge remote-tracking branch 🔍 代码审查报告：pay-260616 - Merge remote-tracking branch 'pay/pay' into pay-26...
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `37a972f9c ## 自动代码审查报告
**分支**: pay-260616
**提交**: `37a972f9c73935580738d52261c1c00d425ffbff`
**提交人**: zhangjunnan (121158035@qq.com)
**时间**: 2026-06-09 10:16:19
---
## 1. 审查摘要
- **代码质量评分**：4.5 / 10 分
- **总体评价**：当前代码呈现典型的“调试脚本与生产逻辑混杂”状态。核心业务控制器中充斥大量硬编码、未经验证的超全局变量读取及直接 `exit/die` 操作；订单服务类方法过长、职责不清，且存在浮点数计算金额、循环内查库等隐患；模型层事务控制与外部 API 调用耦合过深。整体不符合现代 PHP 工程规范，存在较高的安全与稳定性风险。
- **风险等级**：🔴 高
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `TestHlj.php`<br>`niubilityTest`/`jhGiftTest`/`vipRechargeNotify` | **支付回调未验签且依赖 `$_GET`**。直接通过 GET 参数接收订单号与交易流水，未进行签名验证、防重放攻击或幂等性校验，极易被恶意伪造请求导致资损或数据错乱。 | 1. 支付回调必须使用 `POST` 或读取 `php://input` 原始数据。<br>2. 严格校验支付平台签名（如微信 `sign`、通联 `sign`）。<br>3. 增加订单状态幂等判断，避免重复处理。 | ```php<br>// 错误<br>$notifyArr = ['out_trade_no' => $_GET['order_id']];<br><br>// 正确<br>$rawInput = file_get_contents('php://input');<br>$notifyData = json_decode($rawInput, true) ?: $_POST;<br>$this->verifyPaySign($notifyData); // 验签逻辑<br>$this->handlePayCallback($notifyData);<br>``` |
| 🔴 严重 | `TestHlj.php`<br>`getTimePackageList()` | **未定义变量直接调用**。`$this->room_data['_id']` 在该方法作用域内未初始化，将触发 `Undefined property` 错误并导致后续逻辑中断。 | 修正为已查询的 `$room_data['_id']`，并增加空值保护。 | ```php<br>// 错误<br>$operational_scene = $room_operational_scene[$this->room_data['_id']] ?? '1';<br><br>// 正确<br>$operational_scene = $room_operational_scene[$room_data['_id']] ?? '1';<br>``` |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`check_notify()` | **事务提交位置不严谨**。`$this->db->trans_complete()` 被包裹在 `if (!$this->update(...)) { ... } else { ... }` 的 `else` 分支中。若 `update` 失败走 `else` 外的逻辑，事务可能处于未提交/未回滚的悬空状态。 | 将 `trans_complete()` 移至 `try` 块末尾，或使用 CI 的 `trans_start()` + `trans_complete()` 自动提交机制，配合 `try-catch` 统一回滚。 | ```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>``` |
| 🟠 警告 | `Neworderservice.php`<br>全局多处 | **浮点数直接计算金额**。如 `$actual_pay = $goods['_actual_amount'] * $goods['_quantity'];` 及多次 `/100` 操作，PHP 浮点运算存在精度丢失风险（如 `0.1+0.2=0.30000000000000004`），财务场景极易引发对账差异。 | 金额统一转为“分”（整数）计算，或使用 `bcmath` 扩展函数（`bcadd`, `bcmul`, `bcdiv`）。 | ```php<br>// 推荐：使用 bcmath<br$actual_pay = bcmul($goods['_actual_amount'], $goods['_quantity'], 2);<br>// 或统一转分计算后除以 100<br$actual_pay = ($goods['_actual_amount_cents'] * $goods['_quantity']) / 100;<br>``` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`get_list()`<br>`Neworderservice.php` 多处 | **循环内加载模型/执行查询（N+1 问题）**。在 `foreach` 中反复调用 `$this->load->model()` 或单条查询，导致数据库连接频繁建立与查询爆炸。 | 1. 模型应在构造函数或框架自动加载中初始化。<br>2. 使用 `WHERE IN` 批量查询，或在循环外预加载数据到内存数组。 | ```php<br>// 错误<br>foreach ($order_info as &$v) {<br> $merchant_data = $this->ahead_merchant_model->get_one(['_id' => $v['merchant_id']]);<br>}<br><br>// 正确<br>$merchant_ids = array_column($order_info, 'merchant_id');<br>$merchants = $this->ahead_merchant_model->get_list(['_id' => $merchant_ids]);<br>$merchant_map = array_column($merchants, null, '_id');<br>``` |
| 🟠 警告 | `TestHlj.php`<br>`jsonEcho()` | **绕过框架输出组件并强制终止**。使用 `ob_end_clean()` + `ob_start()` + `flush()` + `die()` 手动输出 JSON，破坏了 CI 框架的 Hook 机制、日志记录与全局异常捕获。 | 使用框架标准输出方式，保持请求生命周期完整。 | ```php<br>// 推荐<br>$this->output<br> ->set_content_type('application/json')<br> ->set_status_header($code)<br> ->set_output(json_encode($result, JSON_UNESCAPED_UNICODE));<br>``` |
| 🟡 建议 | `TestHlj.php`<br>全局 | **大量魔法数字与硬编码**。如 `merchant_id = 1281`、`uid = 66`、`JSON_UNESCAPED_UNICODE` 硬编码为 `256`、测试 Token 直接写死。降低可维护性且易引发生产事故。 | 1. 提取至配置文件或环境变量。<br>2. 测试代码与生产接口严格分离，使用 `ENVIRONMENT` 常量控制。 | ```php<br>// config/test.php<br>return ['default_merchant_id' => 1281, 'test_uid' => 66];<br><br>// 控制器中<br>$this->config->load('test');<br>$merchant_id = $this->config->item('default_merchant_id');<br>``` |
| 🟡 建议 | `Neworderservice.php`<br>`getOrderTypeInfo()` | **方法过长且违反单一职责**。单个方法超 500 行，混合了商品校验、价格计算、会员折扣、服务费、优惠券抵扣、套餐组装等逻辑，可读性与可测试性极差。 | 拆分为独立策略类或 Service：`PriceCalculator`、`VipDiscountService`、`CouponDeductionService`、`OrderAssembler`。 | 建议采用策略模式重构 `switch($type)` 分支，每个订单类型交由独立的 `OrderTypeHandler` 处理。 |
> 📌 **框架适配说明**：代码实际遵循 **CodeIgniter 3** 规范（`BASEPATH`、`get_instance()`、`$this->load->model()`）。若项目确为 `phpci` 框架，请确认是否兼容 CI3 语法。以下建议基于 CI3/现代 PHP 最佳实践给出。
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **支付安全加固**：立即下线或增加鉴权的测试回调接口。所有支付回调必须实现签名验证、IP 白名单、订单状态幂等校验，并记录完整请求日志。
2. **修复致命逻辑缺陷**：修正 `getTimePackageList` 中的 `$this->room_data` 未定义问题；规范 `check_notify` 的事务边界，确保异常必回滚。
3. **金额计算精度**：全局替换浮点数金额运算为 `bcmath` 或整数分计算，避免财务对账纠纷。
4. **清理硬编码与测试代码**：将 `TestHlj.php` 中的调试接口迁移至独立测试模块或 CLI 脚本，生产控制器严禁保留硬编码 ID/Token。
### 🛠 后续重构与优化方向
- **架构分层**：当前 Controller 承担了路由、参数解析、业务调用、响应输出全部职责。建议引入 `Service` 层处理复杂业务（如订单创建、价格计算），`Controller` 仅负责参数校验与响应组装。
- **异步化改造**：`send_success_msg` 中同步调用微信模板消息、短信网关、第三方 API，严重拖慢接口响应。建议接入消息队列（Redis/RabbitMQ）异步发送。
- **统一响应与异常处理**：废弃 `jsonEcho` + `die()` 模式，使用框架全局异常处理器（`Exception Handler`）统一捕获 `throwError`，返回标准化 JSON 结构。
- **代码规范落地**：配置 `PHP_CodeSniffer` 或 `PHP-CS-Fixer` 强制遵循 PSR-12；移除注释掉的死代码；为关键方法添加类型声明（PHP 7.4+ `declare(strict_types=1)`）。
- **框架生命周期利用**：避免在方法内重复 `$this->load->model()`，应在 `__construct` 中预加载或启用 CI 自动加载；使用 `$this->output` 替代手动 `ob_*` 操作。
如需针对特定模块（如订单价格计算引擎、支付回调验签逻辑）提供详细重构代码或单元测试用例，可提供具体业务场景，我将进一步输出可落地的实施方案。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780971379
|
1780971379
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
622
|
21
|
280
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 包厢配送可以合并配送的增加判断起购数。
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `a2bcc6060 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `a2bcc6060a2ffddb47d4bf3df51c3a6cdf98f54c`
**提交人**: zhangjunnan (121158035@qq.com)
**时间**: 2026-06-09 10:50:05
---
## 1. 审查摘要
- **代码质量评分**：4 / 10 分
- **总体评价**：该 Model 承载了大量核心订单业务逻辑，但实现方式较为原始。存在 **SQL 注入风险、硬编码敏感密钥、循环内查询导致的严重性能瓶颈、关键写操作缺失事务** 等高危问题。代码规范与框架最佳实践偏离较大，魔法数字泛滥，方法职责过重（如 `get_bill_goods_info` 超 200 行），可维护性与扩展性较差。
- **风险等级**：🔴 高
> 📌 **框架说明**：从代码结构（`get_instance()`、`$this->load->model()`、`system/` 目录）判断，该代码基于 **CodeIgniter 3** 架构。若 `phpci` 为贵司内部定制框架，以下基于 CI 标准的审查建议同样适用。若存在差异，请以 `phpci` 官方文档为准。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_bill_goods_info` (~L340) | **SQL 注入漏洞**：使用字符串直接拼接构建查询条件 `$sql = '_unique_key="' . $unique_key . '" ...`，未进行参数绑定或转义，攻击者可构造恶意输入破坏查询或拖库。 | 废弃字符串拼接，全面使用框架提供的查询构建器（Query Builder）或预处理语句。 | `$this->db->where('_unique_key', $unique_key);`<br>`$this->db->where_in('_status', [1, 4]);` |
| 🔴 严重 | `confirm_receipt` (~L285) | **数据一致性风险**：连续执行两次 `insert` 写入订单状态流转记录，未包裹数据库事务。若第二次写入失败，将导致订单状态停留在“已送达”而非“已完成”，引发业务状态不一致。 | 使用框架事务机制包裹关键写操作，失败时自动回滚。 | `$this->db->trans_start();`<br>`$this->ahead_yc_order_process_model->insert($data1);`<br>`$this->ahead_yc_order_process_model->insert($data2);`<br>`$this->db->trans_complete();`<br>`if (!$this->db->trans_status()) { $this->db->trans_rollback(); return false; }` |
| 🔴 严重 | 类属性定义 (~L10) | **硬编码敏感信息 & 弱加密**：`public $encrypt = "Vs!Fs7VT";` 将密钥明文暴露在源码中；且 `md5()` 校验签名易受彩虹表破解，且未使用防时序攻击比对。 | 密钥移至 `config/` 或环境变量；签名校验改用 `hash_equals()`；敏感数据加密建议改用 `openssl_encrypt()` 或框架内置 Encryption 库。 | `if (hash_equals($expected_sign, $sign)) { return true; }` |
| 🟠 警告 | `get_list` (~L135) | **严重性能瓶颈 (N+1 查询)**：在 `foreach` 循环中动态 `load->model` 并执行 `get_one`。若列表返回 50 条数据，将触发 50+ 次独立 SQL 查询与模型加载，极易导致数据库连接耗尽与接口超时。 | 模型统一在 `__construct` 加载；使用 `WHERE IN` 批量查询关联数据，或在数据库层使用 `JOIN` 一次性拉取。 | `$ids = array_column($order_info, 'package_id');`<br>`$this->db->where_in('_id', $ids)->get('ahead_room_package')->result_array();` |
| 🟠 警告 | `get_detail` (~L220) | **逻辑/变量错误**：`$order_data['before_payment'] = ...` 中 `$order_data` 未定义（应为 `$order_info`）；且 `$this->ahead_yc_order_model->get_one()` 在自身类中调用冗余且易引发递归加载。 | 修正变量名，直接使用 `$this->get_one()` 查询当前表数据。 | `$before_order = $this->get_one(['_id' => $order_info['before_order_id']], '_actual_pay');`<br>`$order_info['before_payment'] = $before_order['_actual_pay'] ?? '';` |
| 🟠 警告 | 全局/多处 | **模型重复加载**：每个方法内部频繁调用 `$this->load->model()`，违反框架最佳实践，增加文件 I/O 与内存开销。 | 统一在 `__construct()` 中加载依赖模型，或配置 `autoload.php` 自动加载。 | `public function __construct() { parent::__construct(); $this->load->model(['ahead_room_package_model', 'ahead_yc_order_extension_model']); }` |
| 🟡 建议 | 全文件 | **命名规范不一致**：方法名混用驼峰 (`bindingOrder`) 与下划线 (`binding_order_check`)；数组与常量定义重复 (`$pay_id_arr` vs `const ORDER_PAY_PLATFORM_ARR`)。 | 遵循 PSR-12 统一使用下划线命名法；将映射关系收敛至 `config/` 目录或单一常量类，避免散落。 | `const PAY_PLATFORM_MAP = [1 => '微信', 2 => '支付宝', ...];` |
| 🟡 建议 | `get_bill_goods_info` (~L350) | **魔法数字泛滥**：大量硬编码状态值（如 `1, 2, 10, 14, -1`）散落在业务逻辑中，可读性差且修改易遗漏。 | 提取为类常量或枚举（PHP 8.1+），并在逻辑判断中引用常量。 | `if ($order['_pay_platform'] === self::ORDER_VIP_PAY_PLATFORM) { ... }` |
## 3. 总结与行动建议
### 🚨 优先修复（P0/P1）
1. **修复 SQL 注入**：立即替换 `get_bill_goods_info` 中的字符串拼接查询，全面改用 `$this->db->where()` / `$this->db->where_in()`。
2. **补充数据库事务**：为 `confirm_receipt`、`bindingOrder` 等涉及多表写入或状态流转的方法添加 `$this->db->trans_start()` / `$this->db->trans_complete()` 机制。
3. **消除循环内查询**：重构 `get_list` 与 `get_detail`，将模型加载移至构造函数，使用批量查询或 `JOIN` 替代 `foreach` 中的单条查询。
4. **移除硬编码密钥**：将 `$encrypt` 迁移至配置文件，签名校验替换为 `hash_equals()`，避免安全审计不通过。
### 🛠 后续重构方向
1. **拆分巨型方法**：`get_bill_goods_info` 逻辑过于臃肿（超 300 行），建议按职责拆分为：`calculateBillTotals()`、`formatGoodsList()`、`handleSpecialPlatforms()` 等私有方法，提升可测试性。
2. **统一状态管理**：将散落的 `$pay_id_arr`、`$type_arr` 等映射数组迁移至 `application/config/order_status.php`，或使用 PHP 8.1 `enum` 管理，彻底消除魔法数字。
3. **补充类型声明**：建议为所有公开方法添加参数类型与返回值类型声明（如 `public function get_list(array $where, int $page, int $page_size): array`），提升 IDE 提示与静态分析能力。
4. **清理历史债务**：移除 `//add by nan 24.3.7` 等过时注释、被注释的废弃代码及未使用的局部变量，保持代码库整洁。
> ⚠️ **局限性说明**：您提供的代码在 `get_timing_order` 方法处被截断，未能完整审查该方法及后续可能存在的逻辑。建议补充完整代码后再次进行针对性审查。若 `phpci` 框架对事务、查询构建器或模型加载有特殊封装，请以官方文档为准进行适配调整。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780973405
|
1780973405
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
623
|
21
|
281
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `0cc49c079 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `0cc49c07974a677777bf4123cfd006e244468930`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-09 10:54:42
---
## 1. 审查摘要
- **代码质量评分**：6.0 / 10 分
- **总体评价**：业务逻辑覆盖全面，订单计价、会员折扣、套餐组合及退款流程设计较为完整。但存在**高危 SQL 注入隐患**、**资金计算精度缺失**、**事务边界混乱**及**调试代码残留**等严重问题。代码规范与框架最佳实践有较大优化空间。
- **风险等级**：🔴 高（涉及资金安全、数据一致性及系统稳定性）
> 📌 **框架说明**：提交代码中大量使用 `get_instance()`、`$this->load->model()`、`$this->db->trans_start()` 等语法，属于典型的 **CodeIgniter 3 (CI3)** 架构。`phpci` 实为持续集成服务器（CI/CD 工具），并非 PHP 框架。以下审查将严格基于 **CI3 最佳实践** 与 **PSR-12 规范** 进行。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Neworderservice.php`<br>约 330 行 | **SQL 注入风险**：`$pack_goods_where = "wares_package._package_id in (" . implode(",", $id_array['package_id']) . ")";` 未对数组元素进行类型过滤，若传入恶意字符串将直接拼接至 SQL。 | 强制类型转换或使用 CI 查询构建器 `where_in()`。 | `$ids = array_map('intval', $id_array['package_id']);`<br>`$this->db->where_in('wares_package._package_id', $ids);` |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`refund_by_notify` 方法内 | **SQL 注入风险**：`$log_where = '_relation_id="' . $order_data['_id'] . '" and _status=1 and _type in (5,13)';` 直接拼接变量至查询条件，未做转义或参数化。 | 使用 CI Query Builder 替代原生字符串拼接。 | `$this->db->where('_relation_id', $order_data['_id'])`<br>`->where('_status', 1)`<br>`->where_in('_type', [5, 13]);` |
| 🔴 严重 | `Neworderservice.php`<br>多处计价逻辑 | **资金计算精度丢失**：大量使用浮点数直接相乘/相加（如 `$goods_actual_pay = $v[$price_key] * $v['_quantity'];`），PHP 浮点数遵循 IEEE 754，易产生 `0.00000001` 级误差，导致对账失败。 | 涉及金额计算统一使用 `bcmath` 扩展或 `round()`，建议底层以“分”为单位计算。 | `$goods_actual_pay = round(bcmul($v[$price_key], $v['_quantity'], 2), 2);` |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`check_notify` 方法 | **事务边界混乱**：`try` 块内调用 `trans_complete()`，`catch` 块内又调用 `trans_rollback()`。若异常发生在 `trans_complete()` 之后，可能导致重复回滚或状态不一致。 | 移除 `try-catch` 中的手动回滚，统一使用 `trans_begin()` + `trans_status()` 显式控制。 | 见下方重构示例 |
| 🟠 警告 | `Neworderservice.php`<br>约 415 行 | **调试代码残留**：循环中存在 `echo $vip_upgrade_data_actual_pay;`，生产环境会破坏 JSON/XML 响应结构，导致前端解析崩溃。 | 立即删除或替换为日志记录。 | `log_message('debug', 'vip_upgrade_actual_pay: ' . $vip_upgrade_data_actual_pay);` |
| 🟠 警告 | `Neworderservice.php`<br>多个私有方法 | **重复加载模型**：在 `_create_insert_infos_data`、`get_goods_vip_price`、`getOrderTypeInfo` 中多次调用 `$this->CI->load->model()`，增加不必要的 I/O 开销。 | 将高频模型移至 `__construct()` 统一加载，或配置 `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_book_order_model.php`<br>`refund` 方法 | **事务外状态更新**：在开启事务前执行 `$this->update()` 将订单状态改为 4。若后续退款逻辑失败回滚，订单状态已变更，造成数据不一致。 | 将状态更新移入 `trans_start()` 之后，确保原子性。 | 将 `update` 语句移至 `$this->db->trans_start();` 下方 |
| 🟡 建议 | 全局文件 | **魔法数字泛滥**：硬编码如 `100`, `-1`, `9999999999999`, `13`, `14`, `58`, `56` 等散落各处，可读性差且后期维护成本极高。 | 提取为类常量或配置文件，如 `const STATUS_PENDING = -1; const DISCOUNT_BASE = 100;`。 | `const MAX_DEDUCT_AMOUNT = 9999999999999;`<br>`const PAY_SCENE_WX_BOOK = '5';` |
| 🟡 建议 | `Neworderservice.php`<br>约 480 行 | **重复赋值冗余**：`$result['service_charge'] = $service_charge;` 连续赋值两次，无实际意义。 | 删除冗余行，保持代码整洁。 | 直接删除重复行 |
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **立即修复 SQL 注入**：替换所有字符串拼接的 SQL 条件，全面改用 CI3 的 `$this->db->where()` / `where_in()` 或预处理语句。
2. **统一资金计算规范**：引入 `bcmath` 或封装 `MoneyCalculator` 类，所有金额运算强制保留 2 位小数，杜绝浮点数直接运算。
3. **修正事务控制逻辑**：
```php
// 推荐的事务控制模式（替代 trans_start/trans_complete 混用）
$this->db->trans_begin();
try {
// 执行所有数据库操作
if ($this->db->trans_status() === FALSE) {
$this->db->trans_rollback();
return ['status' => false, 'msg' => '数据库操作失败'];
}
$this->db->trans_commit();
return ['status' => true, 'msg' => '成功'];
} catch (\Exception $e) {
$this->db->trans_rollback();
log_message('error', 'Transaction failed: ' . $e->getMessage());
return ['status' => false, 'msg' => '系统异常'];
}
```
4. **清理生产环境调试代码**：全局搜索 `echo`、`var_dump`、`print_r`，替换为 `log_message()` 或移除。
### 🛠 后续重构与优化方向
- **架构解耦**：`Neworderservice.php` 承担了过多职责（计价、校验、组装、优惠券匹配）。建议拆分为 `OrderPricingService`、`CouponValidator`、`OrderAssembler`，符合单一职责原则。
- **常量与配置集中化**：将状态码、支付场景、折扣基数、最大抵扣额等提取至 `config/constants.php` 或类常量，提升可维护性。
- **模型加载优化**：CI3 支持自动加载，建议在 `application/config/autoload.php` 中配置高频模型/辅助函数，避免运行时重复 `load`。
- **规范对齐**：严格遵循 PSR-12 命名规范（类名 `PascalCase`，方法/属性 `camelCase` 或 `snake_case` 统一），清理历史注释（如 `//add by nan 22.07.11`），改用 Git Commit 记录变更。
- **安全加固**：对 `$order_data['_book_mobile']`、`$param['vip_card']` 等外部输入增加严格过滤与白名单校验；敏感操作（退款、状态变更）建议增加幂等性校验与操作日志审计。
> 💡 **提示**：若需针对 `phpci` 持续集成流水线配置代码扫描（如 PHP_CodeSniffer、PHPStan、SonarQube），可提供具体 CI 配置文件，我将为您补充自动化审查规则。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780973682
|
1780973682
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
624
|
21
|
282
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 1
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `732130eb7 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `732130eb7dd417124c37b2b955467fe175a093df`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-09 11:04:51
---
## 1. 审查摘要
- **代码质量评分**：4.5 / 10 分
- **总体评价**：代码实现了较为复杂的订单业务逻辑，但存在明显的架构设计缺陷。模型层承担了过多的业务逻辑与数据组装职责，导致方法冗长、可读性差。存在 SQL 注入隐患、N+1 查询性能瓶颈、事务缺失及弱加密算法等高风险问题。硬编码配置与魔法数字泛滥，不符合现代 PHP 工程规范。
- **风险等级**：🔴 高
> 📌 **框架说明**：根据目录结构（`system/helpers/`、`application/models/`、`get_instance()`、`$this->load->model()` 等）判断，该代码基于 **CodeIgniter 3** 架构。以下审查基于 CI3 规范与 PHP 7+ 最佳实践。若 `phpci` 为内部定制框架，请结合其官方文档调整部分建议。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `get_bill_goods_info` ~L200 | **SQL 注入风险**：使用字符串拼接构建查询条件 `_unique_key="' . $unique_key . '"`，未使用框架查询构造器或参数绑定，若 `$unique_key` 未严格过滤将导致注入。 | 改用 CI 查询构造器或参数化查询，彻底杜绝拼接。 | `$this->db->where('_unique_key', $unique_key)->where('_status IN(1,4)')->where('_timestamp >', time()-7*86400)->get()->result_array();` |
| 🔴 严重 | `confirm_receipt` ~L280 | **事务缺失导致数据不一致**：连续两次 `insert` 写入订单流程记录，若第二次失败，第一次已提交，导致订单状态处于中间态。 | 使用数据库事务包裹关键写入操作。 | `$this->db->trans_start(); $this->model->insert($data1); $this->model->insert($data2); $this->db->trans_complete();` |
| 🔴 严重 | `encode_group_buying_order` ~L430 | **弱加密/哈希滥用**：使用 `md5` 进行“加密/解密”验证。MD5 是单向哈希且已不安全，硬编码密钥 `$this->encrypt` 易泄露。 | 改用 `hash_hmac` 进行签名验证，密钥移至配置文件。 | `return hash_equals(hash_hmac('sha256', $order_id, config_item('group_buying_secret')), $sign);` |
| 🟠 警告 | `get_list` ~L110 | **N+1 查询性能瓶颈**：在 `foreach` 循环中逐条调用 `get_one()` 查询关联表，列表数据量稍大时将引发严重性能问题。 | 提取所有 `package_id`，使用 `WHERE IN` 批量查询，在内存中映射。 | `$ids = array_column($order_info, 'package_id'); $pkgs = $this->ahead_room_package_model->get_where_in('_id', $ids);` |
| 🟠 警告 | `close_room_after` ~L310 | **循环内单条更新**：`foreach` 中逐条执行 `update()`，频繁与数据库交互，增加锁竞争与 IO 开销。 | 收集所有待更新 ID，使用批量更新。 | `$ids = array_column($order_data, '_id'); $this->db->where_in('_id', $ids)->update($this->table_name, ['_process' => 10]);` |
| 🟠 警告 | 文件顶部 ~L4 | **全局实例化违反 MVC**：`$CI = &get_instance();` 在类外部执行，破坏 CI 生命周期，且 `$CI->load->model()` 未绑定到当前类。 | 移至类构造函数 `__construct()` 中，或依赖注入。 | `public function __construct() { parent::__construct(); $this->load->model('Simple_model'); }` |
| 🟠 警告 | `get_detail` ~L180 | **变量作用域错误与语法瑕疵**：`$order_data['before_payment']` 赋值后未使用；`$order_info['pay_scene_show']` 末尾多了一个分号 `;;`。 | 修正目标变量为 `$order_info`，清理多余符号。 | `$order_info['before_payment'] = $before_order_info_data['_actual_pay'] ?? '';` |
| 🟡 建议 | 全局多处 | **命名与规范不一致**：类名、方法名混用驼峰与下划线；大量魔法数字（如 `1,2,3,4,5...`）；`public $pay_id_arr` 与 `const` 重复定义。 | 遵循 PSR-12 统一蛇形命名；将配置移至 `config/` 文件；使用常量替代魔法数字。 | `const STATUS_PAID = 1; const PLATFORM_WECHAT = 1;` |
| 🟡 建议 | `get_vip_order` ~L340 | **模型越权访问 Session**：在 Model 中直接读取 `$CI->session`，破坏 MVC 分层与单元测试可行性。 | 将时间过滤条件作为参数传入，或在 Controller 层处理业务逻辑。 | `public function get_vip_order($merchant_id, $vipCardNo, $filter_3_months = false, ...)` |
| 🟡 建议 | `get_detail` / `confirm_receipt` | **全局函数依赖**：调用 `throwError()`、`minToStr()`、`send_wx_pay_order()` 等未定义全局函数，不利于框架集成与错误追踪。 | 封装为 CI Helper 或 Library，或使用 `show_error()` / 抛出 `Exception`。 | `throw new \RuntimeException('订单不存在');` |
## 3. 总结与行动建议
### 🚨 优先修复的关键问题
1. **修复 SQL 注入与事务缺失**：立即将 `get_bill_goods_info` 中的字符串拼接改为查询构造器；为 `confirm_receipt` 及所有涉及多表写入的方法添加 `$this->db->trans_start()/trans_complete()`。
2. **替换弱加密算法**：废弃 `md5` 签名方案，改用 `hash_hmac('sha256', ...)`，并将密钥 `$this->encrypt` 迁移至 `application/config/config.php` 或环境变量。
3. **消除 N+1 查询**：重构 `get_list` 与 `get_detail` 中的循环查询逻辑，采用 `WHERE IN` 批量拉取关联数据，或在数据库层使用 `JOIN` 一次性获取。
### 🛠 后续重构与优化方向
1. **职责分离（MVC 规范）**：当前 Model 承担了视图数据格式化（如 `date()`、`number_format()`、状态映射）与复杂业务编排。建议：
- 将状态映射数组移至 `config/` 文件。
- 将数据格式化逻辑移至 Controller 或独立的 `Service/Formatter` 类。
- Model 仅负责数据持久化与基础查询。
2. **拆分巨型方法**：`get_bill_goods_info` 超过 300 行，包含大量条件分支与数组操作。建议按业务场景拆分为 `getBillSummary()`、`getPaidGoods()`、`getUnpaidGoods()` 等私有方法，提升可测试性。
3. **统一常量与配置管理**：清理重复的 `public $xxx_arr` 与 `const`，统一使用类常量或配置文件。消除魔法数字，提升代码自解释能力。
4. **框架生命周期适配**：移除文件顶部的 `$CI = &get_instance();`，统一在 `__construct()` 中加载依赖。将全局函数 `throwError` 等替换为 CI 原生异常处理或自定义 Exception 类。
> ⚠️ **局限性说明**：提供的代码在 `get_timing_order` 方法末尾被截断（`return ['success' => false, 'msg' => '订单`），无法评估该方法的完整逻辑与异常处理。建议补充完整代码以便进行闭环审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780974291
|
1780974291
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
626
|
21
|
283
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - Merge remote-tracking branch 🔍 代码审查报告：pay-260616 - Merge remote-tracking branch 'pay/pay-260616' into...
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `5238ee526 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `5238ee526627d406578ac3282d622f260bdbdddc`
**提交人**: zhangjunnan (121158035@qq.com)
**时间**: 2026-06-09 11:16:45
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10
- **总体评价**：业务逻辑覆盖全面，能处理复杂的订单、会员、优惠券及多支付场景。但代码存在明显的生产环境调试残留、SQL拼接隐患、财务计算精度风险，且方法过长、魔法数字泛滥，严重违反单一职责原则（SRP）。整体可维护性与安全性有待大幅提升。
- **风险等级**：🔴 高
> 💡 **框架说明**：代码中大量使用 `defined('BASEPATH')`、`get_instance()`、`$this->load->model()` 等语法，实际为 **CodeIgniter 3** 架构。`phpci` 通常指持续集成平台，非 PHP 框架。以下建议均基于 CI3 最佳实践与 PSR-12 规范。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Neworderservice.php` (约第430行) | **调试代码未清理**：循环内存在 `echo $vip_upgrade_data_actual_pay;`，会破坏 API 响应结构（如 JSON 解析失败）或泄露内部数据。 | 立即移除所有 `echo`、`var_dump`、`print_r`。生产环境应使用日志组件记录。 | `// 删除该行`<br>`// 改为：doLog("升级金额计算: {$vip_upgrade_data_actual_pay}", 'vip_upgrade');` |
| 🔴 严重 | `Neworderservice.php` & `Ahead_yc_order_model.php` | **SQL 注入风险**：使用字符串拼接构造 `WHERE` 条件，如 `"_unique_key=\"" . $unique_key . "\""` 或 `implode` 拼接 `IN` 语句，未做参数绑定或转义。 | 全面改用 CI3 查询构建器（Query Builder）或参数化查询，杜绝手动拼接。 | `$this->db->where_in('_package_id', array_map('intval', $id_array['package_id']));`<br>`$this->db->where('_unique_key', $unique_key);` |
| 🔴 严重 | `Neworderservice.php` (约第470行) | **逻辑覆盖 Bug**：`$order['_prime_service_charge']` 被连续赋值两次，第二次 `$order['_prime_service_charge'] = $service_charge;` 覆盖了首次的 `$prime_after_paid_service_charge`，导致原始服务费数据丢失。 | 核对业务意图，保留正确变量名或重命名第二个字段。 | `$order['_prime_service_charge'] = $prime_after_paid_service_charge;`<br>`$order['_final_service_charge'] = $service_charge; // 明确区分` |
| 🟠 警告 | `Neworderservice.php` & `Ahead_book_order_model.php` | **浮点数精度丢失**：支付金额计算直接使用 `$total_amount * 100` 或 `sprintf("%.2f")`，PHP 浮点运算易产生 `0.00000000000001` 误差，导致支付网关拒单或对账不平。 | 财务计算必须使用 `bcmul()`、`bcadd()` 或 `intval(round($val * 100))`。 | `$total_fee = intval(round(bcmul($total_amount, '100', 2)));` |
| 🟠 警告 | `Neworderservice.php` | **重复加载模型**：在循环或多次调用中反复执行 `$this->CI->load->model('Ahead_vip_level_model');`，CI3 模型加载一次即可全局复用，重复调用浪费性能。 | 将模型加载移至 `__construct()` 或类属性初始化，或使用 `CI::$instance->load->model()` 仅一次。 | `// __construct 中加载一次`<br>`$this->CI->load->model('Ahead_vip_level_model');`<br>`// 后续直接使用 $this->CI->Ahead_vip_level_model` |
| 🟠 警告 | `Ahead_book_order_model.php` (第1行) | **文件级全局实例化**：`$CI = &get_instance();` 放在类外部，每次 `require/include` 该文件都会执行，可能引发未初始化错误或性能损耗。 | 移至类的 `__construct()` 方法中，或依赖 CI 自动加载机制。 | `public function __construct() { parent::__construct(); $this->load->model('Simple_model'); }` |
| 🟡 建议 | 全局 | **魔法数字泛滥**：大量硬编码状态值（如 `-1, 1, 2, 3, 7, 13, 100`），可读性差且易引发维护错误。 | 提取为类常量或配置数组，集中管理业务枚举。 | `const STATUS_PENDING = -1;`<br>`const PLATFORM_WECHAT = 1;`<br>`const DISCOUNT_FULL = 100;` |
| 🟡 建议 | `Neworderservice.php` | **方法过长违反 SRP**：`getOrderTypeInfo()` 超 1000 行，包含价格计算、优惠券校验、服务费、会员升级等数十个职责。 | 按订单类型拆分策略类（Strategy Pattern），或使用独立的价格计算服务类。 | `class OrderPriceCalculator { public function calculateDrinkOrder(...) {} }`<br>`class OrderPriceCalculator { public function calculateRoomPackage(...) {} }` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题（P0/P1）
1. **立即清理调试输出**：全局搜索 `echo`、`var_dump`、`print_r` 并移除，改用 `doLog()` 或 Monolog。
2. **修复 SQL 注入隐患**：将所有手动拼接的 SQL 字符串替换为 CI3 Query Builder 方法（`$this->db->where()`, `$this->db->where_in()`, `$this->db->escape()`）。
3. **修正变量覆盖逻辑**：检查 `$order['_prime_service_charge']` 的赋值意图，确保原始服务费与折后服务费分别存储。
4. **统一财务计算精度**：所有涉及金额乘除、网关传参（分/元转换）的场景，强制使用 `bcmul()` 或 `intval(round())`，禁止直接浮点运算。
### 🛠 后续重构与优化方向
1. **架构解耦**：当前 `Neworderservice` 承担了“订单校验、价格计算、优惠券匹配、会员升级推荐、服务费核算”等全部职责。建议引入 **策略模式** 或 **责任链模式**，将不同订单类型（酒水、开房套餐、预买等）拆分为独立的 `Calculator` 类。
2. **常量与配置集中化**：将支付平台、订单状态、折扣规则等魔法数字提取至 `config/order.php` 或类常量中，便于后续多租户/多门店配置扩展。
3. **事务管理规范化**：CI3 的 `$this->db->trans_start()` / `$this->db->trans_complete()` 已内置自动回滚机制。建议移除 `try...catch` 中的手动 `trans_rollback()`，改为依赖 CI 自动处理，或在 `catch` 中仅记录日志并抛出异常。
4. **遵循 PSR-12 规范**：
- 统一使用短数组语法 `[]` 替代 `array()`。
- 为方法参数添加类型声明（如 `array $id_array`, `int $type`）。
- 控制单行长度（建议 ≤120字符），拆分超长条件判断。
> 📌 **局限性说明**：由于 `Neworderservice.php` 与 `Ahead_yc_order_model.php` 代码片段在末尾被截断，部分依赖上下文的方法（如 `throwError`、`Simple_model` 基类实现、`doLog` 全局函数）未完全展示。若上述函数存在未捕获的致命错误或全局状态污染，建议补充完整代码以便进行更深度的静态分析。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780975005
|
1780975005
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
631
|
21
|
284
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616 🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616' of https://gitea.g-hi.co...
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `3a8a6f74a ## 自动代码审查报告
**分支**: pay-260616
**提交**: `3a8a6f74a5ceacbebedc0d300c10ac338c68dcb3`
**提交人**: linyangrui (yangruilin888@gmail.com)
**时间**: 2026-06-09 14:15:21
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10
- **总体评价**：代码承载了复杂的订单计价、会员折扣、多支付渠道对接及退款逻辑，业务覆盖面广。但存在**严重的安全隐患**（支付回调未验签、硬编码密钥）、**逻辑缺陷**（调试代码残留、浮点数精度风险）及**性能瓶颈**（同步阻塞外部请求、重复加载模型）。整体违反单一职责原则，魔法数字泛滥，可维护性与扩展性较差。
- **风险等级**：🔴 高
> 📌 **框架说明**：根据目录结构（`system/`、`application/`）、`get_instance()`、`$this->load->model()` 等特征，该项目实际基于 **CodeIgniter 3.x** 架构。以下审查基于 CI3 最佳实践。若确为定制版 `phpci`，请核对底层生命周期差异。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Neworderservice.php`<br>(约第 410 行) | **调试代码未清理**：循环内使用 `echo $vip_upgrade_data_actual_pay;` 会直接输出到响应流，破坏 JSON/API 结构，导致前端解析崩溃。 | 立即删除 `echo` 语句。若需调试，应使用日志记录。 | `// 删除此行：<br>echo $vip_upgrade_data_actual_pay;` |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`check_notify()` | **支付回调缺失签名验证**：直接根据 `order_id` 更新订单状态，未校验微信/支付宝回调签名。攻击者可伪造 POST 请求篡改订单状态或触发重复退款。 | 在方法入口处调用支付 SDK 的验签方法，验签失败直接返回 `FAIL` 或 `false`。 | `if (!$this->verify_pay_sign($this->input->post())) {<br> return ['status'=>false, 'msg'=>'签名验证失败'];<br>}` |
| 🔴 严重 | `Ahead_yc_order_model.php`<br>(类属性) | **硬编码加密密钥**：`public $encrypt = "Vs!Fs7VT";` 将敏感密钥写死在源码中，违反安全规范，易随版本库泄露。 | 移至 `application/config/config.php` 或环境变量，通过 `$this->config->item('encrypt_key')` 读取。 | `// config.php<br>$config['order_encrypt_key'] = getenv('ORDER_ENCRYPT_KEY') ?: 'default_key';` |
| 🟠 警告 | `Neworderservice.php`<br>(约第 260 行) | **SQL 注入风险**：`$pack_goods_where = "wares_package._package_id in (" . implode(",", $id_array['package_id']) . ")";` 未对数组元素做类型强转，若传入恶意字符串将导致注入。 | 使用 CI 查询构造器 `where_in()`，或对 ID 进行 `(int)` 过滤。 | `$ids = array_map('intval', $id_array['package_id']);<br>$this->db->where_in('_package_id', $ids);` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`send_success_msg()` | **同步阻塞支付回调**：在支付成功回调中同步调用微信模板消息、短信发送等外部 HTTP 请求。网络延迟将直接阻塞回调响应，导致支付平台重试或订单状态不一致。 | 将消息推送改为异步队列（如 Redis/Beanstalkd）或 CI 的 `ignore_user_abort()` + `fastcgi_finish_request()`。 | `// 记录到队列后快速返回<br>$this->queue->push('send_book_msg', $order_data);<br>return ['status'=>true, 'msg'=>'支付成功'];` |
| 🟠 警告 | `Neworderservice.php`<br>多处计价逻辑 | **浮点数精度丢失风险**：财务计算直接使用 `*`、`/` 及 `sprintf("%.2f", ...)`，在 PHP 中易产生 `0.0000000001` 级误差，长期累积导致账目不平。 | 涉及金额计算统一使用 `bcmath` 扩展或至少 `round($val, 2, PHP_ROUND_HALF_UP)`。 | `$actual = bcdiv(bcmul($price, $qty, 4), 100, 2);` |
| 🟡 建议 | `Neworderservice.php`<br>多处 | **重复加载模型**：`$this->CI->load->model('Ahead_vip_level_model');` 在多个方法中被重复调用，增加 I/O 开销且违反 CI 规范。 | 统一在 `__construct()` 中加载，或使用 CI 自动加载配置。 | `public function __construct() {<br> $this->CI =& get_instance();<br> $this->CI->load->model(['Ahead_vip_level_model', 'Ahead_merchant_goods_model']);<br>}` |
| 🟡 建议 | 全局文件 | **魔法数字泛滥**：大量使用 `-1`, `1`, `2`, `100`, `9999999999999` 等硬编码值，业务含义不透明，极易引发逻辑误判。 | 提取为类常量或配置数组，如 `const STATUS_DISABLED = -1; const DISCOUNT_FULL = 100;`。 | `const MAX_DEDUCT_AMOUNT = 9999999999999;<br>if ($deduct > self::MAX_DEDUCT_AMOUNT) { ... }` |
| 🟡 建议 | `Neworderservice.php`<br>`getOrderTypeInfo()` | **方法过长违反单一职责**：该方法超 500 行，混合了商品校验、价格计算、优惠券抵扣、服务费计算、订单组装等逻辑，极难测试与维护。 | 拆分为独立方法或策略类：`validateGoods()`, `calculateVipPrice()`, `applyRewards()`, `assembleOrder()`。 | *(架构级重构，见第3节建议)* |
> ⚠️ **局限性说明**：`Ahead_yc_order_model.php` 末尾代码被截断，`get_bill_goods_info()` 方法未完整展示。该部分涉及大量数组合并与状态判断，若存在未闭合的循环或条件分支，可能引发内存溢出或逻辑死锁。建议补充完整代码以便深度评估。
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题（P0/P1）
1. **清理调试输出**：立即移除 `Neworderservice.php` 中的 `echo` 语句，恢复 API 响应纯净性。
2. **支付回调安全加固**：在 `check_notify()` 入口增加支付平台签名校验逻辑，拒绝非法请求。
3. **敏感信息脱敏**：将 `$encrypt` 密钥迁移至配置文件或环境变量，禁止硬编码。
4. **SQL 注入防御**：对所有动态拼接的 SQL 条件（尤其是 `IN` 语句）进行 `(int)` 强转或改用 CI Query Builder。
### 🛠 后续重构与优化方向
1. **财务计算标准化**：
- 引入 `bcmath` 或封装 `MoneyCalculator` 类，统一处理加减乘除与舍入规则。
- 所有金额字段在入库前执行 `round($val, 2)`，避免数据库精度不一致。
2. **架构解耦与职责分离**：
- 将 `Neworderservice::getOrderTypeInfo()` 拆分为 **校验层**、**计价层**、**组装层**。
- 使用策略模式处理不同订单类型（`case '1'`, `case '2'` 等），避免巨型 `switch`。
3. **异步化与性能提升**：
- 支付成功后的短信、微信推送、日志记录等非核心链路全部改为异步队列处理。
- 模型加载统一收敛至构造函数，避免运行时重复 `load`。
4. **代码规范与可维护性**：
- 全面替换魔法数字为语义化常量。
- 补充 PHPDoc 类型声明（如 `@param int $vip_level`、`@return array<string, mixed>`），便于 IDE 静态检查。
- 遵循 PSR-12 规范，统一命名风格（建议属性使用 `snake_case`，方法使用 `camelCase`）。
> 💡 **实施建议**：建议先建立自动化测试用例覆盖核心计价与退款流程，再进行重构。财务类代码的每一次修改都必须通过单元测试验证边界条件（如 0 元订单、最大折扣、并发退款等），确保资金安全零容错。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780985721
|
1780985721
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
633
|
21
|
285
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - Merge remote-tracking branch 🔍 代码审查报告：pay-260616 - Merge remote-tracking branch 'origin/pay-260616' i...
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `7c248c9a1 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `7c248c9a19979d2d197232e1464ccf25c88a3a70`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-09 14:40:10
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：代码实现了较为复杂的订单计价、优惠券抵扣、支付回调及退款逻辑，业务覆盖全面。但核心方法严重臃肿（God Method），存在未清理的调试输出、变量重复赋值、潜在 SQL 注入及频繁加载 Model 等性能隐患。整体代码风格与 PSR-12 规范差距较大，可维护性与安全性亟待提升。
- **风险等级**：🔴 高
## 2. 问题详情
> *注：因提供的代码片段存在截断，行号为基于上下文估算的近似位置，实际审查请以完整文件为准。*
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Neworderservice.php` ~L380 | 遗留 `echo $vip_upgrade_data_actual_pay;` 调试语句。在 API 或 JSON 响应场景下会直接破坏输出结构，导致前端解析失败。 | 彻底移除 `echo`/`var_dump`/`print_r`，统一替换为框架日志组件（如 `log_message()` 或 `doLog()`）。 | `// 移除该行，改用日志：<br>doLog("VIP升级金额累加: {$vip_upgrade_data_actual_pay}", 'order_calc');` |
| 🔴 严重 | `Ahead_yc_order_model.php` ~L250 | 原始 SQL 字符串拼接存在 **SQL 注入风险**。`$sql = '_unique_key="' . $unique_key . '" AND ...'` 未对 `$unique_key` 进行转义或参数绑定。 | 使用框架查询构造器或参数化查询，杜绝手动拼接。 | `$this->db->where('_unique_key', $unique_key)<br> ->where_in('_status', [1, 4])<br> ->where('_timestamp >', time() - 7 * 86400)<br> ->get()->result_array();` |
| 🔴 严重 | `Neworderservice.php` ~L430 | 关键订单字段被**重复赋值覆盖**。`$order['_prime_service_charge']` 先赋 `$prime_after_paid_service_charge`，紧接着又被 `$service_charge` 覆盖；`$result['service_charge']` 同理。 | 梳理业务语义，确认应保留的值，删除冗余赋值，避免金额计算错乱。 | `$order['_prime_service_charge'] = $service_charge; // 仅保留最终计算值<br>// 删除重复的 $order['_prime_service_charge'] = $service_charge;` |
| 🟠 警告 | `Ahead_shop_group_buying_coupon_model.php` ~L30 | `FIND_IN_SET` 拼接未严格过滤，且 CI 查询构造器不支持 `$where['where'][] = [implode(...)]` 这种嵌套语法，易引发 SQL 语法错误或注入。 | 强制类型转换后使用原生 `where` 字符串，或改用 CI 的 `where()` 链式调用。 | `$shop_id = (int)$shop_id;<br>$this->db->where("FIND_IN_SET({$shop_id}, _satisfy_shop_ids) > 0");` |
| 🟠 警告 | `Ahead_book_order_model.php` ~L110 | 异常分支中 `$result['msg']` 未定义直接返回，触发 PHP Notice，且可能导致前端收到 `null` 错误信息。 | 使用空合并运算符 `??` 提供默认值，或提前初始化响应数组。 | `$subMsg = $res_data['response']['result']['sub_msg'] ?? '未知错误';<br>return ['status' => false, 'msg' => '退款失败: ' . $subMsg];` |
| 🟠 警告 | 全局多处 | 频繁在方法内部调用 `$this->CI->load->model()` 或 `$this->load->model()`。每次调用都会触发文件 I/O 与实例化，严重拖慢高并发下的订单计算与退款流程。 | 将高频依赖的 Model 移至构造函数统一加载，或配置自动加载。 | `public function __construct() {<br> parent::__construct();<br> $this->load->model(['Ahead_vip_level_model', 'Ahead_merchant_goods_model', 'Ahead_pay_log_model']);<br>}` |
| 🟡 建议 | `Neworderservice.php` `getOrderTypeInfo` | 方法长度超 500 行，嵌套层级深，违反单一职责原则（SRP）。计价、折扣、服务费、免单逻辑耦合严重，极难单元测试。 | 按业务域拆分为独立私有方法：`calcGoodsPrice()`, `calcPackagePrice()`, `applyRewardDiscount()`, `calcServiceCharge()` 等。 | `// 主方法仅保留流程编排<br>$goodsData = $this->calcGoodsPrice($id_array, $goods_quantity);<br>$packageData = $this->calcPackagePrice($id_array, $goods_quantity);<br>return $this->assembleOrderResult($goodsData, $packageData);` |
| 🟡 建议 | 全局 | 大量魔法数字（`-1`, `1`, `100`, `2`, `3`）与混合数组语法 `array()`/`[]` 并存，不符合 PSR-12 规范，降低可读性。 | 定义类常量/枚举，统一使用短数组语法 `[]`，建议文件头部添加 `declare(strict_types=1);`。 | `const STATUS_DISABLED = -1;<br>const DISCOUNT_FULL = 100;<br>const PAY_TYPE_WECHAT = 1;<br>// 统一使用 [] 替代 array()` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **清理调试输出**：立即全局搜索并移除 `echo`、`var_dump`、`print_r`，避免生产环境输出污染。
2. **修复 SQL 注入隐患**：将 `Ahead_yc_order_model.php` 中的原始 SQL 拼接全部替换为查询构造器或参数绑定。
3. **修正重复赋值 Bug**：核对 `Neworderservice.php` 中 `$order['_prime_service_charge']` 与 `$result['service_charge']` 的业务意图，保留正确逻辑。
4. **防御性编程**：对 `FIND_IN_SET`、`implode` 等动态拼接处增加严格类型校验（如 `(int)` 强转），防止恶意参数注入。
### 🛠 后续重构与优化方向
1. **架构解耦（拆分 God Method）**：`Neworderservice::getOrderTypeInfo` 承载了过多职责。建议引入 **策略模式（Strategy Pattern）** 或 **工厂模式**，将 `case '13'/'1'`（酒水/售货柜）与 `case '2'/'4'`（开房套餐）的计价逻辑抽离为独立的 `PriceCalculator` 类。
2. **性能优化**：
- 将循环内的 `$this->load->model()` 提前至构造器。
- 批量查询替代循环查询：如 `get_merchant_goods_by_ids` 已实现，但后续价格策略查询可考虑一次性拉取后内存匹配，减少 DB 往返。
- 金额计算统一使用 `bcmath` 扩展或框架内置的货币处理工具，避免浮点数精度丢失（当前大量使用 `sprintf("%.2f")` 和直接乘除，存在精度风险）。
3. **规范与可维护性**：
- 启用 `PSR-12` 代码风格检查器（如 `PHP_CodeSniffer` 或 `PHP-CS-Fixer`）进行自动化格式化。
- 将状态码、支付类型、折扣标识等硬编码提取为 `const` 常量或独立配置类。
- 补充关键业务方法的 PHPDoc 注释，明确参数类型、返回值及异常抛出条件。
> 💡 **框架适配说明**：当前代码结构高度契合 **CodeIgniter 3.x** 规范。若 `phpci` 为内部定制或升级版本，请重点核对：① 事务处理是否推荐使用 `trans_begin()/trans_commit()/trans_rollback()` 替代 `trans_start()/trans_complete()`；② Model 自动加载机制是否已优化。建议查阅 `phpci` 官方文档确认组件生命周期差异。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780987210
|
1780987210
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
635
|
21
|
286
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 预订开房后退款
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `6d68c74c8 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `6d68c74c8a53ee6664976274f5246cdd087173f6`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-09 15:18:13
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：代码完整覆盖了预订下单、支付回调、退款、消息推送等核心电商/预订业务链路，具备一定的幂等性设计与缓存优化意识。但存在**事务与外部网络请求强耦合、SQL 拼接隐患、模型重复加载、魔法数字泛滥**等问题，在资金流转场景下存在较高的数据一致性风险与可维护性瓶颈。
- **风险等级**：🔴 高（涉及支付退款、事务一致性、潜在 SQL 注入）
> 📌 **框架说明**：代码语法与架构高度匹配 **CodeIgniter 3** 框架（如 `$this->load->model()`、`$this->db->trans_start()`）。若 `phpci` 为贵司定制框架，请确认其事务与模型加载机制是否与 CI3 一致。以下建议基于 CI3 最佳实践给出。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`check_notify` / `refund_by_notify` | **事务内调用外部支付 API**：微信/银联退款请求在 `trans_start()` 与 `trans_complete()` 之间执行。网络超时或第三方异常会导致数据库长事务锁表，且手动 `trans_rollback()` 与 CI 自动事务管理机制冲突。 | 将第三方 API 调用移出数据库事务。先完成本地数据状态更新与提交，再执行退款请求；若退款失败，通过补偿任务或异步队列处理。 | ```php<br>// 错误做法<br>$this->db->trans_start();<br>$res = WxPayApi::refund($input); // 阻塞事务<br><br>// 正确做法<br>$this->db->trans_start();<br>// 1. 更新本地状态<br>$this->update(...);<br>$this->db->trans_complete();<br>// 2. 事务提交后执行外部请求<br>$res = WxPayApi::refund($input);<br>``` |
| 🔴 严重 | `Ahead_book_order_model.php`<br>`refund_by_notify` (约 380 行) | **SQL 注入风险**：`$log_where` 与 `$log_up` 使用字符串拼接直接传入底层查询方法，未使用查询构建器或参数绑定。若 `_id` 来源不可控，将导致注入。 | 严格使用 CI 查询构建器或数组传参，避免原始 SQL 拼接。 | ```php<br>// 错误<br>$log_where = '_relation_id="'.$order_data['_id'].'" ...';<br>$this->ahead_pay_log_model->up($log_up, $log_where);<br><br>// 正确<br$this->db->where('_relation_id', $order_data['_id'])<br> ->where_in('_type', [5, 13])<br> ->where('_status', 1)<br> ->update('ahead_pay_log', [<br> '_status' => 4,<br> '_refund_amount' => $this->db->escape_identifiers('_actual_pay')<br> ]);<br>``` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`refund` (约 560 行) | **退款幂等性逻辑缺陷**：执行 `update` 后通过 `$this->db->affected_rows()` 判断是否成功。若订单已处于退款状态（`_status=4`），`affected_rows()` 为 0，代码会回滚并返回失败，不符合接口幂等性规范。 | 更新前先校验状态，若已退款直接返回成功；或忽略 `affected_rows() === 0` 的情况。 | ```php<br>$current = $this->get_one(['_id' => $order_id], '_status');<br>if ($current['_status'] == 4) {<br> return ['status' => true, 'msg' => '订单已退款'];<br>}<br>$this->update(['_status' => 4], ['_id' => $order_id]);<br>``` |
| 🟠 警告 | `Ahead_book_order_model.php`<br>`send_success_msg` / `refund_by_notify` | **频繁重复加载模型/配置**：方法内部多次调用 `$this->load->model()` 与 `$CI->config->load()`，增加文件 I/O 与内存开销。 | 将依赖模型移至构造函数加载，或使用 CI 自动加载配置。配置项建议全局缓存。 | ```php<br>public function __construct() {<br> parent::__construct();<br> $this->load->model(['ahead_merchant_room_type_model', 'ahead_yc_notice_model', 'ahead_user_model']);<br>}<br>``` |
| 🟠 警告 | `Ahead_book_order_operation_log_model.php`<br>`add_log_by_renewals_package` | **变量未初始化**：`$source` 仅在 `if/elseif` 分支中赋值，若未匹配任何条件，`$source ?? 0` 虽兼容 PHP7+，但逻辑不严谨且易引发静态分析警告。 | 方法首行显式初始化 `$source = 0;`。 | ```php<br>public function add_log_by_renewals_package($order_data) {<br> $source = 0;<br> if ($order_data['_pay_scene'] == '1') { $source = 2; }<br> // ...<br>}<br>``` |
| 🟡 建议 | `Ahead_book_order_model.php`<br>全局 | **魔法数字/字符串泛滥**：大量硬编码状态码、支付类型、模板 ID（如 `1, 3, 5, 8, 9, 14, 22, 56, 58, 99`），严重降低可读性与后期维护成本。 | 提取为类常量或独立配置文件，配合 IDE 提示与类型约束。 | ```php<br>class Ahead_book_order_model extends Simple_model {<br> const STATUS_PENDING = -1;<br> const STATUS_PAID = 1;<br> const PAY_SCENE_WECHAT = '5';<br> // ...<br>}<br>``` |
| 🟡 建议 | `Ahead_book_order_model.php`<br>文件头部 | **全局实例获取不规范**：`$CI = &get_instance();` 写在类外部，违反 PSR-12 规范，且可能导致作用域污染或单例状态异常。 | 删除头部代码。CI 模型内部可直接通过 `$this->config`、`$this->load` 访问，无需手动获取 CI 实例。 | ```php<br>// 删除文件顶部的 $CI = &get_instance();<br>// 类内部直接使用 $this->config->item('wx');<br>``` |
| 🟡 建议 | `Ahead_book_order_model.php`<br>`create_community_shop_book_order` | **代码片段不完整**：文件末尾 `if ($this->tuangou->verify_token) {` 后缺失逻辑与闭合括号，无法评估完整业务流程与异常处理。 | 补充完整代码或说明截断原因，确保事务闭合与返回值完整。 | *(需补充完整代码)* |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **解耦事务与外部请求**：立即将 `refund_by_notify` 与 `check_notify` 中的微信/银联退款、短信发送等网络请求移出 `trans_start()` 范围。资金类操作必须保证“本地状态变更”与“第三方调用”的异步或最终一致性。
2. **修复 SQL 拼接隐患**：全面替换 `$log_where`、`$log_up` 等原始字符串拼接，统一使用 CI 查询构建器（`$this->db->where()` / `update()` 数组传参），杜绝注入风险。
3. **修正退款幂等逻辑**：调整 `refund` 方法的状态更新判断逻辑，确保重复请求或已退款订单能安全返回成功状态，避免业务层误判失败。
### 🛠 后续重构与优化方向
- **拆分“上帝类” (SRP 原则)**：`Ahead_book_order_model` 承载了订单、支付、退款、消息推送、社区门店、团购核销等过多职责。建议拆分为：
- `BookOrderModel`（核心订单 CRUD）
- `PaymentService`（支付/退款网关封装）
- `NotificationService`（短信/微信模板消息）
- `CommunityShopService`（社区门店专属逻辑）
- **统一状态与配置管理**：建立全局 `OrderStatus`、`PayPlatform`、`PayScene` 常量类或枚举（PHP 8.1+），替换魔法数字。将 `wx_template` 等配置项移至 `config/` 目录并启用缓存。
- **引入队列机制**：支付成功后的短信/微信推送、流水记录、社区收入同步等**非强一致性操作**，建议接入 Redis/RabbitMQ 队列异步执行，大幅降低主流程响应时间与数据库锁竞争。
- **补充自动化测试**：针对 `check_notify`（支付回调）与 `refund_by_notify` 编写单元测试与集成测试，覆盖正常支付、重复回调、退款失败、库存不足等边界场景，确保资金链路健壮性。
> 💡 **提示**：若 `phpci` 框架对事务或模型加载有特殊封装（如自动连接池、读写分离、自定义 ORM），请对照其官方文档调整上述 CI3 语法建议。代码审查基于当前提供的片段，若存在未暴露的中间件或全局钩子，实际风险可能有所差异。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780989493
|
1780989493
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
636
|
21
|
287
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 退款相关
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `30257114c ## 自动代码审查报告
**分支**: pay-260616
**提交**: `30257114cd8b53738022bdcd2ba8798fb3d78384`
**提交人**: linyangrui (yangruilin888@gmail.com)
**时间**: 2026-06-09 15:46:56
---
## 📋 审查摘要
- **变更文件数**: 3
- **严重问题**: 1
- **高危问题**: 3
- **中危问题**: 2
- **建议优化**: 3
## 🐛 发现的问题
### <font color="red">[语法错误] 对象字面量中存在重复键名 `showCancelBtn`</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 约 168 行
- **问题描述**: 在 `handleOpenMachineResult` 方法的 `this.setData` 调用中，`showCancelBtn: false` 被连续定义了两次。在严格模式或现代 JS 引擎中，重复键名会触发语法警告或直接覆盖，属于结构/语法错误，可能导致 UI 状态渲染异常。
- **修复建议**: 删除重复的键值对，保持对象字面量键名唯一。
```javascript
// 修复前
showCancelBtn: false,
showCloseBtn: true,
showCancelBtn: false, // 重复
// 修复后
showCancelBtn: false,
showCloseBtn: true,
```
### <font color="red">[跨文件调用] 模型方法调用参数传递存在潜在签名不匹配风险</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 约 135、155、215 行
- **问题描述**: 多次调用 `reserveModel.openMachine` 时传入了 6 个参数，其中第 5 个参数为空字符串 `''`，第 6 个为函数。若底层模型的标准回调签名为 `(successCallback, failCallback, completeCallback)`，传入空字符串会导致模型内部尝试执行 `''()` 而抛出 `TypeError`。此外，提供的上下文中未包含 `reserve.js`、`order.js`、`cabinet.js` 等模型文件，无法验证方法是否存在及签名是否一致。
- **修复建议**:
1. 确认模型方法签名，若不需要失败回调应传 `null` 或 `undefined`，而非空字符串。
2. 补充模型文件定义或提供接口文档，以便进行完整的跨文件静态分析。
```javascript
// 建议修改为
reserveModel.openMachine(url, this.data.order_id, forward_open, (res) => {
this.handleOpenMachineResult(res)
}, null, () => { wx.hideLoading() })
```
### [安全隐患] 未校验 Storage 返回值直接访问属性导致潜在崩溃
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 约 78 行
- **问题描述**: `const uid = wx.getStorageSync('userInfo').uid || ''` 中，若用户未登录或 `userInfo` 缓存被清除，`wx.getStorageSync` 返回 `undefined` 或 `null`，直接访问 `.uid` 会抛出 `TypeError: Cannot read properties of undefined (reading 'uid')`，导致页面白屏崩溃。
- **修复建议**: 使用可选链操作符或先进行空值判断。
```javascript
const userInfo = wx.getStorageSync('userInfo') || {}
const uid = userInfo.uid || ''
// 或使用可选链: const uid = wx.getStorageSync('userInfo')?.uid || ''
```
### [安全隐患] 路由跳转参数拼接未全面使用 `encodeURIComponent`
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/apply-refund/apply-refund.js` (约 68 行)
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js` (多处)
- **行号**: 约 68、108、145、180 等行
- **问题描述**: 多个 `wx.navigateTo`/`wx.redirectTo` 的 URL 拼接中，`order_id`、`actual_pay`、`voucher_name` 等参数未使用 `encodeURIComponent` 编码。若参数值包含 `&`、`=`、`?` 或特殊字符，会导致路由解析错误、参数截断或注入恶意路由。
- **修复建议**: 对所有动态拼接的 URL 参数统一使用 `encodeURIComponent()`。
```javascript
url: `/pages/community-reserve/apply-result/apply-result?order_id=${encodeURIComponent(this.data.order_id)}&voucher_name=${encodeURIComponent(this.data.voucher_name)}...`
```
### [逻辑 BUG] `wx.showLoading` 后缺少异常/失败路径的 `wx.hideLoading`
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/apply-refund/apply-refund.js` (约 65 行)
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js` (约 88、133 行)
- **问题描述**: 调用 `wx.showLoading()` 后，仅在成功回调中执行页面跳转或隐藏逻辑。若网络请求超时、接口返回失败或模型内部抛出异常，Loading 遮罩将永久显示，阻塞用户所有交互。
- **修复建议**: 在模型调用的失败回调中补充 `wx.hideLoading()`，或使用 `complete` 回调统一处理。
```javascript
reserveModel.applyBookRefund(this.data.order_id, this.data.refund_reason, (res) => {
// success
}, (err) => {
wx.hideLoading()
wx.showToast({ title: '退款申请失败', icon: 'none' })
})
```
### [代码质量] 函数命名存在拼写错误 `handeleCancel`
- **严重程度**: 中危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/apply-refund/apply-refund.js`
- **行号**: 约 48 行
- **问题描述**: 方法名 `handeleCancel` 存在明显拼写错误（应为 `handleCancel`）。若对应 WXML 文件中绑定的是正确拼写 `handleCancel`，将导致点击事件无法触发，UI 交互失效。
- **修复建议**: 统一修正为 `handleCancel`，并同步检查 `apply-refund.wxml` 中的 `bindtap="handleCancel"` 属性。
### [代码质量] 模块导入路径后缀不一致
- **严重程度**: 中危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/apply-result/apply-result.js`
- **行号**: 约 2 行
- **问题描述**: `import {config} from '../../../config'` 缺少 `.js` 后缀，而 `order-detail.js` 中为 `import {config} from '../../../config.js'`。微信小程序原生构建环境对无后缀导入支持不稳定，在部分版本或 CI/CD 构建中可能导致模块解析失败。
- **修复建议**: 统一添加 `.js` 后缀：`import {config} from '../../../config.js'`
## ✅ 代码亮点
1. **生命周期使用规范**：合理使用了 `onLoad` 接收路由参数，`onShow` 处理页面可见时的数据刷新，符合微信小程序开发规范。
2. **状态管理清晰**：通过 `data` 集中管理弹窗显示状态（如 `showConfirm`、`showScanPop` 等），配合 `setData` 更新视图，逻辑分层明确。
3. **用户体验细节**：在 `scanToOpen` 和 `openRightNow` 中加入了时间限制判断，并在不可操作时给予明确 Toast 提示，交互体验较好。
## 📝 总体建议
1. **补充跨文件依赖**：当前审查受限于未提供 `models/` 和 `config.js` 源码。建议将模型层接口定义（方法签名、参数类型、回调结构）纳入版本控制或提供 TypeScript 声明文件，以便进行静态类型检查。
2. **统一错误处理机制**：建议封装统一的请求拦截器或 Loading 管理工具类，避免在每个页面手动调用 `wx.showLoading`/`wx.hideLoading`，降低遗漏风险。
3. **消除魔法数字**：`order-detail.js` 中大量使用 `1, 2, 4, 5, 6` 等硬编码状态值。建议提取为常量枚举（如 `const MACHINE_RESULT_TYPE = { SUCCESS: 1, CONFIRM: 2, ... }`），并将 `==` 全面替换为 `===`，提升代码可维护性与安全性。
4. **注意项目结构差异**：提供的「项目结构」为 PHP CodeIgniter 后端目录，但审查代码为微信小程序前端。前后端分离架构下，请确保前端模型层与后端 API 路由、参数命名严格对齐，避免联调时出现字段不匹配问题。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780991216
|
1780991216
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
637
|
21
|
288
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 新增订单检索状态-待商家处理
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `82a32d6a4 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `82a32d6a4b1cb7642260483975650f4b9320a030`
**提交人**: linyangrui (yangruilin888@gmail.com)
**时间**: 2026-06-09 15:48:09
---
## 📋 审查摘要
- **变更文件数**: 1
- **严重问题**: 0
- **高危问题**: 4
- **中危问题**: 3
- **建议优化**: 5
## 🐛 发现的问题
### <font color="red">[跨文件调用] 引用的模型文件及方法无法验证</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-list/order-list.js`
- **行号**: 第 2-6 行
- **问题描述**: 代码中通过 `import` 引入了 `ReserveModel`、`PublicModel`、`OrderModel`、`RoomModel`，并调用了大量实例方法（如 `reserveModel.getBookOrderList`、`orderModel.deleteOrder` 等）。但提供的项目结构仅包含 PHP CodeIgniter 系统文件，**未包含任何前端 JS 目录或 `models/` 文件夹**。若实际项目中不存在对应文件或方法签名不匹配，将直接导致 `ReferenceError` 或运行时崩溃。
- **修复建议**: 请确保 `../../../models/reserve.js` 等文件真实存在，且导出的类包含所有被调用的方法。建议在模型文件中统一导出方法签名，或使用 TypeScript/JSdoc 进行类型约束。
### <font color="red">[语法错误] 未处理 find() 返回 undefined 导致运行时崩溃</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-list/order-list.js`
- **行号**: 第 108 行
- **问题描述**: `this.data.status_list.find(item => item.value == this.data.status).name`。当 `options.status` 传入的值不在 `status_list` 中时（如非法参数 `'7'`），`find()` 返回 `undefined`，直接访问 `.name` 会抛出 `TypeError: Cannot read properties of undefined (reading 'name')`，导致页面白屏。
- **修复建议**: 增加安全访问或默认值处理：
```javascript
const matchedStatus = this.data.status_list.find(item => item.value == this.data.status);
this.setData({
status_name: matchedStatus ? matchedStatus.name : '全部状态',
});
```
### [逻辑 BUG] 分页加载状态 `loading` 逻辑错误导致加载动画常驻
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-list/order-list.js`
- **行号**: 第 158, 203, 475, 508 行等
- **问题描述**: 在 `getBookOrderList`、`getGoodsOrderList` 等方法中，`loading: !isLast` 的赋值逻辑有误。当还有更多数据时（`isLast = false`），`loading` 会被设置为 `true`，导致页面加载动画在请求成功后**永远不会消失**，直到翻到最后一页。
- **修复建议**: 请求完成后应固定将 `loading` 设为 `false`，`hasMore` 控制是否显示“加载更多”按钮：
```javascript
this.setData({
order_list: [...this.data.order_list, ...res.result],
hasMore: !isLast,
loading: false // 修正：请求完成即关闭 loading
});
```
### [逻辑 BUG] 数组删除索引未校验导致误删或空数组异常
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-list/order-list.js`
- **行号**: 第 528-531 行
- **问题描述**: `let index = this.data.goods_order_list.findIndex(...)` 若未找到对应订单，返回 `-1`。后续 `slice(0, -1)` 会删除数组最后一个元素，`slice(0)` 返回空数组，导致列表数据错乱。
- **修复建议**: 增加索引校验：
```javascript
if (index !== -1) {
const newList = [...this.data.goods_order_list];
newList.splice(index, 1);
this.setData({ goods_order_list: newList });
}
```
### [跨文件调用] `openMachine` 方法调用参数数量不一致
- **严重程度**: 中危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-list/order-list.js`
- **行号**: 第 435 行 vs 第 238 行
- **问题描述**: `openMachine` 方法在其他地方调用为 4 个参数 `(url, id, forward_open, callback)`，但在 `onNotChangeCleanRoomClick` 中传入了 5 个参数 `(family_server_id, id, 1, callback, 1)`。多出的第 5 个参数 `1` 可能被底层模型忽略，也可能导致参数错位或静默失败。
- **修复建议**: 统一方法签名。若第 5 个参数代表“强制开门”等标识，应在模型定义中明确声明，或合并到 `forward_open` 参数中。
### [安全隐患] 动态拼接 HTML 字符串存在潜在 XSS 风险
- **严重程度**: 中危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-list/order-list.js`
- **行号**: 第 268-280 行
- **问题描述**: `confirmContent` 使用模板字符串拼接了 `this.data.oper_order.book_time` 和 `res.result.reset_book_time`，并设置了 `contentIsNodes: true`。若后端返回的时间字段包含恶意 HTML/JS 代码，在支持 `rich-text` 或自定义节点渲染的组件中可能触发 XSS。
- **修复建议**: 对动态内容进行转义，或使用小程序官方提供的安全渲染方式（如 `<rich-text nodes="{{content}}">` 配合服务端过滤），避免直接拼接未过滤的字符串。
### [代码质量] 魔法数字与硬编码状态值过多
- **严重程度**: 中危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-list/order-list.js`
- **行号**: 全文多处
- **问题描述**: 代码中大量使用硬编码数字表示业务状态，如 `operational_scene` (1,2,3,4)、`res.result.type` (1~6)、`tabIndex` (0,1,2)。可读性差，后期维护极易出错。
- **修复建议**: 提取为常量对象或枚举：
```javascript
const SCENE_TYPE = { ROOM: 1, TABLE: 2, CARD: 3, OTHER: 4 };
const OPEN_RESULT = { SUCCESS: 1, CONFIRM_EARLY: 2, ROOM_MISMATCH: 4, ERROR: 5, NEED_CHANGE: 6 };
// 后续使用 if (res.result.type === OPEN_RESULT.CONFIRM_EARLY)
```
## ✅ 代码亮点
1. **URL 参数安全处理**：在页面跳转时正确使用 `encodeURIComponent` 对动态参数进行编码，有效避免了 URL 解析错误和基础注入风险。
2. **状态管理清晰**：`data` 对象结构划分明确（预订单、门店、酒水订单分区），配合 `setData` 进行局部更新，符合微信小程序性能优化最佳实践。
3. **防重复点击/加载机制**：通过 `loading` 和 `hasMore` 控制分页请求，并在切换 Tab/筛选条件时重置列表和分页状态，逻辑闭环完整。
## 📝 总体建议
1. **补充跨文件依赖验证**：当前审查基于提供的文件结构，缺失前端 `models/` 目录。请务必核对 `ReserveModel` 等类的实际导出路径与方法签名，建议引入 ESLint + `import/resolver` 插件进行静态检查。
2. **统一加载状态管理**：修复 `loading: !isLast` 的逻辑缺陷，建议在请求发起时 `loading: true`，请求完成（无论成功/失败）时 `loading: false`，避免 UI 状态卡死。
3. **抽象重复逻辑**：`handleTabChange`、`changeOperationalScene`、`changeStatus`、`selectShop` 中均包含相同的 `if(tabIndex==0/1/2) 调用对应列表方法` 逻辑。可封装为 `refreshCurrentTabList()` 方法，减少冗余代码。
4. **框架上下文说明**：审查要求中提及 PHP CodeIgniter 规范，但实际代码为微信小程序原生 JS。若该项目为前后端分离架构，请确保后端 CI 控制器与前端 API 路由严格对齐；若为同构项目，请明确技术栈边界以便后续审查。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780991289
|
1780991289
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
638
|
21
|
289
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 因修改支付页优惠券获取逻辑，加跳转参数shop_id
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `7b94e6c0f ## 自动代码审查报告
**分支**: pay-260616
**提交**: `7b94e6c0f68a32b12c7f66e15871e848b797edf0`
**提交人**: linyangrui (yangruilin888@gmail.com)
**时间**: 2026-06-09 15:50:21
---
## 📋 审查摘要
- **变更文件数**: 6
- **严重问题**: 3
- **高危问题**: 5
- **中危问题**: 4
- **建议优化**: 6
## 🐛 发现的问题
### <font color="red">[语法错误] 未定义的变量 qrcode 导致运行时崩溃</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/table-tennis/scan-order/scan-order.js`
- **行号**: 约 238 行
- **问题描述**: 在 `openRoomCheckPackageTime` 的回调中，使用了 `this.exchange('qr_code', qrcode)`，但变量 `qrcode` 并未定义。此处应为 `qr_code`（函数参数或 `this.data.qr_code`）。该错误将直接导致 `ReferenceError`，阻断后续兑换流程。
- **修复建议**:
```javascript
// 错误代码
if(qr_code) { this.exchange('qr_code', qrcode) }
// 修正为
if(qr_code) { this.exchange('qr_code', qr_code) }
```
### <font color="red">[跨文件调用] 调用了可能存在拼写错误的方法 getRoomPackgeTimePriceInfo</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/shop-detail/shop-detail.js`
- **行号**: 约 860 行
- **问题描述**: 调用 `reserveModel.getRoomPackgeTimePriceInfo(...)`，方法名中 `Packge` 疑似为 `Package` 的拼写错误。若后端/模型层实际命名为 `getRoomPackageTimePriceInfo`，此处将报 `TypeError: reserveModel.getRoomPackgeTimePriceInfo is not a function`。
- **修复建议**: 核对 `ReserveModel` 实际定义的方法名，统一修正为正确拼写（通常为 `getRoomPackageTimePriceInfo`）。
### <font color="red">[语法错误] 未安全访问可能为空的 userInfo 对象属性</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/open-result/open-result.js` (约 318 行) & `pay-success.js` (约 285 行)
- **行号**: 约 318 / 285
- **问题描述**: `let uid = wx.getStorageSync('userInfo').uid` 直接链式访问。若用户未登录或 `userInfo` 缓存为空/结构异常，将抛出 `TypeError: Cannot read properties of undefined (reading 'uid')`，导致批量点歌功能崩溃。
- **修复建议**:
```javascript
const userInfo = wx.getStorageSync('userInfo') || {};
const uid = userInfo.uid || '';
if (!uid) {
wx.showToast({ title: '请先登录', icon: 'none' });
return;
}
```
### [逻辑 BUG] 模块级变量导致 WebSocket/定时器状态共享与内存泄漏
- **严重程度**: 高危
- **文件**: `open-result.js`, `pay-success.js`
- **行号**: 文件顶部 (约 8-10 行)
- **问题描述**: `let SocketTask = null`、`let socketOpen = false`、`let countdownTimer = null` 定义在页面模块作用域。微信小程序页面实例会被缓存，多次进入或快速切换页面时，这些变量会被所有页面实例共享，极易引发 WebSocket 连接冲突、重复重连死循环或定时器未清理导致的内存泄漏。
- **修复建议**: 将状态移至页面实例 `this` 或 `data` 中，例如 `this.socketTask = null`，并在 `onUnload` 中确保清理。
### [逻辑 BUG] 数组索引为 -1 时直接访问属性导致崩溃
- **严重程度**: 高危
- **文件**: `continue-packages.js` (约 148 行), `package.js` (约 158 行)
- **行号**: 约 148 / 158
- **问题描述**: `toPayPage` 中直接访问 `this.data.package_list[this.data.packageIndex].id`。初始化时 `packageIndex` 为 `-1`，若用户未点击选择直接触发下一步，将访问 `undefined.id` 报错。
- **修复建议**: 增加边界校验：
```javascript
const selectedPackage = this.data.package_list[this.data.packageIndex];
if (!selectedPackage) {
wx.showToast({ title: '请选择套餐', icon: 'none' });
return;
}
```
### [安全隐患] URL 参数未编码直接拼接可能导致 XSS 或路由解析异常
- **严重程度**: 高危
- **文件**: `open-result.js`, `pay-success.js`, `shop-detail.js` 等多处
- **行号**: 多处 `wx.navigateTo` 拼接处
- **问题描述**: 部分跳转链接直接拼接 `this.data.book_time`、`this.data.msg` 等来自 URL 参数或接口返回的字符串。若内容包含 `&`、`=` 或特殊字符，会破坏 URL 结构；若渲染至 `rich-text` 组件，存在 XSS 注入风险（如 `open-result.js` 的 `confirmContent` 插值）。
- **修复建议**: 统一使用 `encodeURIComponent()` 包裹动态参数，并在展示富文本前进行 HTML 实体转义或使用小程序安全 API 过滤。
### [代码质量] 核心业务逻辑（WebSocket、点歌、授权）严重重复
- **严重程度**: 中危
- **文件**: `open-result.js`, `pay-success.js`, `scan-order.js`
- **行号**: 跨文件
- **问题描述**: `initWebsocket`、`batchSong`、`importUserSongs`、手机号授权流程在三个页面中几乎完全复制。违反 DRY 原则，后期维护成本极高，且一处修复需同步多处。
- **修复建议**: 提取为全局 `Behavior`（如 `behaviors/websocketBehavior.js`）或工具类，通过 `this.triggerEvent` 或回调注入业务差异逻辑。
### [代码质量] data 对象中存在重复键名
- **严重程度**: 中危
- **文件**: `continue-packages.js`
- **行号**: 约 18 行
- **问题描述**: `data` 对象中 `operational_scene: ''` 被声明了两次。JS 引擎会静默覆盖，但属于明显的代码冗余，易引发维护困惑。
- **修复建议**: 删除重复声明，保留一处即可。
### [代码质量] Promise 调用缺少 .catch() 错误捕获
- **严重程度**: 中危
- **文件**: `shop-detail.js`
- **行号**: 约 630, 730, 790 行
- **问题描述**: `getTuanGouBookMethod` 返回 Promise，但在 `toExchangeCoupon`、`useTuangouCoupon` 中仅使用 `.then()`。若模型层请求失败或网络异常，将触发 `Unhandled Promise Rejection`，导致页面白屏或静默失败。
- **修复建议**: 补充 `.catch(err => { wx.hideLoading(); wx.showToast({title: '请求失败', icon:'none'}); })`。
### [代码质量] 魔法数字与硬编码值过多
- **严重程度**: 低危
- **文件**: 全局
- **行号**: 多处
- **问题描述**: 如 `case '7'`、`function == '9001'`、`expire: '-1'`、倒计时 `8`、重连延迟 `3000` 等直接硬编码。缺乏语义化常量，降低可读性。
- **修复建议**: 在文件顶部或独立 `constants.js` 中定义枚举/常量，如 `const WS_FUNC_SONG_CONTROL = '9001';`。
## ✅ 代码亮点
1. **动态 Tab 渲染逻辑清晰**：`continue-packages.js` 和 `package.js` 中根据 `package_list` 和 `hour_list` 是否为空动态生成 `tab_list` 的逻辑健壮，考虑了多种边界情况。
2. **防抖与状态管理意识**：`shop-detail.js` 中 `onPageScroll` 使用局部变量 `updateData` 收集变更，仅在数据真正变化时调用 `setData`，有效减少了渲染开销。
3. **模块化导入规范**：整体采用了 ES6 `import` 语法，模型实例化在模块顶层，符合小程序最佳实践。
## 📝 总体建议
1. **架构层面**：当前代码为典型的小程序前端项目，提供的 `system/` PHP 结构为后端 CodeIgniter 框架，两者无直接交叉引用关系。建议将前端公共逻辑（WebSocket 管理、授权流程、点歌协议）抽离为 `Behavior` 或 `Utils`，彻底解决代码重复问题。
2. **健壮性提升**：所有来自 `options`、`wx.getStorageSync`、接口回调的数据，在访问深层属性前必须进行空值校验（Optional Chaining `?.` 或逻辑与 `&&`）。
3. **安全规范**：严格区分“展示数据”与“路由参数”。涉及用户输入或外部返回的字符串，跳转前必须 `encodeURIComponent`，渲染前必须做 XSS 过滤。
4. **调试与监控**：建议移除或封装 `console.log`，接入小程序错误监控（如 Sentry 或微信官方 `wx.onError`），便于线上排查 `Unhandled Promise Rejection` 和 WebSocket 断连问题。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780991421
|
1780991421
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
640
|
21
|
290
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616 🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616' of https://gitea.g-hi.co...
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `be804c006 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `be804c006c02219ec0f21228b9f5ac11d2eb78de`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-09 16:12:55
---
## 📋 审查摘要
- **变更文件数**: 10
- **严重问题**: 2
- **高危问题**: 4
- **中危问题**: 3
- **建议优化**: 2
## 🐛 发现的问题
### <font color="red">[语法错误] 未定义变量 `qrcode` 导致运行时 ReferenceError</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/table-tennis/scan-order/scan-order.js`
- **行号**: 约 188 行
- **问题描述**: 在 `openRoomCheckPackageTime` 方法中调用 `this.exchange('qr_code', qrcode)`，变量 `qrcode` 未定义。当前作用域内只有局部参数 `qr_code` 和 `this.data.qr_code`，直接运行将抛出 `ReferenceError: qrcode is not defined` 导致页面崩溃。
- **修复建议**:
```javascript
// 修改为：
this.exchange('qr_code', this.data.qr_code)
```
### <font color="red">[语法错误] 函数名拼写错误 `handeleCancel`</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/apply-refund/apply-refund.js`
- **行号**: 约 38 行
- **问题描述**: 方法名定义为 `handeleCancel()`，存在明显拼写错误（应为 `handleCancel`）。若 WXML 模板中绑定的是标准命名 `bindtap="handleCancel"`，将导致点击事件无法触发，弹窗无法关闭。
- **修复建议**:
```javascript
// 将 handeleCancel 重命名为 handleCancel
handleCancel() {
this.setData({ showConfirm: false })
}
```
### <font color="red">[跨文件调用] 模块级 WebSocket 变量导致多实例状态污染</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `open-result/open-result.js`, `pay-success/pay-success.js`
- **行号**: 文件顶部 `let SocketTask = null` / `let socketOpen = false`
- **问题描述**: 微信小程序中，模块级变量在页面多次打开、复用或快速切换时会**全局共享**。`SocketTask` 和 `socketOpen` 定义在模块作用域，会导致不同页面实例或多次进入时连接状态混乱、旧连接未正确关闭、内存泄漏或重复触发 `onMessage`。
- **修复建议**: 将 WebSocket 实例移至页面实例属性或 `data` 中，确保生命周期隔离：
```javascript
Page({
data: { socketTask: null, socketOpen: false },
// 使用时改为 this.data.socketTask 或 this.socketTask
})
```
### [逻辑 BUG] `handleConfirm` 复用确认弹窗导致业务逻辑冲突
- **严重程度**: 高危
- **文件**: `order-list/order-list.js`
- **行号**: 约 385 行
- **问题描述**: `handleConfirm` 方法通过 `tabIndex` 同时处理了“确认提前开机”（tabIndex==0）和“删除酒水订单”（tabIndex==2）。共用同一个 `showConfirm` 状态和 `confirmTxt` 极易引发状态覆盖、误操作或回调错位。
- **修复建议**: 拆分确认逻辑，或增加 `confirmType` 标识区分业务：
```javascript
handleConfirm() {
if (this.data.confirmType === 'open_machine') {
// 执行开机逻辑
} else if (this.data.confirmType === 'delete_order') {
this.deleteOrder()
}
}
```
### [逻辑 BUG] 数组删除操作未处理 `findIndex` 返回 `-1` 的情况
- **严重程度**: 高危
- **文件**: `order-list/order-list.js`
- **行号**: 约 408 行
- **问题描述**: `let index = this.data.goods_order_list.findIndex(...)` 后直接使用 `slice(0, index)`。若订单未找到（`index === -1`），`slice(0, -1)` 会**错误地删除数组最后一个元素**，导致数据错乱。
- **修复建议**: 增加边界判断：
```javascript
if (index === -1) return; // 未找到则直接返回
this.setData({
goods_order_list: [...this.data.goods_order_list.slice(0, index), ...this.data.goods_order_list.slice(index + 1)]
})
```
### [逻辑 BUG] `reserveModel.openMachine` 方法调用参数数量不一致
- **严重程度**: 高危
- **文件**: `order-detail/order-detail.js`, `open-result/open-result.js`, `order-list/order-list.js`
- **行号**: 多处调用 `reserveModel.openMachine`
- **问题描述**: 同一模型方法在不同页面调用时参数数量不一致（4个、5个、6个参数）。例如 `order-detail.js` 传入了6个参数，而 `open-result.js` 传入了4个。若模型方法未做严格的参数兼容处理，极易导致回调函数错位或逻辑异常。
- **修复建议**: 统一模型方法签名，或改用配置对象传参：
```javascript
// 推荐统一为：reserveModel.openMachine({ family_server_id, order_id, forward_open, success, fail })
```
### [安全隐患] 动态 URL 参数未统一编码导致解析异常
- **严重程度**: 中危
- **文件**: `apply-refund/apply-refund.js`, `order-detail/order-detail.js`, `open-result/open-result.js` 等
- **行号**: 多处 `wx.navigateTo` / `wx.redirectTo` 的 `url` 拼接处
- **问题描述**: 部分参数（如 `voucher_name`, `room_name`, `msg`）直接拼接进 URL，未使用 `encodeURIComponent`。若参数包含 `&`, `=`, `?`, 空格或特殊字符，会导致 URL 截断、参数丢失或路由解析失败。部分文件已使用编码，但标准不统一。
- **修复建议**: 统一对所有动态参数值进行编码：
```javascript
url: `/pages/xxx/xxx?name=${encodeURIComponent(this.data.voucher_name)}`
```
### [逻辑 BUG] `wx.showLoading` 未配对 `wx.hideLoading`
- **严重程度**: 中危
- **文件**: `apply-refund/apply-refund.js`
- **行号**: 约 55 行
- **问题描述**: `doRefund` 中调用 `wx.showLoading()`，但在 `reserveModel.applyBookRefund` 回调中直接执行 `wx.redirectTo`，未调用 `wx.hideLoading()`。若网络请求失败、回调未触发或跳转被拦截，Loading 遮罩将永久显示，阻塞用户操作。
- **修复建议**: 在回调入口处或跳转前显式关闭 Loading，并补充 `fail` 处理：
```javascript
reserveModel.applyBookRefund(..., (res) => {
wx.hideLoading()
wx.redirectTo({ ... })
}, (err) => {
wx.hideLoading()
wx.showToast({ title: '退款失败', icon: 'none' })
})
```
### [代码质量] `setData` 中存在重复键值声明
- **严重程度**: 低危
- **文件**: `order-detail/order-detail.js`
- **行号**: 约 235 行
- **问题描述**: 在同一个 `setData` 对象中，`showCancelBtn: false` 被声明了两次。虽然 JS 引擎会覆盖，但属于冗余代码，易引发维护困惑。
- **修复建议**: 删除重复的键值对。
### [代码质量] `import` 路径扩展名不一致
- **严重程度**: 低危
- **文件**: `apply-result.js`, `continue-packages.js`, `pay-success.js`, `package.js`, `scan-order.js`
- **行号**: 文件顶部 `import` 语句
- **问题描述**: 部分文件省略了 `.js` 后缀（如 `'../../../config'`），而部分文件保留了（如 `'../../../config.js'`）。虽然微信小程序支持省略，但混用会降低代码规范性和 IDE 提示准确性。
- **修复建议**: 全局统一添加 `.js` 后缀，保持风格一致。
## ✅ 代码亮点
1. **生命周期管理清晰**：页面在 `onUnload`/`onHide` 中正确清理了 WebSocket 连接和定时器，避免了内存泄漏。
2. **动态 Tab 逻辑健壮**：`continue-packages.js` 和 `package.js` 中根据 `package_list` 和 `hour_list` 动态生成 `tab_list` 的逻辑处理严谨，边界情况（全空、单有、双有）覆盖完整。
3. **状态机设计合理**：`open-result.js` 和 `order-detail.js` 对开机结果 `type`（1~6）的分发处理清晰，弹窗与路由跳转逻辑解耦良好。
## 📝 总体建议
1. **统一跨模块调用规范**：当前 `reserveModel.openMachine` 等核心方法在不同页面传参差异较大。建议在后端/模型层统一使用**配置对象传参**（如 `{ params, success, fail }`），彻底解决参数错位风险。
2. **强化 WebSocket 实例隔离**：小程序页面具有复用特性，务必将 `SocketTask` 等网络实例绑定到 `this` 或 `data` 上，避免模块级变量引发的竞态条件。
3. **完善异常兜底机制**：多处 `wx.getStorageSync('userInfo')` 未做空值保护，建议封装统一的 Storage 读取工具函数，返回默认空对象，防止 `undefined` 穿透至 UI 或网络请求。
4. **补充 PHP 框架关联检查提示**：本次审查代码均为微信小程序前端 JS，未涉及 PHP CodeIgniter 控制器/模型文件。若后续提交包含 PHP 代码，请确保 `$this->load->model('xxx_model')` 与 `application/models/Xxx_model.php` 严格对应，并检查拼写一致性。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780992775
|
1780992775
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
644
|
21
|
291
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 预订退款
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `afdf33599 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `afdf33599c575f0ec80959371c38eb026bf8e536`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-09 17:06:02
---
## 1. 审查摘要
- **代码质量评分**：5.5 / 10 分
- **总体评价**：业务逻辑覆盖较全面，具备支付回调、退款、消息推送等核心流程。但存在**严重的事务管理缺陷**与**SQL注入隐患**，代码结构冗长、硬编码较多，且频繁动态加载模型影响性能。整体可维护性与安全性亟待提升。
- **风险等级**：🔴 高
> 📌 **框架说明**：根据目录结构（`system/`, `application/models/`）、`$CI =& get_instance()` 及 `$this->load->model()` 等特征，判定该代码基于 **CodeIgniter 3.x** 架构。若 `phpci` 为贵司内部定制框架，请结合其官方文档对事务状态机与模型加载机制进行适配调整。
> ⚠️ **局限性说明**：提供的代码在 `create_community_shop_book_order` 方法末尾截断（`if ($this->tuangou->verify_token) {`），导致该部分逻辑无法完整评估。以下审查基于已提供内容。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `check_notify()` 方法内 | **事务提交后执行关键业务**：`$this->db->trans_complete()` 在方法中段调用，数据库事务已提交。随后执行 `send_success_msg()`、会员回调等逻辑，若此处抛出异常或失败，**数据已落库但业务未闭环**，导致状态不一致。且 `catch` 中尝试 `trans_rollback()` 已无效。 | 将非数据库操作（消息推送、外部API调用）移至事务提交后，并增加补偿/重试机制；或改用显式事务控制，确保 `trans_complete()` 仅在方法末尾执行。 | 见下方重构示例 |
| 🔴 严重 | `refund_by_notify()` 约第 240 行 | **SQL 注入风险**：`$log_where = '_relation_id="' . $order_data['_id'] . '" ...';` 直接拼接字符串传入自定义 `up()` 方法。若 `_id` 含双引号或恶意字符，将破坏 SQL 结构或导致注入。 | 严禁字符串拼接构造 SQL 条件。统一使用 CI 查询构造器或参数绑定。 | `$this->db->where('_relation_id', $order_data['_id'])<br>->where('_status', 1)<br>->where_in('_type', [5, 13])<br>->update('pay_log', ['_status'=>4, ...]);` |
| 🟠 警告 | 文件顶部 | **全局 `$CI` 实例滥用**：`$CI = &get_instance();` 定义在类外部。每次文件被 `include` 时都会执行，浪费内存且违反 CI 规范。模型继承自 `CI_Model`，内部可直接使用 `$this->load`。 | 删除顶部 `$CI` 赋值。在需要加载配置的方法内按需获取，或改用 `$this->load->config('wx', TRUE);`。 | `// 删除顶部 $CI = &get_instance();<br>// 方法内改为：<br>$this->load->config('wx', TRUE);<br>$wx_template = $this->config->item('wx');` |
| 🟠 警告 | 多处方法 | **频繁动态加载模型**：`$this->load->model()` 在业务流中重复调用数十次。虽 CI 有缓存，但增加解析开销、降低可读性，且易引发循环依赖。 | 将高频依赖模型移至 `__construct()` 初始化，或抽离为独立 Service 层。 | `public function __construct() {<br> parent::__construct();<br> $this->load->model(['ahead_book_model', 'ahead_vip_model', 'ahead_pay_log_model']);<br>}` |
| 🟠 警告 | `check_notify()` catch 块 | **异常日志记录不规范**：`json_encode($e->getTrace(), 256)` 中 `256` 非标准 JSON 选项，且完整堆栈序列化可能包含敏感信息（如密码、Token）。 | 记录精简的异常信息（消息、文件、行号），避免在生产环境输出完整 Trace。 | `doLog('支付失败: ' . $e->getMessage() . ' in ' . $e->getFile() . ':' . $e->getLine(), 'book_order');` |
| 🟡 建议 | 全局 | **魔法数字与硬编码泛滥**：大量使用 `-1, 1, 4, 5, 14, 56, 58` 等状态码/模板ID，缺乏语义化定义，后期维护成本极高。 | 提取为类常量或独立配置数组，提升代码自解释能力。 | `const STATUS_PENDING = -1; const STATUS_PAID = 1; const SMS_TPL_BOOKING = 56;` |
| 🟡 建议 | 全局 | **违反 PSR-12 规范**：混用 `array()` 与 `[]`；方法过长（`refund_by_notify` 超 150 行）；注释风格不统一；函数命名 `doLog`/`do_log` 不一致；存在过时注释（如 `//add by nan 18.1.22`）。 | 统一使用短数组语法；拆分超长方法；使用 PHP-CS-Fixer 自动格式化；清理历史注释。 | 建议配置 `.php-cs-fixer.php` 并执行 `php-cs-fixer fix` |
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **重构事务控制逻辑**：`check_notify` 与 `refund_by_notify` 中的事务管理是最高风险点。建议采用 **显式事务控制** 或 **延迟提交策略**，确保数据库操作与外部服务调用解耦。
2. **消除 SQL 拼接隐患**：全面排查 `$log_where` 及类似字符串拼接 SQL 的地方，替换为 CI Query Builder 或 PDO 参数绑定。
3. **清理全局 `$CI` 与模型加载**：移除文件顶部的 `$CI =& get_instance()`，将模型加载收敛至构造函数或依赖注入容器，降低运行时开销。
### 🛠 后续重构与优化方向
- **架构分层**：当前 Model 承担了过多职责（支付、退款、消息推送、库存扣减、会员逻辑）。建议引入 **Service 层**，将 `check_notify`、`refund_by_notify` 拆分为独立的 `PaymentService` 与 `RefundService`，Model 仅负责数据持久化。
- **状态机管理**：订单状态流转（`-1 → 1 → 4` 等）建议使用状态机模式或枚举类管理，避免硬编码判断，提升业务扩展性。
- **统一日志与异常处理**：建立全局异常拦截器，规范 `doLog`/`do_log` 调用，敏感数据脱敏后再落盘。
- **补充单元测试**：针对支付回调、退款分支、库存扣减等核心链路编写 PHPUnit 测试用例，覆盖正常流、并发冲突、第三方 API 超时等边界场景。
> 💡 **提示**：若 `phpci` 框架对事务或模型加载有特殊封装，请以官方文档为准。建议在修复上述高危问题后，使用静态分析工具（如 `PHPStan` 或 `Psalm`）进行全量扫描，进一步收敛潜在缺陷。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780995962
|
1780995962
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
645
|
21
|
292
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - refund_method
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `8a99434b2 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `8a99434b2373fa9a9942af59296889b958ee96d1`
**提交人**: linyangrui (yangruilin888@gmail.com)
**时间**: 2026-06-09 17:12:13
---
## 📋 审查摘要
- **变更文件数**: 1
- **严重问题**: 1
- **高危问题**: 3
- **中危问题**: 2
- **建议优化**: 4
## 🐛 发现的问题
### <font color="red">[语法错误] 未安全处理空值导致潜在运行时崩溃</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 约 68 行
- **问题描述**: `const uid = wx.getStorageSync('userInfo').uid || ''` 中，若本地缓存中不存在 `userInfo` 或其值为 `null`/`undefined`，直接访问 `.uid` 会抛出 `TypeError: Cannot read properties of null (reading 'uid')`，导致页面白屏崩溃。
- **修复建议**: 使用可选链操作符或安全取值：
```javascript
const userInfo = wx.getStorageSync('userInfo') || {};
const uid = userInfo.uid || '';
```
### <font color="red">[跨文件调用] 模型方法调用参数类型不一致/疑似传参错误</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 约 115、188、285 行
- **问题描述**: `reserveModel.openMachine` 方法在多处被调用，但第 5 个参数类型不一致。首次调用传空字符串 `''`，后续调用传数字 `1`。若底层模型未做类型兼容，将导致参数解析错误或静默失败。
- **修复建议**: 统一参数类型，或查阅 `reserve.js` 确认该参数语义（如是否为 `skip_clean_check` 标识）。建议统一使用布尔值或明确定义的枚举值，例如：
```javascript
// 统一传参示例
reserveModel.openMachine(url, this.data.order_id, forward_open, successCallback, false, completeCallback)
```
### [安全隐患] 路由跳转参数未进行 URL 编码，存在路由断裂或注入风险
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 约 108 行
- **问题描述**: `onApplyClick` 方法中拼接跳转 URL 时，`voucher_name` 未使用 `encodeURIComponent` 编码。若该字段包含 `&`、`=`、`#` 或特殊字符，将破坏 URL 结构，导致目标页面接收参数错乱，甚至引发 XSS 或路由劫持。
- **修复建议**: 对所有动态拼接的 URL 参数进行编码：
```javascript
url: '/pages/community-reserve/apply-refund/apply-refund?order_id=' + this.data.order_id +
'&actual_pay=' + this.data.order_detail.actual_pay +
'&voucher_name=' + encodeURIComponent(this.data.order_detail.voucher_name) +
'&voucher_can_refund=' + this.data.order_detail.voucher_can_refund
```
### [逻辑 BUG] 弹窗状态初始值设置错误，导致页面加载即显示阻断弹窗
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 约 48 行
- **问题描述**: `data` 中 `showCantConvertPop: true` 的注释为“当前时间不允许自助转房弹窗是否显示”。默认值为 `true` 会导致页面一进入就强制弹出该提示，不符合常规交互逻辑，且会阻断用户操作。
- **修复建议**: 将初始值改为 `false`，仅在满足特定业务条件时通过 `setData` 动态开启：
```javascript
showCantConvertPop: false, // 默认隐藏
```
### [逻辑 BUG] wx.showToast 的 success 回调误用，导致导航时机不可控
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 约 298 行
- **问题描述**: `wx.showToast` 的 `success` 回调是在 Toast **显示时**立即触发，而非消失后触发。在 `success` 中直接调用 `wx.navigateTo` 会导致页面跳转与 Toast 动画冲突，Toast 可能被瞬间销毁或跳转失败。
- **修复建议**: 移除 `success` 回调，直接执行跳转，或使用 `setTimeout` 延迟跳转以保证用户体验：
```javascript
wx.showToast({ title: '变更成功!', icon: 'success' });
setTimeout(() => {
wx.navigateTo({ url: '/pages/...' });
}, 1500);
```
### [中危] 页面卸载后执行定时器回调可能引发内存泄漏或报错
- **严重程度**: 中危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 约 175 行
- **问题描述**: `onChangeOrderClick` 中使用了 `setTimeout(() => { this.getOrderDetail() }, 5000)`。若用户在 5 秒内返回上一页或关闭小程序，`this` 指向的页面实例可能已被销毁，此时调用 `this.getOrderDetail()` 会报错或造成内存泄漏。
- **修复建议**: 在 `onUnload` 生命周期中清理定时器，或使用 `wx.navigateBack` 配合页面栈刷新替代定时器：
```javascript
// 在 data 中记录 timerId
this.timerId = setTimeout(() => { this.getOrderDetail() }, 5000);
// 在 onUnload 中清除
onUnload() { clearTimeout(this.timerId); }
```
### [代码质量] 变量命名拼写错误及冗余赋值
- **严重程度**: 建议优化
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js`
- **行号**: 约 38、41、198 行
- **问题描述**:
1. `avilable_room_list` 拼写错误，应为 `available_room_list`（多处使用）。
2. `operfrom` 拼写错误，应为 `operateFrom` 或 `operFrom`。
3. `handleOpenMachineResult` 中 `showCancelBtn: false,` 被连续赋值两次（约 198、200 行），属冗余代码。
- **修复建议**: 全局替换拼写错误，删除重复的 `showCancelBtn: false` 赋值。保持命名符合驼峰规范。
## ✅ 代码亮点
1. **状态管理清晰**：使用 `data` 集中管理弹窗显示状态（`showScanPop`, `showConfirm` 等），配合 `setData` 更新，符合微信小程序 MVVM 规范。
2. **业务边界处理完善**：在 `onApplyClick` 和 `onChangeOrderClick` 中充分考虑了退款/变更的时间限制、次数限制及商家操作状态，用户体验闭环较好。
3. **模块化调用**：合理拆分了 `ReserveModel`、`OrderModel`、`CabinetModel`，职责分离清晰，便于后期维护。
## 📝 总体建议
1. **强化防御性编程**：小程序环境网络与缓存状态多变，所有 `wx.getStorageSync`、API 返回的 `res.result` 都应进行空值/类型校验后再访问属性。
2. **统一路由参数处理**：建议封装一个 `buildUrl(path, params)` 工具函数，自动处理 `encodeURIComponent`，避免手动拼接遗漏。
3. **规范模型接口契约**：跨文件调用 `reserveModel.openMachine` 时参数类型混乱，建议在 `reserve.js` 中明确定义 JSDoc 注释，或使用 TypeScript 约束参数类型，防止后续维护出现隐式 Bug。
4. **清理冗余与拼写**：尽快修正 `avilable`、`operfrom` 等拼写错误，避免后续开发者产生误解或引发连锁引用问题。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780996333
|
1780996333
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
646
|
21
|
293
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 关房文案
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `52b3c6985 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `52b3c69852cbf94ac325eaf9428d5306d9dc0245`
**提交人**: linyangrui (yangruilin888@gmail.com)
**时间**: 2026-06-09 17:27:27
---
## 📋 审查摘要
- **变更文件数**: 1
- **严重问题**: 0
- **高危问题**: 3
- **中危问题**: 2
- **建议优化**: 4
## 🐛 发现的问题
### <font color="red">[跨文件调用] 模型文件缺失且方法调用签名不一致</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js
- **行号**: 约 10-12, 115, 235, 335
- **问题描述**:
1. 代码引入了 `ReserveModel`, `OrderModel`, `CabinetModel`，但提供的项目结构为 PHP CodeIgniter 框架，**未提供对应的 JS 模型文件**，无法验证这些类及 `getBookOrderDetail`, `openMachine`, `reOpenCabinetDoor` 等方法是否真实存在。
2. `reserveModel.openMachine` 在多处调用时参数数量和语义不一致：
- 第115行：`openMachine(url, order_id, forward_open, success, '', fail)`
- 第235行：`openMachine(family_server_id, order_id, 1, success, '', fail)`
- 第335行：`openMachine(family_server_id, order_id, 1, success, 1, fail)`
参数位置混用极易导致模型层解析错位或抛出 `TypeError`。
- **修复建议**:
1. 补充 `../../../models/reserve.js` 等文件以完成跨文件验证。
2. 统一方法签名，强烈建议改为对象传参：`reserveModel.openMachine({ url, orderId, forwardOpen, success, fail })`，避免位置参数歧义。
### <font color="red">[语法错误] 未安全访问 Storage 对象导致潜在 TypeError</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js
- **行号**: 约 48
- **问题描述**: `const uid = wx.getStorageSync('userInfo').uid || ''`。若本地未缓存 `userInfo` 或缓存值非对象类型，直接访问 `.uid` 会触发 `TypeError: Cannot read properties of undefined`，导致小程序页面直接白屏崩溃。
- **修复建议**: 使用可选链操作符或前置判空：
```javascript
const userInfo = wx.getStorageSync('userInfo');
const uid = userInfo?.uid || '';
```
### [安全隐患] 动态拼接 HTML 字符串存在 XSS 风险
- **严重程度**: 高危
- **文件**: web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js
- **行号**: 约 198-208
- **问题描述**: `confirmContent` 直接拼接了 `res.result.book_time` 和 `res.result.reset_book_time` 等后端返回数据到 HTML 字符串中。若后端接口未做严格过滤，攻击者可通过篡改这些字段注入恶意 `<script>` 或事件属性，在支持富文本渲染的自定义组件中触发 XSS。
- **修复建议**: 对后端返回的字符串进行 HTML 实体转义，或使用小程序官方 `<rich-text>` 组件配合严格的节点白名单过滤，禁止直接拼接不可信数据。
### [逻辑 BUG] `setData` 对象中存在重复键名
- **严重程度**: 中危
- **文件**: web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js
- **行号**: 约 218
- **问题描述**: 在 `handleOpenMachineResult` 的 `type == 2` 分支中，`showCancelBtn: false` 被连续定义了两次。虽然 JS 引擎会以后者覆盖前者，但属于冗余代码，易引发维护困惑或后续合并冲突。
- **修复建议**: 删除重复的 `showCancelBtn: false` 键值对，保持对象字面量整洁。
### [逻辑 BUG] 数组访问未做边界保护
- **严重程度**: 中危
- **文件**: web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js
- **行号**: 约 418
- **问题描述**: `this.data.timeSliceList[this.data.recommendIndex].fragment_period_key`。虽然前置判断了 `recommendIndex != -1`，但未校验 `timeSliceList` 实际长度是否大于该索引。若后端返回空数组或数据异常，仍会引发 `Cannot read properties of undefined` 崩溃。
- **修复建议**: 增加安全访问逻辑：
```javascript
const selectedItem = this.data.timeSliceList[this.data.recommendIndex];
if (!selectedItem) {
wx.showToast({ title: '时段数据异常', icon: 'none' });
return;
}
```
### [代码质量] 魔法数字硬编码
- **严重程度**: 建议优化
- **文件**: web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js
- **行号**: 多处（如 `status == 5`, `operational_scene == 1/2/3/4`, `type == 1/2/4/5/6`）
- **问题描述**: 订单状态、业务场景、弹窗类型等大量使用数字硬编码，可读性差，后续新增场景时极易遗漏或写错。
- **修复建议**: 提取为常量枚举文件（如 `constants/order.js`）：
```javascript
export const ORDER_STATUS = { IN_PROGRESS: 5 };
export const SCENE_TYPE = { ROOM: 1, TABLE: 2, CARD: 4 };
export const OPEN_RESULT_TYPE = { SUCCESS: 1, CONFIRM: 2, ROOM_MISMATCH: 4, ERROR: 5, UNCLEAN: 6 };
```
### [代码质量] `wx.showLoading` 缺少全局异常兜底
- **严重程度**: 建议优化
- **文件**: web/Hi-Zan/Hi-Zan/pages/community-reserve/order-detail/order-detail.js
- **行号**: 约 65, 85, 113, 148 等
- **问题描述**: 多处直接调用 `wx.showLoading()`，但完全依赖模型回调中的 `wx.hideLoading()`。若网络请求超时、DNS解析失败或模型层未正确触发 fail 回调，Loading 遮罩将永久显示，阻塞用户操作。
- **修复建议**: 在请求发起前设置超时自动隐藏，或在模型层封装统一的 Request 拦截器处理 Loading 状态的生命周期。
## ✅ 代码亮点
1. **状态管理清晰**：使用 `data` 集中控制各类弹窗（`showScanPop`, `showConfirm`, `showChangeRoomPop` 等）的显隐，符合微信小程序组件化开发的最佳实践。
2. **业务分支明确**：针对 `bigType`（预订单/现场单）做了清晰的路由分离，逻辑隔离良好，降低了耦合度。
3. **交互细节完善**：充分考虑了提前开机确认、未清扫换房提示、碎片时段推荐、商家变更拦截等边缘场景，用户体验设计较为成熟。
## 📝 总体建议
1. **⚠️ 上下文严重不匹配**：提供的项目结构为 `PHP CodeIgniter` 框架，但审查代码为 `微信小程序 JS`。跨文件引用验证因缺少 `models/` 目录源码无法彻底完成。**请务必补充对应的 JS 模型文件**，否则 `ReserveModel` 等方法调用存在极高风险。
2. **健壮性优先**：立即修复 `wx.getStorageSync` 的空指针问题，统一 `openMachine` 等核心方法的调用签名，增加数组/对象的安全访问逻辑，避免线上白屏。
3. **安全与规范**：对富文本内容进行转义处理，提取魔法数字为常量枚举，统一 Loading 状态管理。建议接入 `ESLint` + `Prettier` 进行静态检查，自动拦截重复键名等低级语法问题。
4. **架构优化**：当前页面承担了过多的业务逻辑（近 400 行）。建议将弹窗控制、状态计算、API 请求封装为独立的 `Behavior` 或 `Mixin`，保持 Page 实例的轻量与可测试性。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780997247
|
1780997247
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
647
|
21
|
294
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - applyBookRefund
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `98f24d0d2 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `98f24d0d2e8840d59952c676882a04847b1378b0`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-09 17:29:32
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：该控制器承载了小程序预订核心链路（选店、选包厢、下单、开房、退款、变更、AI交互等），业务覆盖完整。但存在**构造函数职责过重、框架超对象滥用、事务处理不规范、死代码残留及 PSR-12 规范缺失**等问题。部分逻辑依赖隐式约定，可维护性与安全性存在隐患。
- **风险等级**：中（存在事务状态覆盖风险、订单路由误判风险及框架非标准用法）
> 📌 **框架说明**：代码实际基于 **CodeIgniter 3** 架构（`BASEPATH`、`get_instance()`、`$this->load->model()` 等特征）。若 `phpci` 为内部定制框架，请对照其官方文档核对生命周期与组件加载差异。以下建议以 CI3/现代 PHP 规范为准。
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `Book.php` / 第 450~480 行 (`communityNotCleanChangeBook`) | 数据库事务处理存在状态覆盖风险。手动调用 `$this->db->trans_rollback()` 后未终止执行，后续 `$this->db->trans_complete()` 仍会执行，可能导致事务状态混乱或重复提交。 | 使用 `try-catch` 统一管控事务，或确保回滚后直接 `return`。推荐将事务逻辑收敛至 Model 层。 | ```php<br>$this->db->trans_start();<br>try {<br> // 业务逻辑...<br> $this->db->trans_complete();<br>} catch (\Exception $e) {<br> $this->db->trans_rollback();<br> $this->error_response($e->getMessage());<br>}<br>``` |
| 🔴 严重 | `Book.php` / 第 3 行 | 父类引入使用 `include` 且路径拼接冗长，未使用框架常量，易导致重复加载或路径解析失败。 | 改用 `require_once` 配合 `APPPATH` 常量，符合 CI 规范。 | `require_once APPPATH . 'controllers/mini/hz/Index.php';` |
| 🟠 警告 | `Book.php` / 第 330 行 (`checkBookReceipt`) | `if (false && $order_id)` 为硬编码死代码。逻辑被强制跳过，后续维护者易产生困惑，且可能遗漏业务开关。 | 移除死代码，或改为配置项/数据库开关控制。 | `if ($order_id) { /* 恢复原逻辑 */ }` |
| 🟠 警告 | `Book.php` / 第 380 行 (`communityOpenDoor`) | 使用 `strpos($order_id, 'CYD') !== false` 判断订单类型。若订单号包含 `CYD` 但非预订单（如备注字段污染），将导致路由错乱。 | 使用严格前缀匹配或基于订单表 `type` 字段校验。 | `if (str_starts_with($order_id, 'CYD')) { ... }`<br>*(PHP 8+ 可用 `str_starts_with`，低版本用 `substr($order_id, 0, 3) === 'CYD'`)* |
| 🟠 警告 | `Book.php` / 构造函数 (~L20, L60) | 频繁使用 `$CI = &get_instance()` 动态修改超全局对象属性（如 `error_status`, `operational_scene`）。破坏框架封装性，且 `$this` 在控制器中已是实例，无需重复获取。 | 使用 `$this->config->set_item()` 或父类属性传递状态，避免污染 CI 超对象。 | `$this->config->set_item('error_status', 2333);`<br>`$this->operational_scene = $this->param['operational_scene'] ?? 1;` |
| 🟡 建议 | `Book.php` / 第 130 行 (`getCommunityShopBookInfo`) | `is_valid_json()` 为自定义函数，未处理 `json_decode` 失败场景。若传入非法字符串，可能触发 Warning 或返回 `null` 导致后续数组访问报错。 | 使用原生 `json_decode` 配合 `json_last_error()` 或 `JSON_THROW_ON_ERROR` (PHP 7.3+)。 | ```php<br>$decoded = json_decode($shop_guide_info, true);<br>if (json_last_error() === JSON_ERROR_NONE && is_array($decoded)) {<br> $data['shop_guide_info'] = $decoded;<br>}<br>``` |
| 🟡 建议 | `Book.php` / 第 50 行 | `strpos($this->function_name, 'ChangeBook') !== false \|\| strpos(..., 'changeBook')` 冗余。且 `$unnecessary_shop_id_function` 暴露为 `public`，易被外部篡改。 | 使用 `stripos` 简化判断；属性改为 `protected`；使用 `array_flip` 或 `isset` 提升查找性能。 | `protected $unnecessary_shop_id_function = [...];`<br>`if (stripos($this->function_name, 'changebook') === false) { ... }` |
| 🟡 建议 | 全局方法命名 | 方法命名风格不统一（如 `tuanGouVerify`、`communityOpenRoom` 混用大小写），不符合 PSR-12 `camelCase` 规范。 | 统一重构为小驼峰命名，提升可读性与 IDE 提示体验。 | `tuanGouVerify` → `tuangouVerify`<br>`getRoomPackgeTimePriceInfo` → `getRoomPackageTimePriceInfo` (修正拼写) |
## 3. 总结与行动建议
### 🚨 优先修复项（P0/P1）
1. **事务安全加固**：`communityNotCleanChangeBook` 中的事务回滚逻辑必须收敛。建议将 `trans_start()` / `trans_complete()` 移至 Model 层，或在 Controller 中使用 `try-catch` 确保异常时安全回滚并终止响应。
2. **清理死代码与硬编码**：移除 `checkBookReceipt` 中的 `if (false && ...)`，改为可配置开关；修正父类引入路径为 `require_once APPPATH . '...'`。
3. **订单类型路由安全**：将 `strpos($order_id, 'CYD')` 替换为严格前缀匹配，避免字符串包含误判导致越权或逻辑错乱。
### 🛠 后续重构方向
1. **构造函数瘦身**：当前构造函数承担了参数校验、模型加载、状态注入、业务预处理等职责，违反单一职责原则。建议：
- 将 `shop_id` 校验、`merchant_id` 绑定等前置逻辑移至父类 `Index` 的中间件或钩子中。
- 按需延迟加载模型（`$this->load->model()` 移至具体方法内），减少内存占用。
2. **统一响应与状态管理**：废弃 `$CI = &get_instance()` 动态赋值模式。建议封装统一的 `ApiResponse` 类或使用 CI 的 `Output` 类处理状态码与业务数据，避免全局变量污染。
3. **安全与规范对齐**：
- 所有外部输入（`$this->param`）应在 Model 层使用 Query Builder 参数绑定，严禁拼接 SQL。
- 遵循 PSR-12 规范：统一方法命名、补充空格、修正拼写错误（如 `Pakcage` → `Package`）。
- 敏感操作（退款、开房、门锁控制）建议增加操作日志记录与幂等性校验（如基于 `request_frequency` 的 Token 防重放）。
> 💡 **提示**：若 `phpci` 为内部框架且对控制器生命周期、模型加载有特定约束，请优先遵循其官方文档。本审查基于 CodeIgniter 3 最佳实践与 PHP 8 现代语法提供，可直接落地参考。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780997372
|
1780997372
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
648
|
21
|
295
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 卡券续费查询用户卡券需要shop_id
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `51041ff98 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `51041ff98a6f987d6f01b3910b6092dc6231d4bb`
**提交人**: linyangrui (yangruilin888@gmail.com)
**时间**: 2026-06-09 17:35:58
---
## 📋 审查摘要
- **变更文件数**: 1
- **严重问题**: 2
- **高危问题**: 3
- **中危问题**: 2
- **建议优化**: 4
## 🐛 发现的问题
### <font color="red">[语法错误] 潜在的空指针/运行时崩溃（未处理 find 返回 undefined）</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-list/order-list.js`
- **行号**: 约 118 行
- **问题描述**: `this.data.status_list.find(item => item.value == this.data.status).name` 在 `this.data.status` 的值不在 `status_list` 中时，`find()` 会返回 `undefined`，直接调用 `.name` 将触发 `TypeError: Cannot read properties of undefined (reading 'name')`，导致页面白屏崩溃。
- **修复建议**: 使用可选链操作符或提供默认值：
```javascript
const matchedStatus = this.data.status_list.find(item => item.value == this.data.status);
this.setData({
status_name: matchedStatus ? matchedStatus.name : '全部状态',
});
```
### <font color="red">[跨文件调用] 方法调用参数数量不一致/签名不匹配</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-list/order-list.js`
- **行号**: 约 330、440、465 行
- **问题描述**: `reserveModel.openMachine` 在多处被调用，但传入的参数数量和顺序不一致：
1. `openMachine(url, this.data.oper_order.id, forward_open, callback)` (4个参数)
2. `openMachine(this.data.family_server_id, this.data.oper_order.id, 1, callback, 1)` (5个参数，多了一个末尾的 `1`)
3. `openMachine(this.data.family_server_id, this.data.oper_order.id, 1, callback)` (4个参数)
这种不一致极易导致底层模型方法解析错位、回调丢失或静默失败，属于典型的跨文件调用契约破坏。
- **修复建议**: 统一 `reserveModel.openMachine` 的函数签名。建议改为接收配置对象或固定参数顺序，例如：
```javascript
// 模型层定义建议：openMachine(params, callback)
// 调用层统一为：
reserveModel.openMachine({
url: url,
orderId: this.data.oper_order.id,
forwardOpen: forward_open,
extraFlag: 1 // 如有需要
}, (res) => { ... })
```
### [逻辑 BUG] 数组删除逻辑存在越界/误删风险
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-list/order-list.js`
- **行号**: 约 535 行
- **问题描述**: `deleteOrder` 方法中使用 `findIndex` 查找订单索引，若因网络延迟或数据不同步导致 `findIndex` 返回 `-1`，执行 `slice(0, -1)` 会错误地删除数组最后一个元素，`slice(0)` 则返回完整数组，导致列表状态错乱。
- **修复建议**: 增加索引校验，或改用 `filter` 安全删除：
```javascript
const index = this.data.goods_order_list.findIndex(item => item.order_id == this.data.del_order_id);
if (index > -1) {
const newList = [...this.data.goods_order_list];
newList.splice(index, 1);
this.setData({ goods_order_list: newList });
}
// 或直接使用 filter:
// this.setData({ goods_order_list: this.data.goods_order_list.filter(item => item.order_id !== this.data.del_order_id) });
```
### [安全隐患] 动态拼接 HTML 字符串存在 XSS 风险
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-list/order-list.js`
- **行号**: 约 360~375 行
- **问题描述**: `confirmContent` 使用模板字符串拼接了 `<span style="...">` 等 HTML 标签，并配合 `contentIsNodes: true` 渲染。若 `res.result.reset_book_time` 或 `this.data.oper_order.book_time` 包含恶意脚本（如 `<img src=x onerror=alert(1)>`），将直接触发 XSS 攻击。
- **修复建议**: 避免在 JS 中拼接 HTML。应在 WXML 中使用数据绑定，或使用微信小程序提供的安全渲染机制。若必须使用富文本，需对后端返回的数据进行严格的 HTML 实体转义或白名单过滤。
### [代码质量] 魔法数字与硬编码过多，缺乏常量管理
- **严重程度**: 中危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-list/order-list.js`
- **行号**: 全文多处（如 `tabIndex == 0/1/2`，`status` 值 `'1'/'2'/'5'`，`operational_scene` 值 `1/2/3/4`）
- **问题描述**: 业务状态码、Tab 索引、场景类型等大量使用硬编码数字。可读性差，后期维护或新增状态时极易遗漏判断分支，引发逻辑漏洞。
- **修复建议**: 提取为枚举常量或配置文件：
```javascript
const TAB_TYPE = { BOOK: 0, ROOM: 1, GOODS: 2 };
const ORDER_STATUS = { ALL: '', UNUSED: '1', USED: '2', EXPIRED: '3', REFUNDED: '4', IN_PROGRESS: '5', CANCELLED: '6' };
// 后续判断改为：if (this.data.tabIndex === TAB_TYPE.BOOK)
```
### [代码质量] handleConfirm 方法职责不单一
- **严重程度**: 中危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-list/order-list.js`
- **行号**: 约 505 行
- **问题描述**: `handleConfirm` 同时处理了“确认提前开机”和“确认删除订单”两种完全无关的业务逻辑，通过 `tabIndex` 进行分支判断。违反单一职责原则，增加耦合度，后续若新增确认弹窗类型，该方法将无限膨胀。
- **修复建议**: 拆分为独立方法，如 `handleConfirmEarlyOpen()` 和 `handleConfirmDelete()`，在弹窗组件的 `bindconfirm` 事件中通过 `data-action` 或独立回调绑定对应方法。
## ✅ 代码亮点
1. **结构清晰**：页面生命周期、数据初始化、业务方法分类明确，注释规范，符合微信小程序开发规范。
2. **状态管理合理**：合理使用 `setData` 控制 UI 状态（如弹窗显隐、加载状态、分页标志），用户体验流畅。
3. **防重复提交意识**：在关键操作（如开门、删除）前调用 `wx.showLoading()`，并在回调中 `wx.hideLoading()`，有效防止用户重复点击。
4. **分页加载逻辑完整**：`hasMore` 与 `page` 递增逻辑闭环完整，下拉/上滑加载更多体验良好。
## 📝 总体建议
1. **统一底层 API 契约**：当前 `reserveModel`、`orderModel`、`roomModel` 的回调参数数量、成功/失败回调结构不一致（如有的传 `(success, error)`，有的只传 `success`）。建议在 Model 层统一封装为 `Promise` 或标准 `(res, err)` 格式，降低调用方心智负担。
2. **强化边界防御**：前端直接依赖后端返回的数据结构（如 `res.result.xxx`），缺乏空值/类型校验。建议在关键数据赋值前增加 `if (res && res.result)` 等防御性编程，或使用可选链 `res?.result?.xxx`。
3. **抽离公共逻辑**：`getBookOrderList`、`getMyRoomOrderList`、`getGoodsOrderList` 的分页与列表合并逻辑高度重复。可封装为通用方法 `fetchList(apiFn, listKey, params)`，减少冗余代码。
4. **安全加固**：所有跳转 URL 拼接的参数建议统一使用 `encodeURIComponent` 包裹；涉及金额、状态变更的操作，务必在后端进行二次权限与状态校验，不可仅依赖前端状态。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780997758
|
1780997758
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
649
|
21
|
296
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616 🔍 代码审查报告：pay-260616 - Merge branch 'pay-260616' of https://gitea.g-hi.co...
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `6280ae8dc ## 自动代码审查报告
**分支**: pay-260616
**提交**: `6280ae8dcba40d7f0e7ed8d6e14cea5efb25ed32`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-09 17:41:23
---
## 📋 审查摘要
- **变更文件数**: 2
- **严重问题**: 3
- **高危问题**: 4
- **中危问题**: 3
- **建议优化**: 4
## 🐛 发现的问题
### <font color="red">[语法错误] PHP文件顶部直接调用 get_instance() 导致框架初始化失败</font>
- **严重程度**: <font color="red">严重</font>
- **文件**: `application/models/Ahead_shop_config_second_model.php`
- **行号**: 第 3 行
- **问题描述**: 在类定义外部直接执行 `$CI = &get_instance();`。CodeIgniter 框架的超级对象（Super Object）仅在控制器实例化后才会通过 `get_instance()` 返回。在模型文件加载阶段（通常早于控制器实例化）调用此函数会返回 `null` 或直接抛出 `Fatal error: Call to undefined function get_instance()`，导致整个应用崩溃。
- **修复建议**: 删除文件顶部的 `$CI = &get_instance();` 和 `$CI->load->model('Simple_model');`。在 CI 模型中，应直接使用 `$this->load->model()` 加载依赖，或在具体方法内部按需加载。
### <font color="red">[跨文件调用] 调用了未定义的自定义辅助函数</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `application/models/Ahead_shop_config_second_model.php`
- **行号**: 第 338, 352, 353, 355, 446 行等
- **问题描述**: 代码中多处直接调用了 `throwError()`, `hourToTime()`, `timeToHour()`, `minToStr()`, `get_business_date()` 等函数。这些并非 PHP 内置函数或 CI 标准辅助函数。若未在 `autoload.php` 中全局加载或未在当前文件 `require/include`，将触发 `Fatal error: Uncaught Error: Call to undefined function`。
- **修复建议**:
1. 确认这些函数是否定义在自定义 Helper 中，并在控制器或 `autoload.php` 中通过 `$this->load->helper('your_helper')` 加载。
2. 若为全局函数，建议在文件顶部显式引入或改用类方法封装，避免隐式依赖。
### <font color="red">[跨文件调用] JS 模型文件引用路径及类名未经验证</font>
- **严重程度**: <font color="red">高危</font>
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-list/order-list.js`
- **行号**: 第 2-5 行
- **问题描述**: 引入了 `ReserveModel`, `PublicModel`, `OrderModel`, `RoomModel`。根据微信小程序规范，需确保 `../../../models/reserve.js` 等文件真实存在，且内部正确 `export` 了对应类。若文件缺失或导出名称不匹配，页面加载时将直接白屏报错。
- **修复建议**: 核对项目目录结构，确保 `models/` 目录下存在对应 `.js` 文件，且导出语法为 `export class ReserveModel { ... }`。建议在开发环境开启严格模式验证模块依赖。
### [逻辑BUG] Array.find() 未处理未匹配情况导致运行时 TypeError
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-list/order-list.js`
- **行号**: 第 118 行
- **问题描述**: `this.data.status_list.find(item => item.value == this.data.status).name`。当 `this.data.status` 传入的值不在 `status_list` 中时（例如脏数据或新增状态未同步），`find()` 返回 `undefined`，紧接着访问 `.name` 会抛出 `TypeError: Cannot read properties of undefined (reading 'name')`，导致页面崩溃。
- **修复建议**: 增加安全判断或使用可选链：
```javascript
const matchedStatus = this.data.status_list.find(item => item.value == this.data.status);
this.setData({
status_name: matchedStatus ? matchedStatus.name : '全部状态'
});
```
### [安全隐患] URL 参数拼接未全面使用 encodeURIComponent
- **严重程度**: 高危
- **文件**: `web/Hi-Zan/Hi-Zan/pages/community-reserve/order-list/order-list.js`
- **行号**: 第 245, 263, 270, 277 行等
- **问题描述**: 多处使用字符串拼接构造跳转 URL，如 `'?order_id=' + this.data.oper_order.id + '&type=1...'`。虽然当前业务字段多为数字，但若未来 `shop_id`、`room_id` 或 `shelf_name` 包含特殊字符（如 `&`, `=`, `?`, 中文），将破坏 URL 结构，导致参数解析错误或路由跳转失败。
- **修复建议**: 对所有动态参数统一使用 `encodeURIComponent()` 包裹，或使用微信官方推荐的 `wx.navigateTo` 参数对象化写法（若框架支持）。
### [逻辑BUG] PHP 静态缓存未处理空值且缺乏清理机制
- **严重程度**: 中危
- **文件**: `application/models/Ahead_shop_config_second_model.php`
- **行号**: 第 108, 468, 508 行
- **问题描述**: 使用 `self::$shop_config[$shop_id]` 进行请求级缓存。若 `$this->get_one()` 查询不到数据返回 `false` 或 `null`，该空值会被缓存。后续同一请求中再次调用将直接返回缓存的空值，可能导致业务逻辑误判（如认为配置已存在但实际为空）。此外，静态变量在 CLI 脚本或长连接服务中不会自动释放，可能引发内存泄漏或脏数据。
- **修复建议**: 缓存前判断结果有效性，或提供 `clearCache($shop_id = null)` 方法。建议改用 CI 的 `Cache` 库或 Redis 进行分布式缓存。
### [代码质量] PHP 模型中 switch 语句过长，违反单一职责原则
- **严重程度**: 中危
- **文件**: `application/models/Ahead_shop_config_second_model.php`
- **行号**: 第 110-320 行
- **问题描述**: `get_shop_setting()` 方法包含超过 50 个 `case` 分支，代码行数超 200 行。该函数承担了数据查询、类型转换、默认值处理、业务规则计算（如时间取整、状态映射）等多重职责，可读性差且极难维护。
- **修复建议**: 采用配置映射表（Config Map）或策略模式重构。例如将默认值和转换逻辑抽离为独立数组或配置文件，通过 `array_key_exists` 和闭包函数动态处理，将函数长度控制在 50 行以内。
### [代码质量] PHP 模型加载命名大小写不一致，存在跨平台兼容性风险
- **严重程度**: 中危
- **文件**: `application/models/Ahead_shop_config_second_model.php`
- **行号**: 第 440, 485 行
- **问题描述**: 混用了 `$this->load->model('Ahead_ai_audio_player_content_model')`（首字母大写）和 `$this->load->model('ahead_shop_model')`（全小写）。CodeIgniter 在 Windows 下不区分文件名大小写，但在 Linux/生产环境中严格区分。若实际文件名与加载字符串大小写不一致，将导致 `Unable to locate the model you have specified` 错误。
- **修复建议**: 统一遵循 CI 规范：模型文件名全小写（如 `ahead_ai_audio_player_content_model.php`），加载时统一使用小写字符串。
## ✅ 代码亮点
1. **JS 状态管理清晰**：小程序页面数据（`data`）结构划分明确（预订单、门店、酒水订单分区），配合 `tabIndex` 和 `loading` 状态控制，交互逻辑完整。
2. **PHP 缓存优化意识**：在 `get_shop_setting` 和 `check_is_cleaned_for_open_room` 中使用了静态变量 `self::$shop_config` 避免重复查询数据库，提升了单次请求性能。
3. **防御性编程**：JS 中多处使用 `e.currentTarget.dataset.item` 安全获取事件参数，PHP 中大量使用 `??` 空值合并运算符设置默认值，降低了空指针风险。
## 📝 总体建议
1. **修复致命依赖问题**：优先处理 PHP 文件顶部的 `get_instance()` 调用和未声明的辅助函数。这是导致应用无法启动或运行时报错的核心原因。
2. **统一跨文件引用规范**：建立项目级的模型/Helper 命名与加载规范。PHP 端严格遵循 `小写文件名 + 小写加载`；JS 端确保 `import` 路径与导出类名一致，可考虑引入 ESLint 进行静态检查。
3. **重构超长 Switch**：建议将 `get_shop_setting` 拆分为 `基础配置获取` + `业务规则处理器`。可引入配置中心或 JSON 映射表，使新增业务场景时无需修改核心模型代码。
4. **增强异常边界处理**：JS 端对网络请求返回值增加 `Array.isArray()` 和 `res.code === 200` 校验；PHP 端对 `throwError` 等自定义异常捕获机制进行统一封装，避免错误堆栈直接暴露给前端。
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780998083
|
1780998083
|
0
|
0
|
0
|
0
|
Edit
Delete
|
|
650
|
21
|
297
|
1
|
|
0
|
🔍 代码审查报告：pay-260616 - 预订退款判断
|
## 自动代码审查报告
**分支**: pay-260616
**提交**: `7e2cd1572 ## 自动代码审查报告
**分支**: pay-260616
**提交**: `7e2cd1572cdc8a693aadf5d382c6ea720a3b5aaa`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-09 17:44:22
---
## 1. 审查摘要
- **代码质量评分**：6.5 / 10 分
- **总体评价**：该 Model 承载了大量门店配置读取与业务规则处理逻辑，功能覆盖完整。但存在明显的**性能瓶颈**（循环内重复加载模型与查询）、**框架生命周期误用**（文件顶部全局获取实例）、以及**可维护性隐患**（巨型 `switch`、硬编码长字段串、变量未初始化）。整体代码偏向“过程式”堆砌，缺乏面向对象设计与批量处理思维。
- **风险等级**：🔴 高（主要源于高并发下的数据库连接耗尽风险、静态缓存潜在串扰、以及异常处理缺失）
> 📌 **框架说明**：根据目录结构（`system/`, `application/models/`）及 `$CI = &get_instance()` 用法，推断项目基于 **CodeIgniter 3** 或其衍生框架。若 `phpci` 为内部定制框架，请对照其官方文档调整生命周期与 Query Builder 用法。
---
## 2. 问题详情
| 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) |
| :--- | :--- | :--- | :--- | :--- |
| 🔴 严重 | `renewal_audio_broadcast` 方法内 | **N+1 查询与循环内加载模型**：在 `foreach` 中反复调用 `$this->load->model()` 和 `get_end_time_room()`，数据量稍大即会导致数据库连接池耗尽、脚本超时。 | 1. 将模型加载移至循环外；<br>2. 收集所有 `shop_id`/`room_id` 后使用 `WHERE IN` 批量查询；<br>3. 合并业务逻辑，减少嵌套循环。 | 见下方 `renewal_audio_broadcast` 优化示例 |
| 🔴 严重 | 文件顶部 (第 3-4 行) | **违反框架生命周期**：在类外部执行 `$CI = &get_instance(); $CI->load->model(...)`。每次文件被 `include` 时都会执行，造成性能损耗，且在 CLI/定时任务中可能引发 `get_instance()` 未初始化错误。 | 移除文件顶部代码。在方法内部直接使用 `$this->load->model()` 或 `$this->db`。CI 框架会自动处理实例注入。 | `// 删除顶部两行<br>class Ahead_shop_config_second_model extends Simple_model { ... }` |
| 🟠 警告 | `deal_audio_content_params` 方法 | **未定义变量警告**：`$total_time` 仅在 `if (!empty($room_data['_open_id']))` 分支内赋值，若条件不满足将触发 `Undefined variable` 警告。且循环内重复加载模型。 | 1. 提前初始化 `$total_time = '';`；<br>2. 将 `$this->load->model()` 移至 `foreach` 外部。 | `$total_time = ''; // 提前声明<br>$this->load->model('ahead_open_room_log_model');<br>foreach ($params_map as &$param) { ... }` |
| 🟠 警告 | `get_shop_setting` 方法 | **巨型 Switch 与隐式变量**：超 150 行的 `switch` 难以维护；部分分支未赋值 `$result`，依赖末尾 `?? ''` 兜底，易引发逻辑遗漏。静态缓存 `self::$shop_config` 在长驻进程（如 Swoole/RoadRunner）中会导致多请求数据串扰。 | 1. 在 `switch` 前初始化 `$result = '';`；<br>2. 若运行环境为 PHP-FPM 可保留静态缓存，否则建议改用 CI Cache 驱动或请求级缓存；<br>3. 考虑将转换逻辑抽离为私有方法。 | `public function get_shop_setting(...) {<br> $result = ''; // 显式初始化<br> switch ($field) { ... }<br> return $result;<br>}` |
| 🟠 警告 | `get_wechat_group_config` 方法 | **全局状态污染风险**：使用 `$this->set_table_name()` 临时修改表名，若后续查询抛出异常，表名无法恢复，将影响同一进程内的后续请求。 | 使用 `try...finally` 确保状态恢复，或优先使用 CI Query Builder 的 `from()` 与 `join()` 避免修改模型内部状态。 | `try {<br> $this->set_table_name($table_name . ' a');<br> $res = $this->select($where, $fields);<br>} finally {<br> $this->set_table_name($table_name);<br>}` |
| 🟡 建议 | `get_one` 方法参数 | **拼写错误**：参数名 `$fileds` 拼写错误，应为 `$fields`。 | 修正拼写，保持代码规范与 IDE 提示准确性。 | `public function get_one($where, $fields = '*', $order = '')` |
| 🟡 建议 | 多处使用 `throwError()` | **非标准异常处理**：依赖全局函数 `throwError()` 不符合现代 PHP 规范，且可能直接暴露堆栈信息或中断正常流程。 | 改用标准 PHP 异常或返回统一错误结构体，交由框架错误处理器统一拦截。 | `throw new \InvalidArgumentException('门店ID不能为空');` |
| 🟡 建议 | 全局代码规范 | **命名与缩进**：方法名使用 `snake_case`（CI3 历史习惯），不符合 PSR-12 推荐的 `camelCase`；缩进混用 Tab 与空格；缺少类型声明。 | 若团队强制沿用 CI3 规范可保留，但建议统一为 4 空格缩进。新增方法建议采用 `camelCase`，并补充 PHP 7+ 类型提示。 | `public function getShopSetting(int $merchantId, int $shopId, string $field): string` |
---
## 3. 总结与行动建议
### 🔑 优先修复的关键问题
1. **重构 `renewal_audio_broadcast` 方法**：当前实现是典型的“循环查库”反模式。必须将模型加载外置，并采用批量查询（如收集所有 `shop_id` 后一次性 `get_community_bill_shop`，或使用 `JOIN` 关联查询账单与房间）。
2. **清理文件顶部全局代码**：立即删除 `$CI = &get_instance();` 及外部 `load->model()`，避免框架生命周期冲突与内存泄漏。
3. **修复未初始化变量**：`deal_audio_content_params` 中的 `$total_time` 必须提前声明，否则在严格错误级别下会导致脚本中断。
### 🛠 后续重构与优化方向
1. **拆分巨型 `switch`**：`get_shop_setting` 承担了过多职责。建议：
- 将纯映射类字段（如直接返回 `$data['xxx'] ?? default`）提取为配置数组或动态属性访问。
- 将需要复杂计算/关联查询的字段（如 `currency_symbol`, `book_hour_options`）拆分为独立的私有方法 `private function resolveCurrencySymbol($data)`，在 `switch` 中仅做路由。
2. **引入请求级缓存**：若项目未来可能迁移至 PHP-FPM 以外的运行环境（如 Swoole、Workerman），`self::$shop_config` 静态缓存将引发严重的数据安全问题。建议改用 CI 的 `$this->cache->save()` 或注入 `Request` 对象进行单次请求缓存。
3. **统一异常与错误处理**：逐步废弃 `throwError()` 全局函数，建立统一的 `AppException` 或返回 `['code' => -1, 'msg' => '...']` 结构，提升 API 健壮性。
4. **数据库查询优化**：`$this->set_table_name()` 属于非标准 CI 用法。建议全面迁移至 `$this->db->from()->join()->get()` 链式调用，避免隐式状态修改。
### ⚠️ 审查局限性说明
- 本次审查仅基于提供的单个 Model 文件。`Simple_model` 父类实现、`hourToTime()`/`timeToHour()` 等全局助手函数、以及 `throwError()` 的具体行为未提供，部分逻辑（如跨天时间判断、缓存机制）的准确性依赖于这些外部组件的实现。
- 若 `phpci` 为高度定制的内部框架，部分 Query Builder 或生命周期建议需以官方文档为准。
> 💡 **附：`renewal_audio_broadcast` 核心优化思路示例**
> ```php
> public function renewal_audio_broadcast()
> {
> // 1. 模型外置
> $this->load->model(['ahead_bill_model', 'ahead_family_servers_model', 'Ahead_ai_audio_player_content_model']);
>
> $time = strtotime(date('Y-m-d H:i:00'));
> $business_date = get_business_date($time)['business_day'];
>
> // 2. 批量获取门店（避免逐店查询）
> $shops = $this->ahead_bill_model->get_community_bill_shop($time);
> if (empty($shops)) return true;
>
> $shop_ids = array_column($shops, 'shop_id');
> $merchant_ids = array_column($shops, 'merchant_id');
>
> // 3. 批量获取账单/房间数据（示例：使用 WHERE IN 或 JOIN）
> // 实际需根据 ahead_bill_model 的 API 调整，此处展示批量处理思想
> $all_bills = $this->ahead_bill_model->get_end_time_rooms_batch($merchant_ids, $shop_ids, $business_date, $time);
>
> foreach ($all_bills as $bill) {
> // 4. 统一处理播报逻辑，消除嵌套循环
> $this->ahead_family_servers_model->operational_scene_audio_broadcast(
> $bill['merchant_id'], $bill['shop_id'], $bill['room_id'], 'renewal',
> ['remaining_time' => $bill['renewal_time'], 'ai_audio' => $bill['is_ai']]
> );
> }
> return true;
> }
> ```
---
*此 Issue 由代码审查服务自动创建*...
|
0
|
0
|
0
|
0
|
0
|
|
0
|
1780998262
|
1780998262
|
0
|
0
|
0
|
0
|
Edit
Delete
|