参数化查询是防御sql注入的唯一语法级隔离机制，必须用于支付接口所有动态值；转义或过滤不可靠，关键字段需双重校验、最小权限与严格事务控制。
支付接口必须用参数化查询，不能靠转义或过滤补救
拼字符串构造 SQL（比如 "UPDATE orders SET amount = " . $_POST['amount']）在支付逻辑里等于直接交出数据库密码。转义函数如 mysql_real_escape_string() 或正则过滤都挡不住 1e3、0x313233 这类绕过写法，更别说十六进制编码、宽字节注入。参数化是唯一能从语法层面隔离数据与指令的机制。
- PHP MySQLi 必须走
$stmt = $mysqli->prepare("UPDATE orders SET status = ? WHERE id = ?")+bind_param("si", $status, $id)，类型标记"si"不能省——它强制校验变量类型，防止整数位被注入字符串 - Node.js mysql2 包只认
connection.query("SELECT * FROM payments WHERE order_id = ?", [orderId])，? + 数组是硬性路径，escape()或模板字符串拼接一律禁止 - Python psycopg2 中
cursor.execute("UPDATE payments SET amount = %s", (amount,))才安全；用f"UPDATE ... {amount}"或%格式化字符串即刻失效
金额、订单号等关键字段必须双重校验
参数化只防语法破坏，不拦业务错乱。攻击者传 amount=99999999.99 或 order_id="1'; DROP TABLE payments; --"，参数化照单收下，但业务已崩。
- 金额字段先做类型强检：
is_numeric($amount) && $amount > 0 && $amount ，再用 <code>number_format($amount, 2, '.', '')统一小数位，避免浮点精度导致扣款偏差 - 订单 ID 必须白名单校验：
preg_match('/^[a-zA-Z0-9]{16,32}$/', $orderId)，禁用下划线、中划线、中文、空格——有些老系统用 UUID 带横线，就得提前标准化再校验 - 状态字段（如
status）只能是预设枚举值：in_array($status, ['pending', 'success', 'failed'], true)，绝不能放行任意字符串
事务边界要短，且隔离级别 ≠ 防注入
有人把事务设成 SERIALIZABLE 就以为能挡注入，这是根本性误解。隔离级别管的是并发读写冲突，注入发生在 SQL 解析阶段，跟锁完全无关。
- 支付扣款必须包裹在显式事务中：
START TRANSACTION ISOLATION LEVEL READ COMMITTED（PostgreSQL）或BEGIN（MySQL），且只包“查余额 → 判够 → 扣款 → 记日志”这四步 - 别把 HTTP 请求解析、日志落盘、消息队列投递塞进事务——长事务拖慢数据库，还放大死锁风险
- MySQL 默认
REPEATABLE READ可能引发幻读：A 查余额够 → B 插入一笔支出 → A 扣款 → 实际余额不足。用READ COMMITTED更稳
数据库账号权限必须最小化，错误信息绝不外泄
就算代码全参数化，一个带 DROP 权限的账号被攻破，就能直接删库；而暴露的错误信息（如 Unknown column 'xxx'）等于把表结构图送给攻击者。
- 运行
SHOW GRANTS FOR 'pay_app'@'%'，确认输出里只有SELECT、INSERT、UPDATE，绝对没有GRANT、FILE、ALTER - Node.js 中捕获
connection.query()的err，前端只返回{ code: 500, message: "请求失败" }，完整错误记到服务端日志，不透出任何 SQL 片段或字段名 - MySQL 配置里开
sql_mode=STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION，让非法输入直接报错而非静默截断，逼你在应用层处理异常
真实攻击往往不是靠一次大招打穿，而是从一个没校验的 order_id 参数开始，绕过参数化，撬开整个资金链。所有校验点——类型、范围、格式、权限、事务粒度——都得咬合，漏一处，钱就可能不见。
