安全扫描报出拼接字符串的查询存在注入风险，业务里确实直接把参数拼进了语句。日志里能对上时间点，这种反而好排。
用户输入直接进入 SQL 文本，特殊字符改变了语句结构。这一点先确认清楚，后面就不用反复试。
cur.execute('SELECT * FROM users WHERE name = %s AND status = %s', (name, 1))
# 表名白名单
table = {'orders', 'users'}[t]
这次卡住的地方就在「SQL 注入防护」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。偶发问题先统计频率，一小时几次和一天一次，查法完全不同。
改完顺手把文档补一句，省得下次自己重新推一遍。监控和日志的时间要对上，时区不一致会多绕很大一圈。
临时改动用注释写上日期和原因，过两周自己都记不清为什么这么写。动手前把原文件复制一份带时间戳，出问题立刻换回去，比现场分析快得多。
处理上按这个顺序：全部改用参数占位符；表名等无法参数化的部分做白名单；限制数据库账号权限。
结果对不对很好判断，扫描不再报注入风险，带引号的输入也能正常查询。