|
|
@@ -1157,3 +1157,26 @@ B/C 档的绿与 A 档的绿不是同一种绿，混在一张总表里就是把"
|
|
|
⚠ `t_user_expense_school` 的建行语句只写 `(userid, schoolid, campusid)` 三列 ⇒ 金额列
|
|
|
`DEFAULT NULL` ⇒ `SET balance=balance+m` 仍是 **NULL** ⇒ **钱一分没到账、107 流水照写**。
|
|
|
与 C1-11 同族但后果更重（不是"少扣"，是"用户被告知发了奖励、余额没动"），线上有真实调用点。
|
|
|
+
|
|
|
+### 17.3 `user_discount_usable`：**oracle 是 PHP 内联 SQL，不是 SP**
|
|
|
+
|
|
|
+`CoursesActivityUserDiscountHelper.php:94` 把它 `CALL` 的那一行整行注释掉了，
|
|
|
+但**上面一行有生效的等价 SQL**：
|
|
|
+
|
|
|
+```php
|
|
|
+$sql = "SELECT SUM(t1.discount_amount-t1.discount_amount_used) as amount FROM ... WHERE {$condition}";
|
|
|
+```
|
|
|
+
|
|
|
+⇒ 生产实际跑的是**那段 PHP 内联 SQL**，SP 从未被调用过。
|
|
|
+
|
|
|
+**两条结论**：
|
|
|
+
|
|
|
+1. 这一支**不进 `DefaultCases`**。拿 SP 当双跑基准，验的是"我们照着一段**死代码**实现对了"，
|
|
|
+ 而生产跑的是另一段代码 —— 那种绿是假绿。
|
|
|
+2. 将来若真要验 target 的"可用赠送金额"，**基准必须取 PHP 内联 SQL**（`getUsableDiscountAmount` 那段），不是 SP。
|
|
|
+
|
|
|
+**给后端的一句话**：**这一支照 PHP 抄，不要照 dump 抄。**
|
|
|
+照 dump 抄会把 `IF inputSchoolid>0 THEN … AND campusid=…` 那个签名缺陷引进来
|
|
|
+（两个参数绑成一个开关：传 `schoolid>0, campusid=0` 时条件变成 `AND campusid=0`，
|
|
|
+只统计全机构池、漏掉本校区全部额度）。**而那个缺陷在生产上从未发生**，因为这段 SP 根本没被调用过。
|
|
|
+它**不是"待迁移的风险"，而是"如果照 dump 抄就会被引入的风险"** —— 这两句话的处置完全不同。
|
