集成测试复现sql注入是为了验证修复真实生效，核心是构造恶意输入并确认其未被数据库执行；若执行则防护失效，若被拦截或参数化则通过，需覆盖全链路、关闭调试模式、检查数据库日志及防退化场景。
集成测试里复现 SQL 注入漏洞，不是为了“打穿系统”，而是为了验证修复是否真实生效、边界场景是否覆盖到位。核心判断是：你能否在测试中构造出一条被拼接进 SQL 的恶意输入，并观察它是否被数据库执行——如果执行了，说明防护没起作用；如果被拦截或参数化处理了，才算通过。
为什么不能只用单元测试验证 SQL 注入修复
单元测试容易绕过真实的数据访问链路。比如你 mock 了 $pdo->prepare()，但实际运行时可能因为配置错误、中间件拦截失败、或某处漏掉了 bind_param() 调用，导致拼接逻辑悄悄复活。集成测试强制走通从 HTTP 请求 → 路由 → 控制器 → DAO → 数据库的全路径，才能暴露这类“看似修了，其实没修”的问题。
- 常见漏点：登录页修了，但搜索接口、导出接口、分页参数
order by字段仍用字符串拼接 - 框架陷阱：Laravel 的
orderBy($request->input('sort'))默认不校验字段名，直接拼进 SQL - ORM 误区：ThinkPHP 的
where('name', $user_input)安全，但where("name = '$user_input'")就危险
用真实请求 + 断言响应状态码和内容
测试目标不是“拿到数据库数据”，而是确认恶意输入未触发非预期行为。重点检查三点：是否返回 500 错误（说明报错注入成功）、是否返回异常多的数据（联合查询生效）、是否跳转到后台（布尔盲注绕过登录）。
- 测试 payload 示例：
' OR '1'='1（字符型）、1 AND SLEEP(1)（延时型）、' UNION SELECT 1,2,3--（联合型） - 断言建议：
assertResponseStatus(400)或assertSeeText('invalid input')，而不是assertResponseStatus(200) - 关键细节：必须关闭调试模式（
APP_DEBUG=false），否则 MySQL 报错会直接暴露在页面上，测试就失去了生产环境意义
数据库层需启用查询日志并验证执行语句
光看 HTTP 响应不够。有些注入虽未造成业务异常，却已偷偷执行了 SELECT user() 或 SELECT @@version。集成测试中应开启 MySQL 的 general_log，并在测试 tearDown 阶段检查日志是否包含未参数化的原始输入。
- 临时开启日志：
SET GLOBAL general_log = 'ON'; SET GLOBAL log_output = 'TABLE'; - 查日志语句：
SELECT argument FROM mysql.general_log WHERE command_type = 'Query' AND argument LIKE '%{your_payload}%' - 注意：Docker 环境下要确保容器挂载了日志目录，否则重启后日志丢失
测试用例必须覆盖“修复后又退化”的场景
最常被忽略的是：修复代码被后续重构覆盖。比如某次 PR 合并把 prepare() 改成了 query()，CI 没报错，但注入复活了。因此集成测试用例本身要带“防护钩子”——例如在 DAO 层加一个 assertNoRawSqlInjection($sql) 方法，自动扫描语句中是否含单引号+空格+关键词组合（如 ' and 、' union ）。
这种检测不替代参数化，但它能立刻告诉你：“这次提交又把拼接写回来了”。复杂点在于正则要避开合法场景，比如 JSON 字段值里的 '，所以更稳妥的做法是结合 AST 解析，而非纯字符串匹配。
