sqlmap这个工具，检测圈内人叫它“神器”不夸张。检测但真正用得好的检测人，十个里挑不出三个。检测多数人只会敲一句python sqlmap.py -u "http://target.com/page?检测id=1"，然后盯着屏幕等结果——这跟拿大炮打蚊子没什么区别，检测打中了算运气，检测打不中才是检测常态。

我见过最典型的检测翻车现场，是检测朋友测一个政府网站。URL带参数，检测后端是检测MSSQL，他直接跑默认检测，检测半小时后sqlmap报“所有参数均安全”。检测他不死心，检测换了个姿势：--level=3 --risk=2，结果还是白搭。最后我上手一看，参数名是callback，服务端拿它拼JSONP回调函数名，根本没进SQL语句。sqlmap默认只测值，不测参数名本身——这算盲区，但更算认知盲区。

检测的本质不是“跑一把”，而是“想一下”。你得先判断这个参数会被拼进哪种SQL语境。数字型、字符型、搜索框里的LIKE模糊匹配、ORDER BY后面的列名——每种位置的注入手法完全不同。sqlmap的--prefix和--suffix参数就是干这个的，但多数人懒得设，直接默认跑。默认值针对的是“参数值直接进入WHERE子句”的理想情况，现实里哪有那么多理想情况。

有一次测一个登录接口，POST提交username和password。sqlmap默认测这两个字段，报错“无注入”。我抓包看了下，发现服务端还有个隐藏字段remember_token，虽然前端不渲染，但后端会拿它拼SQL。手动加上-p remember_token，三秒出结果，直接--os-shell拿下。这事儿说明什么？工具再强，也得你告诉它该往哪儿看。

还有个坑，很多人忽略——WAF。sqlmap自带的--tamper脚本能绕一部分，但别指望它万能。我遇到过ModSecurity把UNION SELECT拦得死死的，但用--tamper=space2comment把空格换成注释符/**/就过了。后来发现那WAF只查union\s+select的正则，注释符绕得干干净净。这种细节，文档里不会教你，全靠实战试错。

说回检测本身。sqlmap的--batch模式适合自动化，但别依赖它做决策。它默认会问“检测到疑似注入，是否继续？”你一个回车选Y，它可能跑偏到盲注上，浪费半小时。我习惯加--smart，只对“看起来像”的参数深入测，再配合--string指定正常响应里的特征字符串，能大幅减少误报。

最后说个反直觉的观察：sqlmap检测成功率最高的场景，往往是开发者自以为“防住了”的地方。参数化查询做了一半，剩下几个动态拼接的排序字段；或者过滤了单引号，却没过滤数字型注入——这类半吊子防护，sqlmap一测一个准。反而那些裸奔的站，可能因为响应结构太乱，导致sqlmap判断不了真假，偶尔还漏报。

所以结论很直白：sqlmap是个好锤子，但你要先看清钉子在哪。别迷信默认参数，别跳过手工分析，更别在没WAF的环境里测试完就觉得自己天下无敌。工具是死的，绕过思路是活的。这年头，稍微像样点的目标都有防护，你拿默认配置去撞，撞开了算运气，撞不开才是常态。