SQLite Web: gitea.db

id

Primary key. INTEGER NOT NULL

repo_id

INTEGER

index

INTEGER

poster_id

INTEGER

original_author

TEXT

original_author_id

INTEGER

name

TEXT

content

## 自动代码审查报告

**分支**: pay-260616
**提交**: `5ff542a6bc55215e93856d51c13640688e03939b`
**提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com)
**时间**: 2026-06-08 18:31:12

---

## 📋 审查摘要
- **变更文件数**: 3
- **严重问题**: 1
- **高危问题**: 4
- **中危问题**: 3
- **建议优化**: 2

## 🐛 发现的问题

### [语法错误] PHP 文件截断导致致命解析失败
- **严重程度**: 严重
- **文件**: `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 的自动格式化功能快速定位未闭合代码块。

### [跨文件调用] 未加载的微信支付 SDK 类直接实例化
- **严重程度**: 高危
- **文件**: `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` 中配置自动加载。

### [跨文件调用] 小程序页面依赖的外部模型方法未验证
- **严重程度**: 高危
- **文件**: `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` 或空值防御。

### [跨文件调用] 全局函数与常量命名不一致且未声明
- **严重程度**: 高危
- **文件**: `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 由代码审查服务自动创建*

TEXT

milestone_id

INTEGER

priority

INTEGER

is_closed

INTEGER

is_pull

INTEGER

num_comments

INTEGER

ref

TEXT

deadline_unix

INTEGER

created_unix

INTEGER

updated_unix

INTEGER

closed_unix

INTEGER

is_locked

INTEGER NOT NULL (default 0

content_version

INTEGER NOT NULL (default 0

time_estimate

INTEGER NOT NULL (default 0

Update row 598 in issue