sqlite-web 0.7.2
gitea.db
issue
Create
Query
access
access_token
action
action_artifact
action_run
action_run_index
action_run_job
action_runner
action_runner_token
action_schedule
action_schedule_spec
action_task
action_task_output
action_task_step
action_tasks_version
action_variable
app_state
attachment
auth_token
badge
branch
collaboration
comment
commit_status
commit_status_index
commit_status_summary
commit_sync_log
commit_sync_status
dbfs_data
dbfs_meta
deploy_key
email_address
email_hash
external_login_user
follow
gpg_key
gpg_key_import
hook_task
issue
issue_assignees
issue_content_history
issue_dependency
issue_index
issue_label
issue_pin
issue_user
issue_watch
label
language_stat
lfs_lock
lfs_meta_object
login_source
milestone
mirror
notice
notification
oauth2_application
oauth2_authorization_code
oauth2_grant
org_user
package
package_blob
package_blob_upload
package_cleanup_rule
package_file
package_property
package_version
project
project_board
project_issue
protected_branch
protected_tag
public_key
pull_auto_merge
pull_request
push_mirror
reaction
release
renamed_branch
repo_archiver
repo_hidden_file
repo_indexer_status
repo_license
repo_redirect
repo_topic
repo_transfer
repo_unit
repository
review
review_state
secret
session
sqlite_sequence
star
stopwatch
system_setting
task
team
team_invite
team_repo
team_unit
team_user
topic
tracked_time
two_factor
upload
user
user_badge
user_blocking
user_open_id
user_redirect
user_setting
version
watch
webauthn_credential
webhook
Toggle helper tables
Structure
Content
Query
Insert
Drop
Import
Export
Delete row 249 from issue
id
249
repo_id
21
index
46
poster_id
1
original_author
original_author_id
0
name
🔍 代码审查报告：pay-260519 - 1
content
## 自动代码审查报告 **分支**: pay-260519 **提交**: `c2f698590
## 自动代码审查报告 **分支**: pay-260519 **提交**: `c2f6985906699521199792adbee2115351bbaf66` **提交人**: LITTLEMAIDI (11833999+littlemaidi@user.noreply.gitee.com) **时间**: 2026-05-20 18:09:59 --- ## 1. 审查摘要 - **代码质量评分**：5.5 / 10 分 - **总体评价**：该模型承载了核心的预订、支付回调、退款及消息推送逻辑，业务链路完整。但存在**事务边界混乱、SQL拼接注入风险、财务计算精度隐患、方法严重超长违反单一职责原则**等问题。代码风格不统一，硬编码与魔法数字较多，且文件末尾代码被截断，无法评估完整逻辑。 - **风险等级**：🔴 高（涉及资金流转与支付回调，当前实现存在数据不一致与注入风险） --- ## 2. 问题详情 | 严重程度 | 文件/行号 | 问题描述 | 建议修改方案 | 代码示例 (可选) | | :--- | :--- | :--- | :--- | :--- | | 🔴 严重 | `check_notify` 方法 | **事务与异常处理冲突**：`$this->db->trans_complete()` 在 `try` 块中提前执行，若后续 `send_success_msg()` 抛出异常，`catch` 块会调用 `trans_rollback()`。此时事务已提交，回滚无效，且会导致支付回调响应超时被平台重试。 | 严格限定事务仅包裹数据库操作。外部API调用（微信/短信/VIP回调）必须移至事务提交后，或放入异步队列。移除包裹外部调用的 `try-catch` 或拆分逻辑。 | ```php<br>// 正确做法：<br>$this->db->trans_start();<br>// ... 仅数据库操作 ...<br>$this->db->trans_complete();<br><br>if ($this->db->trans_status() === FALSE) {<br> // 处理DB失败<br>} else {<br> // 事务成功后再执行外部通知<br> $this->send_success_msg($order_data);<br>}``` | | 🔴 严重 | `refund_by_notify` 方法 | **SQL 注入漏洞**：`$log_where = '_relation_id="' . $order_data['_id'] . '" and ...'` 直接拼接字符串传入 `up()` 方法。若 `_id` 未严格校验，攻击者可构造恶意输入执行任意 SQL。 | 废弃字符串拼接，全面使用查询构造器或参数绑定。 | ```php<br>$this->db->where('_relation_id', $order_data['_id'])<br> ->where('_status', 1)<br> ->where_in('_type', [5, 13])<br> ->update('pay_log_table', $update_data);``` | | 🟠 警告 | `refund_by_notify` / `check_notify` | **浮点数精度丢失**：金额计算直接使用 `float` 乘除（如 `$total_amount * 100`），在 PHP 中极易产生 `0.000000001` 级误差，导致退款金额对账失败。 | 财务计算统一转为“分”（整数）处理，或使用 `bcmath` 扩展函数。 | ```php<br>// 使用 bcmath 保证精度<br>$total_fee = bcmul($total_amount, '100', 0);<br>$refund_fee = bcmul($can_refund_amount, '100', 0);``` | | 🟠 警告 | 文件顶部 | **框架规范违规**：`$CI = &get_instance();` 定义在类外部。CI/类CI框架中，全局获取实例应在类方法内部按需调用，否则可能在自动加载前引发 `Fatal Error`。 | 删除顶部代码，在类内部方法中按需 `$CI =& get_instance();`，或使用 `$this->load->config()` 替代。 | ```php<br>class Ahead_book_order_model extends Simple_model {<br> public function some_method() {<br> $CI =& get_instance();<br> $CI->config->load('wx', TRUE);<br> }<br>}``` | | 🟠 警告 | `get_list` 方法 | **N+1 查询隐患**：虽使用 `$merchant_business_model` 局部缓存，但循环内仍可能触发多次 DB 查询。若订单列表跨多个商家，性能会显著下降。 | 提取所有 `merchant_id` 使用 `where_in` 批量查询，或在 Service 层统一组装数据。 | ```php<br>$merchant_ids = array_column($order_info, 'merchant_id');<br>$merchants = $this->ahead_merchant_model->get_many(['_id' => $merchant_ids], '_id,_business_model');<br>// 转为 key-value 映射后循环赋值``` | | 🟡 建议 | 全文件 | **魔法数字与硬编码泛滥**：状态码 `-1, 1, 2, 3, 4, 5, 14, 56, 58, 99` 直接散落在代码中，可读性差且后期维护极易出错。 | 在类顶部定义常量枚举，如 `const STATUS_PENDING = -1; const STATUS_PAID = 1;`。 | ```php<br>class Ahead_book_order_model extends Simple_model {<br> const STATUS_PENDING = -1;<br> const STATUS_PAID = 1;<br> // ...<br>}``` | | 🟡 建议 | `check_notify`, `refund_by_notify`, `create_community_shop_book_order` | **违反单一职责原则 (SRP)**：单个方法超过 150~200 行，混合了参数校验、库存扣减、事务控制、第三方退款、日志记录、消息推送。 | 按业务域拆分为独立服务类：`OrderValidator`、`InventoryService`、`RefundProcessor`、`NotificationDispatcher`。模型仅保留数据访问层逻辑。 | *(架构级建议，无需具体代码)* | | 🟡 建议 | 全文件 | **代码规范不统一**：数组语法混用 `array()` 与 `[]`；日志函数名不一致 (`doLog` vs `do_log`)；存在大量注释掉的死代码。 | 统一使用短数组语法 `[]`；统一日志函数命名；清理无用注释代码；严格遵循 PSR-12。 | *(使用 PHP-CS-Fixer 或 IDE 格式化即可)* | --- ## 3. 总结与行动建议 ### 🔑 优先修复的关键问题 1. **修复事务边界**：立即将 `check_notify` 中的 `$this->db->trans_complete()` 移至所有数据库操作结束后，确保外部 API 调用不在事务块内。若外部调用失败，不应影响已提交的支付状态，应记录日志并走补偿机制。 2. **消除 SQL 注入**：全局搜索 `$this->...->up($log_up, $log_where)` 及类似字符串拼接查询，全部替换为 CI Query Builder 或预处理语句。 3. **金额精度改造**：所有涉及支付、退款、分账的金额计算，强制使用 `bcmul`/`bcadd` 或统一转为整数（分）运算，避免财务对账差异。 ### 🛠 后续重构与优化方向 1. **架构分层**：当前 Model 承担了 Controller/Service 的职责。建议引入 `Service` 层处理业务编排（如支付回调流程、退款流程），Model 仅负责 `CRUD` 与基础查询。 2. **异步化改造**：支付成功后的微信模板消息、短信通知、VIP 积分回调等耗时操作，应通过消息队列（如 Redis Queue / RabbitMQ）异步执行，确保支付回调接口在 `2s` 内返回，避免被支付平台判定超时并重复回调。 3. **常量与配置管理**：将散落的魔法数字、短信模板ID、微信配置等抽离至配置文件或常量类，提升可维护性。 4. **代码截断说明**：您提供的代码在 `if ($this->tuangou->consume_check_time == '1') {` 处被截断。若该分支涉及团购券核销或退款逻辑，请补充完整代码以便进行针对性审查。 > 💡 **框架适配提示**：代码结构高度符合 **CodeIgniter 3** 规范。若 `phpci` 为内部定制框架，请确认其事务管理器（`trans_start/complete`）与 CI3 行为是否一致。若存在差异，请以官方文档的事务生命周期为准。 --- *此 Issue 由代码审查服务自动创建*
...
milestone_id
0
priority
0
is_closed
0
is_pull
0
num_comments
0
ref
deadline_unix
0
created_unix
1779271799
updated_unix
1779271799
closed_unix
0
is_locked
0
content_version
0
time_estimate
0
Delete
Cancel